Rox Tether: Agentic UI alternative to MCP Apps, A2UI or ChatGPT Apps

Rox Tether: Agentic UI alternative to MCP Apps, A2UI or ChatGPT Apps

Ask an agent connected to a product's MCP server anything that requires a visual representation: the typical result is a markdown table or some MCP App widget. Both are restrictive renderings since the user never experiences the full product. This research reflects a way for them to stay in their agent and still control and use the product as they see fit, instead of having data rendered on the fly. 

In the revenue space, reps connect MCP servers to their agent and run entire workflows off of it, yet they still open the underlying product to validate. Habit is the reason. A seller's speed is a thousand reps of the same layout: stage columns in the same order, the filter bar in the same corner, the forecast rollup in the same place. Chat renderings throw that away. A widget is the product with its depth amputated; the seller hits its wall in three clicks, opens the real product anyway, and now manages a seam between two copies of the same data.

We study how agents should display results to users, identify a third architectural option beyond the generated and embedded UI, build it, and measure it. In this research paper, we use a shopping cart example, a deliberately generic prototype store we built called Shoply, to show the power of the approach.

Motivation

Agentic UI work has organized around two answers to how agents show users things.

Generated UI Flow

Generate the UI: the model emits an interface description and the client renders it. This covers Google's A2UI, the GenUI research line (arXiv:2508.19227 reports up to 72% preference over chat for information-dense tasks), and Gemini's Dynamic View. Known costs, acknowledged by proponents: generation latency from tens of seconds to minutes, no cross-session consistency, and a learnability problem, since every answer is an interface the user has not seen before.

Embedded UI Flow

Embed the UI: the product ships widgets that render inside the chat host's sandbox. This covers MCP Apps (GA January 2026) and the OpenAI Apps SDK. What shipped has significant gaps: widget state is scoped to the chat message that spawned it, state persistence was deferred to a future extension, and there is a documented bug class where the model acts on a stale widget selection the user has since changed. Partner economics are also strained; six months after launch, reporting found partners deliberately limiting their apps to protect direct customer relationships.

The two poles disagree about who authors the pixels but share a premise: the chat container is the display. Everything the user sees must fit inside the conversation, so products get reduced to fit it. A full commerce experience becomes a carousel card; a CRM becomes a table widget.

We identify and evaluate a third pole. Taxonomy by who owns the pixels:

Fragments of the tethered pole exist but each is missing a piece. Computer-use agents attach to real UIs by pixels and accessibility trees; the topology is right and the interface is wrong. WebMCP (W3C draft, Chrome 149 origin trial) has the right interface and the wrong meeting point, since the page and agent must share a browser and tools exist only while the tab lives. Embedded copilots (AG-UI, Linear's agent SDK) have the right bidirectional contract but deploy inside the product, so they never reach users whose agent sessions live in claude.ai or ChatGPT. No existing system combines a user in an unmodified chat host, a product in an ordinary browser tab, and a semantic control plane between them.

The Tethered UI Flow

How we built it

The architecture rests on one observation: an MCP server and a web app for the same product already share a backend and a user identity. The agent connection authenticates over OAuth as user X. The open tab holds a session cookie as user X. Both channels terminate in the same backend, which can consult its own connection table and determine that user X has a conversation running and a tab open. Pairing them is a lookup. We call this server-side identity rendezvous. It requires no browser API, no new protocol, and no cooperation from the chat host, which simply calls tools.

Four design commitments sit on the rendezvous:

1. Headless-first. The agent always operates against server-side state through ordinary MCP tools. The UI is a projection that can attach at any moment, never a dependency. With no tab open, everything still works, and answers carry server-minted deep links (shoply.example/v/view_42) that open the app at exactly the state the agent meant.

2. Handles, not copies. Server-minted identifiers (cart_u1, view_42) are the unit of reference in tool results, links, and context. Surfaces render handles; they never own state. The protocol layer converged on this independently: MCP's 2026-07-28 revision (SEP-2567) deleted sessions in favor of explicit state handles, OpenAI sunset the Assistants API for response and conversation handles, and A2A had durable task handles from day one.

3. One contract, two directions. Tools are the actions the agent may take. Semantic events (selection.changed, cart.item_qty_changed, order.confirmed) are the observations the product reports back, typed and attributed to a human or agent actor on every mutation. The agent pulls them at turn start through a single tool, context_sync, which returns live tab state plus a cursor-scoped delta since the agent last looked. The round trip costs tens of tokens. Pull rather than push, because no chat host today accepts pushed context, and turn boundaries are when context matters.

4. Authority follows the channel. Some transitions are unavailable to agents as a server-enforced property rather than as policy text. Order confirmation requires the browser session; if the agent's token calls the confirm endpoint, the server returns 403 CHANNEL_REQUIRED. The agent's credentials cannot express confirmation. This generalizes AP2's requirement that mandates be signed on a non-agentic trusted surface, and extends it beyond payments.

Concurrent writes use optimistic preconditions. When the agent, operating on last turn's beliefs, sets a quantity the user has since changed, the write carries expect: qty==1, the server detects the conflict, and the write downgrades to a suggestion rendered in the real UI with Accept and Dismiss. The mechanism dates to Bayou's dependency checks (Terry et al., SOSP '95) and DynamoDB's conditional writes; the novel application is a human and an agent sharing the same live surface. Preconditions are opt-in, as optimistic concurrency always is; a model that never passes expect gets no conflict detection.

Experiments

Shoply ships a measurement harness built for a controlled comparison: one backend, three MCP servers in front of it, and one identical five-task script (search, read cart, add item, update item, checkout) run against each.

The three servers:

• classic: today's norm. Tools return full data as markdown tables; checkout auto-confirms as the agent.

• widget: MCP-Apps style. Same data plus a ui:// template reference.

• tethered: this architecture.

We count only model-visible payload (text + structuredContent) at estTokens = ceil(chars/4). A widget's HTML template and _meta never reach the model, so they are excluded.

The same search re-run over catalogs seeded to three sizes:

What the numbers say:

1. The cost of showing results stops depending on how many results there are. Rendering is linear in result rows; referencing is constant, a count, a few exemplars, and a view handle at any scale. At realistic catalog sizes the gap reaches 100x (103x exact at N=200), and it keeps widening.

2. The savings arrive before scale does. Even at a 12-product catalog, the full five-task workflow drops 49% (464 to 236 estimated tokens).

3. Tokens understate the win. The referenced surface is interactive, so sorting, filtering, and paginating cost zero further model turns, while every refinement of a rendered table costs another round trip.

4. The one task where tethered spends more is the one where it should. Checkout costs 38 extra tokens because the agent can only stage the order; the human confirms in the product, where the Place Order button lives. Consent has a measurable price, and it is small.

Learnings

1. Referencing beats rendering wherever a real interface already exists. The token cost of a reference is flat in result size, the referenced surface is interactive at zero marginal model turns, and state and attribution survive the display detaching. The agent never draws a pixel; it operates the product by reference.

2. Correctness lives in server-side bindings, not in the conversation. Consent enforced by an authentication channel is a guarantee, a 403 the model cannot be talked out of, where prompt text is a request. Context bound to the live session resolves references like "this one" against the current state, eliminating the stale-widget bug class that message binding creates.

3. The control plane outlives the display. Even in a future where models render every pixel, whatever paints them still needs authoritative state, preconditions, and channel-separated authority. And because the architecture is headless-first, links are the entire dependency on the chat host; for B2B products users already pay for and open daily, the aggregator's permission is never required.

References

1. SEP-2567: Sessionless MCP via Explicit State Handles — https://modelcontextprotocol.io/seps/2567-sessionless-mcp

2. MCP Apps Extension (SEP-1865), spec 2026-01-26 — https://modelcontextprotocol.io/seps/1865-mcp-apps-interactive-user-interfaces-for-mcp

3. WebMCP draft, Chrome 149 origin trial — https://developer.chrome.com/blog/ai-webmcp-origin-trial

4. Google A2UI v0.9 — https://developers.googleblog.com/a2ui-v0-9-generative-ui/

5. Chen et al., generative interfaces — https://arxiv.org/abs/2508.19227

6. Google GenUI — https://arxiv.org/abs/2604.09577

7. DOMSteer — https://arxiv.org/abs/2604.14668

8. CI4A ("ARIA for agents") — https://arxiv.org/abs/2601.14790

9. AP2 specification v0.2.0 (Trusted Surface) — https://ap2-protocol.org/specification/

10. Terry et al., Bayou, SOSP '95 — https://dl.acm.org/doi/10.1145/224056.224070

11. CoAgent — https://arxiv.org/abs/2606.15376

12. Electric, "AI agents as CRDT peers" (2026) — https://electric.ax/blog/2026/04/08/ai-agents-as-crdt-peers-with-yjs

13. 12-Factor Agents — https://github.com/humanlayer/12-factor-agents

14. Priompt / Lunnemark, "Prompt Design" (2023) — https://github.com/anysphere/priompt

15. PYMNTS on ChatGPT-app partner economics (2026) — https://www.pymnts.com/news/artificial-intelligence/2026/openai-aims-to-improve-developer-experience-around-third-party-chatgpt-apps/

16. Stratechery, "OpenAI's Windows Play" (2025) — https://stratechery.com/2025/openais-windows-play/