Stackable Labs

Blog · November 13, 2026

Interactive UI for AI agents: what Salesforce, OpenAI and Anthropic shipped this fall

Salesforce, OpenAI and Anthropic spent the fall shipping the same idea: agents need real, declared UI that renders wherever the agent runs. Here's what changed, the four questions every platform still has to answer, and two we're still exploring.

By Adam Grohs, Co-Founder / Head of Product - Stackable Labs

Share

For a long time, the default answer to "what should the agent show the customer?" was "more words." A tracking number in paragraph two. A refund amount in paragraph three. "Reply RETURN to start a return." (We've complained about this before. We'll probably complain about it again.)

This fall, the biggest platforms in AI quietly agreed on a different answer. Not more words. A widget.

Three announcements, one idea

Salesforce used Dreamforce to introduce the Headless Experience Layer, in Beta, under a heading that could be this post's title: "Build the interface once, render it anywhere." Its Dreamforce recap puts it plainly: "you can create a rich, interactive UI widget once, then render it natively across every surface the agent runs on," either "inside Agentforce or externally through a hosted MCP server." The product page names "Lightning, Slack, ChatGPT, and Claude." A companion feature, Deterministic Rendering, has the agent return "structured JSON your client renders natively" (carousels, quick-reply buttons, list pickers and media cards), and "guarantees that the same structured response always looks the same on any client."

OpenAI made its move at DevDay on September 29. From its announcement post: "Plugin extensions support sidebar entries, interactive panels, and file viewers." The extensions docs show what that means in practice: an app can live in the sidebar, or open "beside a conversation, keeping their work and chat together."

Anthropic opened a developer portal for the Claude directory on September 25. Plugins can package MCP servers and skills, and that list includes "MCP Apps, for interactive UI inside chat."

Notice what all three are standing on. OpenAI's sidebar entry "launches your MCP App fullscreen." Anthropic's directory lists MCP Apps by name. Salesforce delivers its widgets to outside surfaces through a hosted MCP server. MCP Apps is an official extension to the Model Context Protocol, and its docs open with the line that sums up this whole shift: "Text responses can only go so far."

When we wrote Beyond the FAQ bot in August, MCP Apps was already the protocol's first official extension, with early support in ChatGPT and Claude. Two months later, MCP is the thread running through all three, and MCP Apps is how the widgets get drawn inside ChatGPT and Claude.

Why the widget, specifically

A chat bubble is too small to act in. A whole app is too big to carry around. The widget sits in between: one piece of UI, built for one job (show this order, confirm this refund, pick this delivery slot), small enough to drop into whatever surface the agent happens to be running on.

Salesforce's product page has the best one-line description of why that matters: it "separates your business logic, data, and permissions from the screen." Build the logic once. Let each surface draw it.

That's also why the widget is where agents that act actually do their acting. The model decides what should happen. The widget is where the customer sees the exact order, the exact amount and the exact date, and taps a real button to say yes. The risky step leaves free text behind.

Even voice, which has no screen at all, follows the pattern. In Sierra's payments integration with Stripe, "When it's time to pay, the agent moves into a secure payment mode," and the caller types their card on the keypad. No widget, but the same instinct: when money moves, the conversation hands off to a structured control.

(The flip side is moving too. WebMCP lets a web page hand tools to browser agents, which we covered on the agnoStack blog. Tools let an agent act. Widgets are where the customer sees the act and agrees to it.)

Four questions every platform has to answer

Rendering a widget is the easy part. The moment a widget can read a customer's data or change an order, it's a piece of third-party code running inside someone else's experience. Every platform shipping this has to answer the same four questions.

1. Who declares what a widget may do? MCP Apps lets a UI resource request permissions and a csp that controls which origins it can load from, and the docs are clear that "The host controls which capabilities your app can access." Salesforce says its layer "inherits Salesforce's native permissions and sharing models." Different mechanisms, same principle: the widget asks, the host decides.

2. Where do the secrets live? Not in the widget. A widget runs in a page the customer can inspect, so API keys and tokens have to stay on a server and be applied on the widget's behalf. MCP Apps runs each app in a sandboxed iframe that, in the docs' words, "can't access the parent page, steal cookies, or escape their container." Good. Something still has to hold the keys.

3. Who reviews it? Anthropic's portal says submissions are "checked and safety-scanned as soon as you submit." OpenAI's submission docs say "After initial publication, OpenAI scans your hosted MCP server daily." Review is becoming table stakes, which is exactly as it should be for code that acts on a customer's behalf.

4. How does it look like it belongs? Deterministic Rendering promises a response looks the same on every client. That's half the answer. The other half is the brand: a widget inside a brand's messenger should look like that brand, not like whoever built the widget.

Where this already exists for Zendesk Messenger

None of the announcements above are about a brand's own support messenger. That's where we work, and it's what Stackable Messenger was built for: live data and one-click actions beside the conversation, not more text inside it.

Zendesk Messenger has good building blocks for rich UI: buttons, carousels and Conversation Extensions. As we wrote in our comparison, what it doesn't offer natively is the package: a way to declare what an experience may do, review it, and let any brand install it.

That package is what Stackable is, and it answers the same four questions:

  • Declared permissions. Every extension's manifest lists its targets, its permissions and the domains it can call. Brands see the permissions before they install, and data.fetch only reaches the listed domains.
  • Secrets stay server-side. Extensions call your systems through data.fetch, proxied by the platform. Secret settings are written as {{settings.apiKey}} placeholders, and the proxy fills them in on the server, so the real secret never enters extension code.
  • Review before install. Marketplace submissions go through an automated bundle scan (do the permissions, targets and domains the manifest declares match what the code actually does?), then an advanced review and Stackable approval.
  • The host's look, for free. The ui.* components automatically inherit colors, typography, spacing and dark mode from the host. No CSS or theme configuration needed.

And the build-once idea applies here too. The same extensions are reaching past the messenger: agnoStack 6.1.0 brought an early look at Stackable App Extensions inside the Zendesk Agent Workspace, right where agents work. The agnoStack blog walks through how one sandboxed runtime, host-mediated capabilities and named slots serve both sides of the conversation. And as we announced in July, a Zendesk Conversation Extension is coming to Stackable as just another surface: same SDK, same components, same manifest, same marketplace.

Two questions we're still exploring

We don't have answers to these yet. They're the ones on our whiteboard.

What happens when the customer's AI finds the front door? Zendesk's Open Service Directory lets a customer's AI find a brand's verified support, and for a lot of brands that's a messenger (Rob covered what a commerce brand needs behind that door on the agnoStack blog). The AI that arrives can't tap a button, but the person it works for can. Could the same extension that shows a person their order also be where they approve what their AI asked for? We started on this in When the customer's AI comes knocking.

Can one extension serve both the person and the agent? WebMCP hands an agent tools. An extension already declares what it can do in its manifest. Could that one declaration describe its actions to an agent as tools and its interface to a person as a widget, so a brand writes the logic once and both sides get it? And when the one calling the tool is an agent, where do the confirmation and the receipt go?

Build the widget, not the wall of text

The platforms have made their call. Agents are getting a real interface, and the widget is how it ships. The open questions now are about trust: who declares, who holds the keys, who reviews, and whose brand it wears.

If you want to build one for a Zendesk messenger today, our Claude Code tutorial goes from an empty folder to an order-status card in one sitting, and the developer docs cover the rest. Or browse the marketplace to see what's already live.