BYO-UI

Multi-platform compositions

The job can span several systems.

A customer-owned interface can coordinate a system of record, a production platform, and an engagement channel—while preserving each system’s source-of-truth and approval boundary.

Single-system BYO-UI

One platform supplies most of the required state and actions. The interface is a focused layer over that governed system.

Fewer identity joinsNarrow authorizationFastest experiment

Multi-system BYO-UI

The interface follows the customer’s job boundary. Each platform retains its source of truth, permissions, and operational responsibility.

Shared identifiersOrchestrationCross-system audit

Recipe library

12 proposed compositions

beehiivHeyGenYouTubeLinkedIn Marketing APIs

Newsletter-to-video distribution room

Turn an approved newsletter into on-brand video and prepare channel distribution.

  1. Read approved post and audience context
  2. Generate script and video draft
  3. Review claims, likeness, captions, and brand
  4. Publish through the native channel approval boundary
Source of truth
beehiiv remains the source for the article and audience; HeyGen owns render jobs; each channel owns publication state.
Approval
Human approval before video generation with protected likeness and before every public publish.
Identity
Delegated account access per platform; do not share creator or channel credentials across tenants.
Audit
Persist source post ID, render job ID, approval actor, and channel publication ID.
RevSure or MetadataSalesforce or HubSpotHeyGenOutreach or lifecycle platform

Account-personalized video studio

Create a relevant account-specific video without creating a parallel CRM or campaign database.

  1. Select account using governed fit and engagement evidence
  2. Retrieve account, contact, and opportunity context
  3. Generate a draft script and video
  4. Route review and approved delivery
  5. Write activity and asset references back
Source of truth
CRM owns account and opportunity; intelligence platform owns scoring evidence; HeyGen owns media asset; engagement platform owns delivery.
Approval
Required for claims, contact selection, likeness, and outbound delivery.
Identity
User-delegated permissions with territory and contact-policy checks.
Audit
Store evidence snapshot, prompt inputs, output asset, reviewer, and delivery result.
Google AdsMeta AdsLinkedIn Marketing APIsAmazon Adsanalytics or warehouse

Cross-channel campaign exception cockpit

Focus operators on pacing, delivery, creative, and conversion exceptions across paid media.

  1. Read spend and delivery
  2. Normalize only explicitly defined metrics
  3. Flag exceptions with source evidence
  4. Prepare changes
  5. Approve and execute through the owning channel
Source of truth
Each ad platform owns campaign state and spend; analytics or warehouse owns the cross-channel comparison model.
Approval
Budget, bid, pause, launch, and audience changes require channel-owner approval.
Identity
Separate advertiser accounts and manager hierarchies; preserve user and app scopes.
Audit
Record source account, metric definition, recommendation, approval, mutation ID, and result.
Zoom or ON24DescriptContentful or AEMbeehiiv or BrazeCRM

Webinar-to-campaign content engine

Convert event evidence into clips, summaries, and follow-up without losing consent or provenance.

  1. Receive completed-event and recording event
  2. Retrieve transcript and engagement
  3. Select evidence-backed highlights
  4. Produce clips and summary drafts
  5. Route content and audience approval
  6. Publish and record campaign state
Source of truth
Event platform owns attendance and recording; media editor owns derived assets; CMS owns published content; lifecycle platform owns delivery.
Approval
Speaker rights, attendee quotes, claims, public assets, and audience sends require approval.
Identity
Event, content, and campaign roles should remain distinct.
Audit
Store timestamps, source recording, asset lineage, reviewers, send IDs, and destination URLs.
Braze or Klaviyo or AJOSegment or HightouchCRManalytics

Lifecycle journey debugger

Explain why customers fail to enter, progress through, or convert in a journey.

  1. Read segment and entry criteria
  2. Trace identity and event flow
  3. Inspect suppression and branch logic
  4. Compare delivery and conversion
  5. Prepare reversible fixes
Source of truth
CDP owns profile and activation state; lifecycle platform owns journey state; CRM and analytics retain their domain records.
Approval
Required before audience, suppression, send, or journey activation changes.
Identity
Respect consent, identity confidence, region, and user permissions.
Audit
Record profile identifiers, event lineage, configuration version, proposed fix, and activation approval.
Qualtrics or TypeformUserTestingDovetailAmplitude or PendoNotion or Jira

Customer evidence decision room

Connect survey, interview, usability, and behavioral evidence to a traceable product or marketing decision.

  1. Collect or select research evidence
  2. Link transcripts and response records
  3. Compare behavioral evidence
  4. Create explicit interpretations and contradictions
  5. Log decision and follow-up work
Source of truth
Research systems own raw evidence; analytics owns behavioral events; work system owns the decision and follow-up.
Approval
Required before exposing participant identity or publishing external claims.
Identity
Research-access and participant-consent boundaries remain authoritative.
Audit
Store source IDs, evidence excerpts, analyst, decision owner, and follow-up outcome.
impact.com or PartnerStackSalesforce or HubSpotStripeContentful or LMS

Partner-to-revenue operations cockpit

Connect partner referrals and enablement to CRM pipeline, revenue, and payout exceptions.

  1. Read partner and referral state
  2. Match or create governed CRM records
  3. Track attribution evidence and revenue
  4. Surface commission exceptions
  5. Route enablement or payment work
Source of truth
Partner platform owns program and commission state; CRM owns pipeline; Stripe owns payment; content system owns enablement assets.
Approval
Attribution overrides, contract changes, and payouts require separation of duties.
Identity
Partner-visible data must be separated from internal commercial and customer data.
Audit
Persist partner, referral, opportunity, invoice, commission, approval, and payout IDs.
AppsFlyer or AdjustGoogle Ads or Meta AdswarehouseStripe or commerce platform

Mobile acquisition reconciliation room

Reconcile ad-platform, mobile measurement, product event, and revenue data without pretending one source is universal truth.

  1. Read channel cost and attributed installs
  2. Read mobile measurement events
  3. Read product and revenue events
  4. Compare windows and identity rules
  5. Create discrepancy cases
Source of truth
Each source retains its own observed facts; the warehouse stores the explicit comparison model.
Approval
Required for attribution settings, audience syncs, budget, or campaign changes.
Identity
Honor device and user privacy, consent, aggregation thresholds, and regional policy.
Audit
Store source, model, window, freshness, discrepancy, owner, and resolution.
Contentful or AEMSmartling or LokaliseHeyGen or CloudinaryWorkfront or Asanalifecycle or social platform

Global campaign localization studio

Move approved campaign source content through translation, media variation, CMS, and distribution workflows.

  1. Lock source version
  2. Create locale jobs
  3. Generate and review media variants
  4. Attach approved assets to localized content
  5. Route market approval
  6. Publish through destination systems
Source of truth
CMS owns source and localized content; localization platform owns translation workflow; DAM/media owns assets; destination owns publication.
Approval
Market reviewer, legal, brand, and destination publisher approvals are required.
Identity
Locale, market, project, and publishing roles should be mapped explicitly.
Audit
Store source version, locale job, asset lineage, approvals, and publication IDs.
Composio or Nango or PipedreamSmithery or official MCP registryenterprise identityobservability platform

Agent capability control plane

Give agents and custom UIs a small, owned, observable capability catalog across many SaaS systems.

  1. Register candidate tool
  2. Verify publisher and source docs
  3. Assign owner and risk class
  4. Define scopes and parameter constraints
  5. Test in nonproduction
  6. Approve and monitor
Source of truth
Underlying SaaS remains authoritative; gateway owns connection and execution metadata; governance catalog owns approval state.
Approval
Required for production promotion, broader scopes, destructive tools, or new connected accounts.
Identity
Use delegated per-user identity where possible; never collapse tenants into a shared superuser.
Audit
Log tool version, schema, user, connected account, call inputs, result IDs, approval, and failure.
Zendesk or IntercomCRMStripe or commerceproduct analyticswork management

Customer support resolution cockpit

Bring account, product, billing, and conversation evidence into a focused resolution interface.

  1. Open support case
  2. Resolve customer and account identity
  3. Retrieve billing and product evidence
  4. Propose next best resolution
  5. Approve consequential actions
  6. Write status back to owning systems
Source of truth
Support system owns case; CRM owns relationship; commerce owns financial state; analytics owns observed usage.
Approval
Refund, credit, entitlement, deletion, and external communication require explicit authority.
Identity
Agent role, customer identity confidence, account tenancy, and PII access must be visible.
Audit
Store case, evidence sources, recommendation, approvals, financial action IDs, and communication history.
Statsig or OptimizelyLaunchDarklyanalyticsJira or AsanaCRM or lifecycle

Experiment-to-release workbench

Connect hypothesis, experiment evidence, feature state, campaign impact, and production release.

  1. Read hypothesis and experiment configuration
  2. Review metric and segment results
  3. Inspect contradictory evidence
  4. Prepare flag or rollout change
  5. Approve production mutation
  6. Monitor outcome and rollback
Source of truth
Experiment platform owns test evidence; LaunchDarkly owns flag state; work system owns decision record.
Approval
Production rollout and rollback changes require environment-aware approval.
Identity
Project and environment roles, protected production, and service credentials apply.
Audit
Store experiment, metrics, decision, flag version, approver, deployment, and rollback evidence.
Composition principle: the interface may unify the moment of work, but it should not invent a new source of truth. Persist identifiers, preserve provenance, and route consequential actions to the system that owns them.