AG-UI: The Missing Layer Between Agent and Interface

Building the interface for an agent is a different problem from building the interface for an application, and most teams discover this the expensive way — after writing the plumbing themselves, twice.

The difference is that an ordinary interface displays state. An agent interface has to display a process: something running for thirty seconds or ten minutes, producing partial output, calling tools, occasionally needing to stop and ask a question, and sometimes deciding what the user should be shown next.

AG-UI is an open protocol for that connection specifically, and it is worth understanding even if you end up not adopting it, because it is a good description of the problem.

Why request-response does not fit

Consider what has to cross the boundary during a single agent run.

Tokens arrive incrementally and the user should see them as they come. The agent decides to call a tool, and the interface should say so rather than appearing frozen. The tool returns something structured — a table, a chart, a set of options — that is not text and should not be rendered as text. The agent hits something ambiguous and needs the user to choose. The user changes their mind mid-run and cancels. Their connection drops and they reload, and the run is still going.

Every one of those is a different message type with different semantics, and modelling them as REST calls or as an undifferentiated text stream is where the bespoke complexity comes from. Teams end up inventing a private message envelope, a private set of event types, and a private reconnection scheme — and then rewriting all of it for the next project.

What the protocol standardises

AG-UI defines an event stream between the agentic backend and the front end. It runs over HTTP and WebSockets and deliberately does not specify a rendering target, so the same backend can serve a web application, a mobile app, a terminal or a chat platform.

The event categories cover the list above: streaming output with cancellation and resumption, multimodal attachments, generative UI both static and declarative, shared state with conflict resolution, tool calls that may originate at either end, human-in-the-loop interrupts, and composition of sub-agents.

Two of those deserve particular attention because they are the ones teams underestimate.

Shared state with conflict resolution. Both ends can modify state — the agent updates its working set, the user edits a field — and something has to decide what happens when they collide. Left undefined, this produces bugs that are intermittent, user-specific and very hard to reproduce.

Frontend tool calls. Some tools belong on the client: reading the current selection, opening a file picker, accessing something only the browser can reach. Treating those as the same kind of thing as a server-side tool, rather than as a special case bolted on, removes a whole category of awkwardness.

Where it came from, and what that implies

The protocol grew out of CopilotKit's work with LangChain and CrewAI, and has since picked up integrations across more than twenty frameworks — first-party support in Microsoft Agent Framework, Google ADK and AWS Strands Agents, alongside community implementations for Pydantic AI, LlamaIndex and others.

The practical significance of that breadth is portability at the layer most likely to change. Agent frameworks are moving fast and the one you choose this year is unlikely to be the one you run in three. If the interface talks to a protocol rather than to a framework, swapping the backend does not mean rebuilding the front end — and the front end is usually the more expensive half.

When it is worth adopting

Not always. If what you are building is a single chat panel that streams text and nothing else, the protocol is more machinery than the problem needs, and a plain streaming endpoint is fine.

It earns its place when any of the following are true: more than one client consumes the same agent; the agent needs to render structured output rather than prose; the run is long enough that interruption and resumption matter; the agent needs to ask the user something mid-run; or you expect to change agent framework at some point.

That last condition applies to almost everyone, which is the strongest argument for looking at it now rather than after the second rewrite.

The wider point

The interesting thing about AG-UI is not the specification. It is that the industry has converged on the idea that agent-to-interface is a distinct connection with its own requirements — alongside agent-to-tools and agent-to-agent — rather than something each team improvises.

Improvised layers are where projects accumulate their least portable code. Having a standard for this one is straightforwardly good news, whether or not you adopt the standard itself.