The Embed Is the Product: Rethinking AI Distribution

The AI industry has picked up a familiar playbook from the developer tools era: ship an API, write documentation, let developers build. This confuses access with distribution. An API grants you access to a capability but doesn’t help you with distribution.

After years of building embedded analytics at ThoughtSpot, I’ve come to the conclusion that for AI products with user-facing surfaces, an API alone won’t cut it. If you want developers to actually adopt your product, not just play with it, you also need to ship embeddable UI alongside your endpoints.

The True Cost of “Just Use Our API”

What happens when a developer integrates an AI-enabled capability via API? They get the intelligent part (the model, the prediction, the recommendation). But the rest is on them: collecting input, presenting results, error handling, loading states, edge cases, accessibility, and localization.

Consider an AI-powered airline booking experience. The API might return flight options ranked by some intelligence. But the developer is left to figure out how to build interfaces for: number of passengers, class of service, number of stops, preferred departure and arrival times, preferred airline, and then decide how to actually present the result set such that it’s usable and actionable. Every team redoing this from scratch is doing worse than a team dedicated to the problem.

This isn’t hypothetical. The pattern is well-established in adjacent spaces.

Stripe never achieved wide adoption just because of its payment API. Stripe Checkout, the embeddable UI, is what made integration easy. It handles 3D secure, card brand detection, address validation, error states, localization, and accessibility. You’re not just saving time; you’re getting experts’ decisions on what works best.

Google Maps and YouTube embeds are so ubiquitous that most people interact with these products through other sites. The embed is the product.

Plaid Link component is what made Plaid ubiquitous in the fintech world, not the API. The UI captures all the complexity of connecting to thousands of banks with different authentication flows.

The Framework: Embeddable UI = API + Expertise + Time-to-Value

I’m not anti-API. They should be a thing. But they should only be part of the equation. An embeddable UI layer should capture three things that an API does not:

• Expertise. Every user-facing interface has edge cases only apparent after thousands of implementations. An embeddable component encapsulates that expertise: the error states you forgot, the accessibility edge cases you missed, the interaction patterns that users expect.
• Time-to-value. When assessing your product value, a developer is looking for it to appear in their product with minimal friction. Embedding your UI component is far less work than building a UI on top of your API. Faster integration equals faster adoption.
• Stickiness. Once developers have built their product around your embedded component, styled it to match their application, wired up their event handlers, and integrated their analytics — switching out your product becomes far more complex. This isn’t lock-in through limitation; this is retention through real integration depth.

Escape Hatches: Control Without Constraints

What’s the skeptical developer’s objection? “I want full control. My use case is unique. Components will constrain me.”

That’s a fair point — but only if the embed isn’t designed well. A well-designed embed SDK strikes a balance between convenience and flexibility using layered escape hatches:

Styling

CSS variables for colors, fonts, and spacing are table stakes. But that’s not enough. The escape hatch? Inject arbitrary CSS into your embed. When business requirements demand something we didn’t think of, they deserve full control over the visual appearance.

Events

Expose interception points for all important events, including error events — developers should be able to show their own error messages and trigger their own analytics on these events. One example from my ThoughtSpot Embedded work: developers can inject custom JavaScript to send metrics from iframe UI events without my team’s SDK teams’ knowledge into their own Pendo or Amplitude instances.

Extensibility

Allow developers to add their own UI elements that connect with and extend the UI where your product lives. We built “custom actions” at ThoughtSpot. Developers can add menu items anywhere in the product. When an end user clicks on it, a callback fires in context; developers can do whatever they want – send data to another system, trigger workflows; the only limiting factor is developer ingenuity.

The goal isn’t to make developers feel constrained by our component; rather, feel empowered to do more in less time.

But, What’s The Catch?

Building an embeddable UI isn’t without challenges. Compared to building an API, it’s harder work.

You’re signing up for the following.

Higher Quality Bar

Customers rely on your embed to do heavy lifting. Your UI must never be perceptibly slower than their own application. Latency in your product may be fine when users use it as a standalone product; it’s not when they see your product embedded within another application.

Versioning Complexity

CSS injection creates implicit dependencies; if your customers inject CSS into their instance of your product and you make changes to the internal CSS structure, it will break their customization. Even simple UI changes can no longer be experiments; they must be feature-gated under the customer’s control, even if you see them as best practices — customers may not yet be ready to deploy changes across all users.

Authentication Integrity

Users cannot authenticate twice; once to their host application and again to your embedded product instance. Do you need cookieless trusted token authentication without third-party cookies that Safari and other browsers now block by default? A mint-token-for-every-session approach won’t cut it; the host application must provision and authenticate users on behalf of an SDK instance that must refresh tokens behind-the-scenes.

Multi-Tenant Isolation

Your customer’s users must never see remnants from another tenant's users. Web security controls for clickjacking and other attacks must work in an embedded context.

These challenges are daunting. But the distribution leverage (developers can integrate in hours instead of weeks; they build deeply around your product and become genuinely dependent on your capabilities) makes them worth it.

The Agentic Future: Embeds as Output Primitives

Even in agentic contexts where multiple iterations by different developers have standardized input patterns across agents, embedding UI components still matters.

A thoughtful reader will ask: how? Agents operate via text today. An agent that books flights returns JSON or natural language instructions — something the user must still act on; it cannot be embedded in any other UI components

But agents shouldn’t return a list of flight options any more than they should return a list of hotels when completing an inline booking request. They should return an embedded flight search result comparator rather than returning a list of options for user consumption and selection post-agent prompting.

UI embeds should become an output primitive for agents — a concept more powerful than prevailing approaches that render responses in natural-language text or structured data formats like JSON.

Model Context Protocol (MCP) and similar frameworks are already making agent tool use protocols standardized across agents; the next frontier is making output rendering mechanisms standardized across agents.

An MCP server returning an iframe with a fully functional flight comparator will be far more useful than one returning JSON that needs downstream tooling into UI components relevant to a given use case.

Conversational interfaces are powerful, but they’re no miracle cure for all interactions humans want with agents or something like them. The mouse was invented after the keyboard for a reason. There are interactions better mediated by pointing devices than by talking or typing.

When agents need something from users that requires structured input rather than unstructured input or complex output rather than free-ranging text output, embeds come to the rescue. An embedded UI component will make it easier for users interact with agents than asking them follow conversational flows over multiple steps across distinct queries.

Conclusion

If you're building an AI product, ask yourself: Do I have a user-facing surface? Does it have interaction complexity rather than just displaying a single value?

If yes, then embeddable UI should be part of your roadmap from day zero rather than a v2 feature? Even if your current users aren't developers, there might still be an opportunity here to open up your perfect, although polished user experience as embeddable components for other developers as a new product line. The API gets you access; the embed gets you distribution