AG-UI: an event protocol for wiring agents into a frontend

The gap AG-UI fills between an agent loop and a screen

An agent backend produces a stream of intermediate work: a token, a tool call, a state patch, a request for human approval. A frontend needs those as discrete, typed messages it can render and respond to. In most projects that translation is hand-written, once per app, and it drifts as the agent changes. AG-UI defines the message vocabulary instead, so the backend emits events and the app consumes them without a bespoke adapter for every pair.

The README positions it against two other protocols rather than against them: MCP gives agents tools, A2A lets agents talk to other agents, and AG-UI brings agents into user-facing applications. That framing is the clearest statement of scope in the repository. The audience is therefore teams that already have an agent and now need it inside a product surface, not teams looking for an agent framework or a chat component set.

Sixteen event types, a middleware layer, and any transport

The mechanism is narrow on purpose. During an execution, the agent backend emits events compatible with one of roughly 16 standard event types, and it accepts a few simple AG-UI compatible inputs as arguments. The README calls this loose event format matching, which means the protocol does not demand byte-exact payloads before two sides can interoperate.

Between the two ends sits a middleware layer. Its stated jobs are transport independence (SSE, WebSockets, webhooks) and tolerance of format variation. A reference HTTP implementation and a default connector ship alongside the spec so a first integration does not start from a blank file. The repository layout matches that story: sdks/, integrations/, middlewares/ and apps/ are separate top-level directories, so the protocol definitions, the per-framework adapters and the runnable demos are versioned independently under one Nx workspace.

The trade-off is visible in that same looseness. Loose matching makes heterogeneous backends easier to connect, and it also means two AG-UI implementations can both be compliant while disagreeing about a field's shape. The README does not document a conformance test suite, so interoperability in practice rests on the reference implementation and the middleware rather than on a checked contract.

Installing AG-UI and running a first app

The README's getting-started path is a single scaffold command. It creates a new application directory named my-agent-app in the current working directory:

npx create-ag-ui-app my-agent-app

After it finishes you have a project wired to the AG-UI packages rather than an empty folder. From there the README points to the quickstart for applications and to the AG-UI Dojo for runnable demos; the Dojo is where the shared_state feature demos for LangGraph, CrewAI and the other integrations live, so it is the fastest way to see what an event stream looks like in a browser before writing your own backend.

If you are contributing an integration rather than an app, the repository is a pnpm and Nx workspace, and the root package.json exposes the build and dev entry points:

pnpm install
pnpm run build
pnpm run dev:integrations

The first builds every project in the workspace, the second builds the integrations packages and then watches them, which is the loop you want while editing an adapter. The same file provides create-integration for scaffolding a new one. None of this is needed to consume AG-UI from an application; it is the path for working inside the repository itself.

Where the protocol gets in the way

The clearest limitation is what the README does not cover. It lists bi-directional state synchronization as a feature and never explains the reconciliation rule. If the agent and the user both modify the same piece of state, nothing in the README says which write wins, whether patches carry a sequence number, or whether the client is expected to re-send its state after a conflict. That is the first thing to read in the spec before building on shared state, because it determines whether you need your own conflict handling on top.

The second is versioning. The repository publishes frequently, with releases on 2026-09-08, 2026-09-09 and 2026-08-31, and the npm badge in the README tracks @ag-ui/core. Nothing in the README describes how a client and a server negotiate which protocol revision they speak, so a frontend built against one release and a backend on another is an untested combination as far as the documentation goes.

AG-UI is also the wrong tool in two common situations. If your agent and your UI live in the same process and you control both, a direct function call or an in-process stream is simpler than serializing events over a transport. And if you need rendered components rather than a message contract, AG-UI will not supply them; the generative UI feature describes structured messages, not a component library.

AG-UI compared with MCP, A2A and CopilotKit

The comparison the README itself draws is with MCP and A2A, and it is a division of labor rather than a competition: MCP exposes tools to an agent, A2A carries agent-to-agent traffic, AG-UI carries agent-to-interface traffic. A project can use all three, and the event types in AG-UI are not a substitute for either of the others.

The more interesting comparison is with CopilotKit, which the README names directly. AG-UI grew out of CopilotKit's partnership with LangChain and CrewAI, and CopilotKit appears throughout the integration docs as the frontend side of the story. The difference in approach is that CopilotKit is a product layer you install into an application, while AG-UI is the protocol underneath it. If you want a working assistant in a React app with minimal protocol work, the product layer is the shorter path. If you are building your own frontend, or a second frontend against the same backend, the protocol is the part that stays constant when the UI framework changes.

Maintenance, licensing and the cost of moving versions

The repository is not archived and the last push was on 2026-09-10, one week before this writing, with three releases in the preceding two weeks. That is a fast cadence and it has a direct cost: the workspace builds all SDK packages together, and the publish scripts in the root package.json run a clean, a fresh install and a full build before publishing the TypeScript packages. Consuming from main means tracking that cadence.

The licence is MIT, stated in the README badge and present as a LICENSE file at the repository root. MIT permits commercial use and modification with the copyright notice retained; the practical implication for adopters is that the protocol text and the reference implementation can be vendored into a private codebase. That is a permission, not legal advice, and the usual caveat applies: if you modify the spec or the SDKs and redistribute them, the notice obligation is yours to satisfy.

Integration status is worth reading carefully before you plan around it. The framework tables mark most entries as Supported, but AWS Bedrock Agents is listed as In Progress, and the distinction between 1st party, Partnerships and Community entries is about who maintains the adapter, not about protocol coverage.

Editorial conclusion

Adopt AG-UI if you already have an agent backend and need a defined event contract between it and a user-facing app, especially if your framework appears in the supported integrations table. Do not adopt it expecting a rendering layer: the README lists chat streaming and generative UI as features, but no component library. Before committing, verify three things in the repository: the middleware behavior when an emitted event does not match one of the roughly 16 standard types, how shared state is reconciled when the client and the agent both write, and whether the protocol version is carried in the payload or negotiated out of band. The last push was on 2026-09-10, so the code is moving; pin a release tag rather than tracking main.

Frequently asked questions

Official sources

1. ag-ui-protocol/ag-ui on GitHub
2. License: MIT
3. Project website
4. README
5. Releases