Essay · cross-cutting · June 2026

The Interface Is a Contract

In the app era, the interface came from the app. A company designed the screen, shipped the screen, and controlled what the screen could do. The user tapped, typed, dragged, selected, and submitted inside a surface whose shape had been decided in advance. The interface was a place the user visited.

Agents change that bargain.

When a user asks an assistant to compare options, prepare a filing, review a chart, assemble an itinerary, negotiate a purchase, summarize a record, or coordinate several services, text is usually too thin. The user does not just need an answer. The user needs a surface: options to compare, fields to correct, evidence to inspect, warnings to notice, approvals to grant, and actions to commit.

But if the agent can simply make any interface it wants, the system has surrendered too much. A model should not get arbitrary authority to invent executable controls, hide consequential state, bind unsafe actions, or make a screen look trustworthy without the host knowing what the screen means.

That is the problem agent UI contracts solve.

An agent UI contract is an agreement between an agent, a host, an application, and a user about how proposed state becomes visible and how visible controls become action. The agent may propose structure, data, choices, labels, updates, and possible actions. The host decides what gets rendered, how it is styled, what actions are legal, what requires approval, what is logged, and what becomes part of the shared thread.

This is not just a frontend engineering detail. It is where authority moves when the app stops being the primary unit of work.

In an agentic interface, the visible surface is not just presentation. It is a governed artifact: a claim about state, a set of permitted actions, and a promise about who is allowed to do what next.

Text is not enough

The first assistant interfaces were mostly chat. That made sense. Language is the right medium for ambiguity, clarification, instruction, and revision. It lets the user say what they mean before they know exactly what they want.

But coordination cannot stay in prose.

If an assistant is comparing three plans, the user needs a comparison surface. If it is preparing a purchase, the user needs a mandate surface: price, merchant, fees, substitutions, return policy, payment method, shipping, and what exactly will happen if they approve. If it is reviewing a medical or legal record, the user needs traceable fields, source links, missing information, confidence, and explicit boundaries. If several agents are negotiating a schedule, the user needs a visible state of the negotiation rather than a paragraph claiming that everyone agreed.

Text can describe these things. It cannot govern them well.

A paragraph is hard to validate. It is hard to diff. It is hard for another agent to contest field by field. It is hard to attach policy to a sentence. It is hard to know whether the user approved the price, the provider, the date, the substitution rule, or merely the general direction.

The app era solved this by giving every important workflow a fixed interface. The agent era cannot rely on fixed interfaces alone, because the surface often has to be assembled around the task. A trip plan, household repair, insurance appeal, workplace approval, patient intake, or procurement decision may need a custom combination of sources, agents, options, constraints, and approval points.

The answer is not arbitrary generated UI. The answer is structured, contract-bound UI.

The agent proposes. The host executes.

The cleanest agent UI pattern is declarative and host-rendered.

The agent emits a structured object: this is a list, this is a comparison, this is a form, this is a price, this is a warning, this is an action, this is the source behind the claim. The host renders that object using trusted components. The agent chooses composition and values. The host owns execution.

That division is the point.

The agent should have latitude to assemble the right interface for the moment. It may know that this user needs a three-option comparison, that the important columns are cancellation terms and total cost, or that the next step should be an approval card rather than another paragraph. But the agent should not get to write arbitrary code, smuggle in unsafe controls, bypass accessibility rules, or invent action bindings the product never reviewed.

A trusted component catalog creates a narrow waist. Above it, agents can be flexible. Below it, the host can be reliable.

This also makes the interface legible to other participants. A rendered card is not merely pixels. It is a structured object with fields, identifiers, actions, and sources. Another agent can point to the fee field. The user's assistant can object that two options use incompatible assumptions. A policy layer can require extra approval when a card includes money movement, medical advice, or a destructive change. The user can freeze the proposal, share it, revise it, or ask why a field is present.

The surface becomes part of the shared substrate.

That is the difference between a generated screen and a contract.

Claims are not actions

There is a sharper version of that division, and it is the one I most often watch fail in the field. The deepest trust failure in an agentic interface is not an ugly surface — it is an assistant saying it did something it did not do. An agent reports it has started your navigation and put on the music; you believe it for a second; then the road never loads and the car is silent. Trust does not dip, it collapses, because the assistant’s “done” was an interactional act that created reliance, and the world failed to match it. That reads as betrayal, not error.

So a contract over the interface has to include a contract over truthfulness about action state. The surface must keep distinct — and show — the difference between I found an option, I can do this, I am doing this, this is ready for your confirmation, this has been done, and I couldn’t do it. A card can carry those distinctions, but the card is the support; the source of trust is correspondence between the claim and the service’s real state. The contract is not only about inspectable structure — it is about not lying about execution (Against the Everything Assistant).

Rich apps still have a place

Declarative components are not enough for every job.

Some workflows need a richer embedded application: a chart explorer, design tool, trace viewer, simulation, document editor, map, media tool, or multi-step configuration surface. In those cases, a server-owned app surface inside the assistant can be the right answer. The host provides sandboxing, lifecycle, permission boundaries, and communication channels. The app provides the specialized experience.

This is a valid contract too, but it has a different risk.

The risk is semantic enclosure. The user can see the embedded app, but the assistant and the broader thread may only see whatever the app chooses to report back. The important state can disappear into private UI state: the selected row, edited filter, dismissed warning, adjusted threshold, chosen quote, or pending approval. If that state never returns to the shared context, the conversation becomes blind to the thing the user just did.

The fix is not to stream every click into the model. That would flood the thread with noise and create its own privacy problems. The fix is to identify meaningful moments.

At those moments, the app should emit structured state back to the host and, when appropriate, into the model-visible thread. The assistant does not need a transcript of every mouse movement. It does need to know that the user approved option B at this price under these constraints using these sources.

Rich app surfaces work when they remain accountable to the shared thread. They fail when they become beautiful pockets of state that no one else can inspect.

This family is standardizing as we speak: the open tool protocol now carries an apps extension in which a server can return a renderable surface while the host owns the sandbox, the lifecycle, and the capability negotiation — and in which model-facing content, render-only data, and explicit context updates travel on separate channels. That channel separation is the mirroring discipline, written into a spec.

Automation is the fallback, not the ideal

The third family is different. Sometimes there is no structured interface, no official tool, no trusted component contract, and no embedded app surface. There is only an existing website or legacy application built for humans.

Then the agent may have to operate the UI itself.

This is powerful and necessary. The world will not expose clean agent contracts all at once. Real work lives in old portals, dashboards, carts, forms, inboxes, record systems, booking engines, spreadsheets, and administrative tools. Agents need a way to act where the world still expects a human clicking through a screen.

But UI operation carries the highest governance burden.

A browser-driving agent is crossing into logged-in accounts and real consequences. It may read private data, fill forms, move money, place orders, send messages, change records, accept terms, or expose information to third parties. The semantics are often inferred from pixels, markup, labels, and learned habits rather than declared by the service itself.

That means the product cannot treat automation as just another tool call.

The session should be visible. Credentials should be scoped. Write actions should require approval. The user should know whether the agent is using an official contract, a structured fallback, or a brittle human-facing interface. The audit trail should record what was seen, what was clicked, what was submitted, and under whose authority.

“Under whose authority” deserves its own line, because the first shipped team agents have already answered it: the agent acts as itself, under its own scoped identity and credentials, rather than borrowing the user's. That is what keeps a shared surface from becoming a side door into someone's private documents — and it belongs in the contract for every one of these families, not only automation.

Automation is the necessary bridge to the existing web. It is not the final form of agentic UI.

The long-term goal is not to make agents better at pretending to be humans trapped in old screens. It is to give agents structured, governable surfaces so humans can supervise the actual work.

The proposal card is the new unit

The most important place this shows up is the forum.

In a visible multi-agent forum, agents do not merely talk. They post proposals.

A travel agent posts an itinerary proposal. A merchant agent posts an offer. A household agent posts a maintenance plan. A workplace agent posts an approval packet. A service agent posts a repair window. The user's assistant compares, questions, challenges, and summarizes. The human decides what to accept.

For this to work, proposals need to be structured artifacts, not conversational vapor.

A proposal card should have fields. It should have a speaker. It should have sources. It should say what is firm, what is estimated, what expires, what is missing, what action it invites, and what authority the agent has. It should be possible to compare two cards, cite a field, revise a constraint, contest a claim, and preserve the accepted version.

This is why agent UI contracts are central to forum commerce and not just to developer tooling.

If every participant contributes only prose, the user's assistant becomes the sole interpreter. It must translate each agent's claims into its own private comparison. That restores the single-assistant bottleneck the forum is meant to escape. Other participants cannot easily contest the translation. The user cannot see the underlying action space.

But if participants post typed proposal artifacts, the forum has shared objects. Agents can compete and collaborate against the same visible state. Bias, sponsorship, fees, omissions, and tradeoffs become inspectable. The user's assistant can still referee, but it does not have to hide the game.

Pointing in, rendering out

Agent UI contracts also pair naturally with deictic input: pointing, selecting, circling, highlighting, or saying “this” while referring to something on screen.

Pointing solves the input side of the problem. It binds the user's words to visible context. This chart. That fee. This row. The error in this panel. The product I just circled. The paragraph under my cursor.

UI contracts solve the output side. Once the agent understands the referent, what can it put back in front of the user? A correction card. A comparison table. A set of action chips. A source-backed explanation. A safe edit preview. A private handoff. A request for approval.

The two belong together because both are about making context explicit.

Without deictic input, the user has to over-describe the visible world in language. Without UI contracts, the agent has to answer back in prose or operate the screen procedurally. A mature agent surface should let the user point at a thing, then let the agent produce a governed surface about that thing.

That is not ambient magic. It is explicit reference and explicit return.

The user shows what they mean. The system shows what it understood. The host limits what can happen next.

Who owns the renderer?

There is a political question hiding inside the engineering.

Who owns the renderer?

If the operating system or browser owns the component catalog, it can decide what kinds of agent work become first-class. If each service owns a fully embedded app surface, it can preserve brand control but trap semantics away from the broader thread. If the assistant provider owns the whole interaction layer, it can quietly become the gatekeeper between the user and every other participant. If every agent drives legacy websites by automation, the user gets reach but little durable structure.

None of these positions is neutral.

The renderer is a governance surface. It decides which controls exist, which actions require approval, which provenance is shown, which participants can post artifacts, which proposals are comparable, and which state becomes part of the record. It can make a forum legible, or it can collapse the forum back into one assistant's private synthesis.

This is why the right architecture is layered.

Tool protocols should expose capabilities and context. UI contracts should expose structured surfaces and actions. Control layers should handle identity, permissions, approvals, audit, and cancellation. The forum should preserve speakers, proposals, and provenance. No one layer should pretend to be the whole system.

The point is not to abolish apps. It is to demote the app from the only place work can happen to one participant in a larger interface ecology. Some work stays inside the service's own surface. Some work appears as structured cards in the forum. Some work requires a rich embedded app. Some work falls back to visible automation. The user should be able to tell which kind of surface they are in.

Design rules for agentic UI

A useful agentic interface should follow a few rules.

First, treat UI artifacts as claims. A card, table, form, chart, or approval panel should carry enough structure to say who produced it, what it asserts, where the data came from, and what action it invites.

Second, keep execution authority outside the model. The agent can propose actions. The host or application binds those actions to real effects under typed rules, validation, and approval gates.

Third, distinguish display from commitment. Showing a price, option, or draft is not the same as accepting it. The interface should make the path from inspection to commitment explicit.

Fourth, emit high-signal state back to the shared thread. The system does not need every UI twitch, but it does need decisions, approvals, rejections, constraint changes, submitted values, and accepted artifacts.

Fifth, expose the fallback rung. The user should know whether an agent is using a first-class contract, a sandboxed app, a structured manifest, a public website, or procedural browser control. Confidence should track the surface.

Sixth, make proposal artifacts contestable. Other agents and the user's assistant should be able to challenge a field, request evidence, flag incompatible assumptions, and compare alternatives without reverse-engineering screenshots.

Seventh, preserve human interruption. Cancel, pause, edit, inspect, and revoke are not decorative controls. They are part of the contract that makes agent action supervisable. And approval is itself a surface: once agents run long tasks, the pending question need not live in the agent's window — a phone, a notification, even a small desk peripheral can carry it. The host preserves authority by keeping approval visible wherever the user actually is.

Eighth, design for accessibility and durability. Host-rendered components should inherit the accessibility, localization, responsiveness, and logging discipline of the application, not depend on whatever layout a model improvised that turn.

These rules make the interface less magical. That is the point. The more consequential the action, the less magical the interface should feel.

After the screen

The app era taught users to think of software as places. Open the app. Enter the workflow. Complete the task. Leave.

The contract also survives the coming diversity of hardware. If the agent declares and the host renders, then a watch, a badge, a desk device, and a desktop can each render the surface its form factor affords — the just-in-time interface the agent-first device platforms are now betting on is the hardware corollary of the narrow waist. The contract is about what is proposed and what may happen next; the rendering layer is interchangeable.

The agent era makes that model porous. The user may begin in a thread, point at a screen, invite a service agent, inspect a proposal card, open a rich embedded tool, approve a state change, and return to the shared record. The work moves across surfaces. The continuity is not the app. The continuity is the governed thread of state, action, and accountability.

That is why agent UI contracts matter.

They are the missing interface layer between fluent conversation and real-world action. Without them, assistants either stay trapped in text, generate unsafe interfaces, hide work inside embedded apps, or click through human screens with too little structure. With them, agents can materialize the right surface at the right moment while the system preserves control.

The future interface is not a single chat box. It is also not a return to static apps.

It is a forum of participants, proposals, tools, and approvals, where surfaces appear because the work needs them and where each surface carries a contract: who made this, what does it mean, what can happen next, what will be remembered, and who can stop it.

After the app, the interface is no longer just where the user acts.

It is where agents become accountable.

← All essays