What is AG-UI? The Agent-User Interaction protocol

One request in, a stream of events out

The 1.0 specification puts the protocol in one line: “one request in, one ordered stream of typed events out, carrying everything the user sees of the agent.” The request is a RunAgentInput, posted to the agent’s endpoint. It names the conversation (threadId) and this turn (runId), carries the message history, and can add the app’s own tools, extra context, the state the last run left behind, and answers to anything the last run asked. The reply is a text/event-stream with exactly one JSON event in each frame. The HTTP binding’s own example:

POST /agent HTTP/1.1
Content-Type: application/json
Accept: text/event-stream

{"threadId":"thr-1","runId":"run-1","messages":[…]}

HTTP/1.1 200 OK
Content-Type: text/event-stream

data: {"type":"RUN_STARTED","threadId":"thr-1","runId":"run-1"}

data: {"type":"TEXT_MESSAGE_START","messageId":"msg-1","role":"assistant"}

data: {"type":"TEXT_MESSAGE_CONTENT","messageId":"msg-1","delta":"Hello."}

data: {"type":"TEXT_MESSAGE_END","messageId":"msg-1"}

data: {"type":"RUN_FINISHED","threadId":"thr-1","runId":"run-1"}

Everything else the agent can say fits one of the eight families:

Most explainers, the protocol’s own GitHub README among them, still say AG-UI has about 16 event types and runs over SSE or WebSockets. That describes the 0.x protocol. In 1.0, HTTP with Server-Sent Events is the binding every HTTP implementation must support, a binary binding (the same POST, answered with length-prefixed protobuf frames) is optional, and WebSockets, message buses and in-process pipes are custom transports that must keep the same ordering and termination rules. 1.0 also added run outcomes, interrupts, subagents and activity events, and renamed thinking to reasoning. A 0.x agent keeps working against a 1.0 client, which translates the retired shapes as they arrive.

What the agent and the app each implement

The agent side is an HTTP endpoint plus a bridge that turns a framework’s native events into protocol events. The spec keeps that bar low on purpose: “The mandatory surface is the run lifecycle and nothing else,” so an agent that emits a start, some text and a finish conforms. Most people never write this part, because the frameworks listed below ship the bridge, and since the protocol carries no framework concepts, one app can face any of them.

The app side carries more. It sends the input, renders the stream, runs the frontend tools it offered (a confirmation card, a map, anything the agent may ask the app to do), keeps the shared state, and, in the architecture page’s words, “decides what requires the user’s consent.” It has to accept every event family even if it ignores some, must not treat an HTTP 200 as success (a failure after the stream opens arrives as RUN_ERROR), and must not report a run as finished when the connection dropped before RUN_FINISHED.

Runs never pause. When an agent needs an approval or a choice mid-task, the run ends with an interrupt naming what it is waiting for, and the app’s next request carries the answer. The interrupt rules say why: “The protocol has no mid-run channel from the consumer, so the run does not wait.” A conversation is a thread of such runs.

What the spec leaves out is as telling. It does not define how a UI renders anything or how an agent framework is built, and it defines no credential: authentication is “a property of the binding and the application, not of the protocol.” AG-UI is the pipe. CopilotKit’s MIT-licensed components and runtime are one front end built on it, with three first-party SDKs behind the protocol itself (TypeScript, Python and .NET) and community ones for Kotlin, Go, Dart, Java, Rust, Ruby and C++.

AG-UI, MCP, A2A and ACP: which connection each one is

The four get named together because one agent can speak all of them at once. They differ in who is on the other end:

MCP shapes what an agent can do, A2A lets it hand work to other agents, and AG-UI’s docs describe handshakes that let an AG-UI app “front for” agents reached through MCP and A2A, so the layers stack rather than compete. The useful line is between AG-UI and the Agent Client Protocol. An ACP editor launches the agent on the same machine and talks to it over stdin and stdout; its HTTP transport is still a draft proposal. AG-UI assumes the agent is a service somewhere else. If yours lives on another computer and you want it in a browser tab or on your phone, AG-UI is the one shaped for that.

Two near-names cause most of the confusion, and AG-UI’s introduction carries a warning about the first. A2UI, started at Google, is a format for interface an agent wants drawn (cards, forms, buttons as a declarative component tree), and MCP Apps is the MCP extension for interactive UI from tool servers. Both are payloads; AG-UI is a pipe that can carry them, and A2UI can travel inside its activity events. AG2, formerly AutoGen, is an agent framework that happens to support AG-UI.

Who supports it (checked October 2, 2026)

Each of these is confirmed in the framework’s own docs, not only in AG-UI’s list:

• Microsoft Agent Framework: .NET (MapAGUIServer), Python (agent-framework-ag-ui) and Go, per its AG-UI integration page.
• Google’s Agent Development Kit: “Supported in ADK Python, TypeScript, Go, Java,” per ADK’s docs.
• LangChain: Deep Agents expose AG-UI directly; LangGraph agents reach it through CopilotKit’s middleware.
• CrewAI: Flows served over AG-UI, including its session-aware conversational Flows.
• Pydantic AI (the ag-ui extra), Mastra (@ag-ui/mastra), Agno (an AG-UI interface on AgentOS at POST /agui) and AG2 (AGUIStream).

On AG-UI’s own list only: Amazon Bedrock AgentCore, marked supported; community bridges for Anthropic’s Claude Agent SDK and Claude Managed Agents, and OpenAI’s Agents SDK and Cloudflare Agents marked in progress. The clients it lists are CopilotKit for the web, a React Native example, a terminal client, Slack and Microsoft Teams through CopilotKit’s Channels SDK, and, in the protocol’s repository, a Kotlin chat app that runs on Android, iOS and desktop. Thoughtworks’ Technology Radar placed AG-UI in Trial in April 2026.

OpenClaw, Hermes and OpenMuse

OpenClaw has no AG-UI support in its docs or code. One of AG-UI’s creators opened a pull request on July 16, 2026 adding a bundled AG-UI channel; OpenClaw’s automated review asked maintainers for “an explicit product and security decision” on bundling “this new browser-facing Gateway protocol,” recommending an external plugin instead, and the PR was closed unmerged for inactivity on September 9. What exists is clawg-ui, a community plugin (openclaw plugins install @contextableai/clawg-ui) that adds a /v1/clawg-ui route to the Gateway and hands each AG-UI message to OpenClaw’s normal reply pipeline, so an AG-UI app becomes one more channel, like Telegram. Its latest release, 0.7.0, dates from April 29, 2026 and is built on AG-UI’s 0.x packages.

Hermes has none either. Its AG-UI adapter, pull request #65845 from the same AG-UI co-creator, has been open since July 16, 2026 and carries a needs-decision label; it would add an agui section to config.yaml and a hermes agui command. A second, community PR has been open since August 8. Hermes does speak ACP, for editors.

OpenMuse is where September’s attention came from: announced on September 22 as “an open source, self-hostable personal assistant that works with any agent harness.” Built by CopilotKit and MIT-licensed, it is an app for iOS, Android and the web with chat, a persistent browser, an optional Linux workspace, tasks and goals. Given a model, it runs CopilotKit’s built-in agent on an OpenAI, Anthropic or Google key. The “any harness” part is one setting: AGENT_BACKEND=agui with an AGENT_URL and AGENT_TOKEN hands its chat to an external AG-UI endpoint (the comment beside it says this “replaces conversational routing only”), which for OpenClaw today means clawg-ui and for Hermes means the unmerged adapter. Two things its README states that the announcement did not: it is an alpha, and every mode needs a CopilotKit Intelligence project key, the service that stores its chat threads, which CopilotKit runs in its cloud or you host yourself on Kubernetes or AWS ECS.

Reaching an agent on its own computer from a phone or web app

This is the arrangement AG-UI is designed around: the agent is a service, and the app is somewhere else. What it asks of you is an HTTP endpoint the app can reach, and every decision about who may use it.

• Authentication is yours. The protocol defines no credential. CopilotKit’s docs for apps that connect to an agent directly put it plainly: “Your agent endpoint must authenticate and authorize every request.”
• A token that starts runs is an owner’s key. Whoever can start a run can do whatever the agent can, and an agent with a terminal, a browser and your accounts can do a lot. OpenClaw’s docs say this of its own HTTP endpoint, which drives the agent the same way: treat it “as full operator access” and “Keep it on loopback/tailnet/private ingress only.” A credential per device is safer than one shared secret: clawg-ui refuses the Gateway’s master token and instead pairs each app, which you approve with openclaw pairing approve clawg-ui <code>, the same pairing a new chat sender goes through.
• Keep the token out of the browser where you can. Web apps usually put a server in between: CopilotKit’s open-source runtime takes the page’s request and forwards each run to the agent server-side, so the agent’s credential never ships in page code. OpenMuse describes its own setup as one owner behind a shared access key, “not a multi-tenant authentication system,” and asks for HTTPS and restricted network access on a remote host.
• A private network is the simplest boundary. If the app only runs on your own devices, an endpoint reachable only on your tailnet is invisible to the internet; a public URL needs authentication at the edge before anything reaches the agent. The trade-off between the two is in Tailscale vs Cloudflare Tunnel, and why the Gateway itself stays off the open internet is in the Gateway exposure guide.
• What comes back is untrusted. The spec’s security section: “Model output is untrusted input.” Apps must validate what they act on, must not render streamed content as executable markup, and should ask before running tool calls with side effects, because an agent that reads the web can be steered by what it reads.

Two properties matter more on a phone than at a desk. A run lives inside one HTTP response, and the SSE binding has no resumption: if the connection drops mid-run, “the producer may have kept going, but this consumer will never see the rest,” and trying again is a new run. And every exchange is opened by the app, since the input is the only message that travels in that direction. Our reading of the 1.0 spec is that an agent cannot start a conversation over plain AG-UI: a morning report reaches you only if the app asks for it or adds a notification channel of its own. CopilotKit’s separate Intelligence service fills part of that gap with runs you can reconnect to, from another device too; OpenMuse keeps its own task worker and in-app notifications, with device push on its roadmap. An agent on a chat app such as Telegram has no such gap: it can write to you first.

One more fit question for personal agents. AG-UI was shaped around apps that hold the conversation: every request carries the thread’s complete history, and the protocol has no other channel through which earlier turns arrive. OpenClaw and Hermes keep their own sessions and memory on their own disk, so as we read it, a bridge for them has to map an AG-UI thread onto the agent’s session rather than replay the app’s copy. clawg-ui does it by routing each message through the Gateway like any channel message; the closed OpenClaw PR kept a session per conversation.