AI agents are becoming more than chatbots. They can call tools, execute multi-step workflows, update application data, and pause for human approval. A traditional request-response API can carry a final answer, but it does not provide a consistent way to represent everything that happens while an agent is working. AG-UI (Agent–User Interaction Protocol) addresses this gap.
What is AG-UI?
AG-UI is an open, lightweight, event-based protocol that standardises communication between an AI agent backend and a user-facing application. It is not a UI component library or an agent framework. Instead, it defines a shared interaction layer so a frontend can receive agent messages, progress, tool activity, and state changes without being tightly coupled to one backend implementation.
How does it work?
At a high level, the frontend starts an agent run by sending input such as conversation messages, a thread identifier, and relevant application context. The backend executes the agent and streams structured events back to the client. Implementations commonly use HTTP with Server-Sent Events (SSE), while AG-UI is designed to work with transports such as WebSockets as well.
The client consumes the event stream and updates the interface incrementally. Instead of waiting for one large JSON response, it can render text as it arrives, show tool progress, update shared state, and display when a run has completed.
Important event categories
- Lifecycle events: indicate that an agent run or step has started, finished, or failed.
- Message events: deliver assistant content incrementally, allowing token-by-token or chunk-based rendering.
- Tool-call events: communicate when a tool call starts, receive its arguments, and complete. The UI can show which action is being performed.
- State events: provide a full state snapshot or incremental changes, helping keep frontend and agent state aligned.
- Activity and sub-agent events: expose progress and delegated work so complex workflows are easier to follow.
These typed events make the interaction observable and easier to debug. A frontend can respond to event types rather than parsing framework-specific log messages.
AG-UI, MCP, and A2A
These protocols solve different problems. MCP connects an agent to tools and external data. A2A supports communication between agents. AG-UI connects an agent to the user-facing application. They are complementary: an agent can use MCP tools, delegate work through A2A, and stream its progress and results to a frontend through AG-UI.
Where is it useful?
AG-UI is useful for agentic chat, workflow dashboards, AI-assisted forms, approval experiences, and applications where users need to see or steer an agent while it works. For example, a data-quality assistant could stream profiling progress, show proposed cleaning rules, update a results panel, and request approval before applying changes.
Engineering considerations
Treat incoming events and tool arguments as untrusted input. Validate payloads, enforce authorization on the server, and require explicit human approval for sensitive actions. Design reconnect and error handling around run and thread identifiers, and avoid exposing private internal reasoning. The frontend should render only supported, validated UI actions.
AG-UI provides a common language for the interaction layer of agentic applications. By separating agent execution from how users experience it, teams can evolve their backend frameworks and frontend interfaces with less custom event plumbing.
References: AG-UI documentation · AG-UI GitHub repository · Microsoft Agent Framework integration