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. Token reduction reaches up to 100x, and the effect is structural. Classic's search cost is linear in result rows. Tethered returns a count, three examples, and a view handle regardless of result size, so its cost is flat. At N=200 the exact ratio is 103x, and it keeps widening with catalog size.

2. Even at a tiny 12-product catalog, the full five-task script drops 49% (464 to 236 estimated tokens).

3. The flat-cost answer is also interactive. The user sorts, filters, and paginates in the real product at zero additional model turns, while every refinement of a static markdown table costs another round trip.

4. Tethered loses exactly one task, by design. Checkout costs 61 tokens against classic's 23 because stage_checkout returns a staged order with confirm_required: true and a consent view, where classic auto-confirms the purchase as the agent. Those 38 tokens buy human confirmation.

Caveats we keep in the paper:

1. These are payload estimates at chars/4, not measured API tokens.

2. Tool-definition tokens are excluded. Tethered surfaces 7 tools to classic's 5, a fixed per-turn cost that favors classic; including it would narrow the totals without changing the scaling shape, since definitions do not grow with data.

3. Widget's savings are partly field trimming rather than rendering offload; its structuredContent carries fewer JSON fields than classic's.

Learnings

1. Referencing beats rendering wherever a real interface already exists. The token cost of a reference is flat in result size, and the referenced surface is interactive at zero marginal model turns.

2. Consent enforced by an authentication channel is a different object from consent requested in a prompt. A 403 is a guarantee the model cannot be talked out of; prompt text is a request the model can be steered around.

3. Binding agent context to the live session eliminates a bug class that message binding creates. References like "this one" resolve against the current state, not against the chat message where a widget happened to render.

4. 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. Pixels are replaceable; handles, rendezvous, and enforcement are not.

5. Distribution concerns weaken for B2B. Users who already pay for a product and open it daily owe the aggregator no permission for this topology, and because the architecture is headless-first, links are the entire dependency on the host.

6. State and attribution survive the display detaching. The UI can close mid-task, the agent keeps operating against the same handles, and every mutation carries its actor. The agent never draws a pixel of the product; it operates it by reference.

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/