The Human-Interaction Layer (AG-UI)
An agent is not a batch job that returns a result; it runs in front of a person — streaming partial work, narrating its tool calls, and pausing for input. The book has already standardized two of the agent's boundaries: agent↔tools (MCP, Ch. 8) and agent↔agent (A2A, Ch. 12). The third — agent↔human — is just as much a protocol, and it is the one most often left as ad-hoc UI glue. This chapter treats the interaction surface as first-class: a typed event stream between the running agent and the front end, of which AG-UI is the emerging open standard and CopilotKit a reference implementation.
13.1 The interaction surface is a protocol, not a screen
From first principles, a run does not produce one response; it produces a sequence over time — token deltas, tool-call starts and results, state updates, status changes, and explicit requests for human input. A front end that renders this needs a stable, transport-agnostic contract for those events, decoupled from any one model, framework, or UI toolkit — otherwise every agent and every client reinvent the wire format between them. That contract is what AG-UI provides: a typed event stream, carried over SSE or WebSockets, describing the lifecycle of a run. It completes a trinity: MCP standardizes the tool boundary, A2A the peer boundary, AG-UI the human boundary. Treating the surface as a protocol rather than bespoke UI code is what lets any compliant front end drive any compliant agent.
| Protocol | Boundary | Standardizes | Representative |
|---|---|---|---|
| MCP (Ch. 8) | agent ↔ tools | Tool discovery, invocation, authorization | MCP servers + gateway |
| A2A (Ch. 12) | agent ↔ agent | Peer discovery, task handoff, delegation | A2A · agent cards |
| AG-UI (this chapter) | agent ↔ human | Streaming events, shared state, human-in-the-loop | AG-UI · CopilotKit |
13.2 What flows across the surface
The event stream carries a small, well-defined vocabulary. Outbound, from agent to human: streamed text (token deltas, where time-to-first-token is the perceived-latency metric, Ch. 18, 29); tool-call transparency (the calls the agent makes and their results, surfaced so the person can see and trust what it is doing); state patches (incremental updates to the shared run state the UI renders); lifecycle and status events; and requests for human input — an approval, a clarification, a choice. Inbound, from human to agent: the responses to those requests, direct edits to shared state, and steering or cancellation. Each inbound event becomes a signal into the durable run (Ch. 4), so the person's action survives restarts exactly as any other input does.
13.3 Generative UI and shared state
The most distinctive capability of a real interaction protocol is bidirectional shared state. Rather than emitting only text, the agent emits structured state that the front end renders into live components — progress, intermediate artifacts, forms, tables — and the person's edits to that state flow back to the agent. This is what AG-UI and CopilotKit call generative UI and shared state: the interface is a live, two-way projection of the agent's working state, not a transcript scrolling past. It is the front-end expression of the steering loop of §5.5 — the human is inside the run, shaping it, rather than waiting at the end of it.
13.4 Human-in-the-loop, from the user's side
Chapter 5 modeled human-in-the-loop as a state the run can pause in (§5.3) and steering as a signal (§5.5); the interaction layer is where those reach the actual person. An approval gate surfaces as an input-request event and resolves when they respond; an interrupt is a steering event mid-run. The interaction surface is therefore the human's window into — and lever on — the running agent, and the place where trust is won or lost, because it is where the person sees what the agent is about to do before it does it. Designing it well (clear tool-call disclosure, easy interruption, legible state) is as much a safety control as a usability one.
13.5 Where it sits, and what it must respect
The interaction layer lives at the edge, between the client and the orchestrator (Ch. 5), as the read/write projection of run state to the human. Because it faces a person, it inherits obligations from the rest of the platform: output streamed to the UI still passes the same guardrails as any other output (Ch. 16) — streaming is not an excuse to skip moderation; the human principal's authorization and the agent's own identity govern the session (Ch. 15); every event is scoped to the tenant (Ch. 26); and the front end is a projection, never the source of truth — the durable run (Ch. 4) is. Operationally it is a streaming-transport problem: SSE or WebSockets, backpressure, reconnection, and resuming a stream against a run that outlived the connection.
The agent↔human surface is a protocol, not a screen. Define a typed event stream — streamed output, tool-call transparency, shared state, and human-input requests — so any front end can drive any agent, the person can steer a run from inside it, and every inbound action becomes a durable signal (Ch. 4). MCP, A2A, and AG-UI are one idea applied to three boundaries: make each edge explicit and contractual rather than bespoke.
Two failures recur. Treating the front end's state as authoritative — rather than a projection of the durable run (Ch. 4) — means a disconnect or a second client silently diverges; the run is the system of record, the UI mirrors it. And streaming output straight to the user without passing it through the same guardrails as any other output (Ch. 16) reopens every safety hole the platform closed elsewhere: moderation and PII handling apply to the token stream too, not only to batch responses.