Skip to content

CHAP vs AG‐UI

Jump to bottom
Arsalan Shahid edited this page Aug 25, 2026 · 3 revisions

AG-UI connects an agent backend to a user-facing application. CHAP gives the work and decisions moving through that interface portable accountability semantics.

Short answer

AG-UI and CHAP overlap at the human-in-the-loop moment, but they approach it from different layers.

AG-UI is an event-based protocol for agent-user interaction. It supports streaming output, shared state, frontend tools, human interrupts, agent steering and UI-oriented events. It helps an application present and control a responsive agent experience.

CHAP is a collaboration and evidence protocol. It represents participants, workspaces, tasks, artefacts, reviews, decisions, overrides, escalation and an append-only evidence chain. It does not specify how an approval dialog should look or how tokens should stream to the browser.

A strong implementation can use AG-UI for the live interface and CHAP for the accountable record.

Comparison

Question AG-UI CHAP
Primary job Connect agent backends to user-facing applications Standardise accountable human-agent work
Main boundary Agent backend and frontend Humans, agents and services in a workspace
Data shape Event stream, messages, state updates, tool events and UI intent Signed envelopes, tasks, artefacts and decisions
Human-in-the-loop Pause, approve, edit, retry or escalate in the live experience Review, approve, reject, override, abstain, escalate and handoff semantics
UI rendering Central concern Out of scope
Streaming Central concern Transport-dependent, not the defining concern
Persistence Chosen by the application and integration Evidence chain and audit methods are protocol concepts
Human edit Can flow through shared state or tool results Can become a structured override with diff, rationale, tags and intent
Best composition Render and collect a CHAP decision Supply the durable meaning behind an AG-UI interaction

Why the overlap matters

AG-UI documentation includes human-in-the-loop interrupts that can pause, approve, edit, retry or escalate without losing state. Those verbs are close to CHAP's decision vocabulary. This creates a useful integration point, not a reason to choose one protocol and reject the other.

An interface event answers: what should the application show or do now?

An accountability envelope answers: what work was proposed, who decided, what changed, why did it change, and how can the sequence be verified later?

The same user action can generate both.

A composition pattern

Consider a customer-support agent that drafts a refund response.

  1. The backend creates a CHAP task and records the draft artefact.
  2. It emits review.request for the support specialist.
  3. AG-UI streams the draft and review controls to the frontend.
  4. The specialist approves, edits, rejects or escalates in the application.
  5. The backend validates the response and maps it to the corresponding CHAP method.
  6. An edit becomes decide.override with a structured patch and rationale.
  7. AG-UI updates shared state and continues the experience.
  8. CHAP retains the decision evidence independently of the transient UI session.

No duplicate decision is needed. The AG-UI event and CHAP envelope are two views of the same application action, with separate responsibilities.

Mapping interactions carefully

Interface action Possible CHAP meaning Important qualification
Approve decide.approve Only if the presented artefact is unchanged
Edit and continue decide.override Preserve the original, revised value, diff and rationale
Reject decide.reject Distinguish policy rejection from malformed input or cancellation
Escalate escalate.raise Identify destination or required authority where policy permits
Retry No automatic one-to-one mapping It may be rework, a new task attempt or an operational retry
Cancel UI No automatic one-to-one mapping Closing a dialog is not necessarily a business rejection

This table shows why blindly translating event names is risky. Interface intent must be interpreted in the task and policy context.

Shared state is not the same as an evidence chain

AG-UI shared state is useful for a responsive application. It lets the agent and frontend stay synchronised as work changes. That state may be persisted and event-sourced by an implementation.

CHAP evidence focuses on protocol-level attribution and sequence. A reviewer should be linked to the exact artefact and authorised decision, and a later verifier should be able to inspect the hash-linked history.

An application may store both in the same database, but their logical purposes remain distinct. UI state supports interaction. Decision evidence supports accountability.

What CHAP should not do in this stack

Do not force CHAP to carry token deltas, visual layout, every hover event or all frontend state. That would turn an accountability protocol into an inefficient UI transport.

Record the consequential boundary:

  • The proposal became reviewable.
  • A participant made a decision.
  • The accepted artefact changed.
  • Work was handed off or escalated.
  • An external action was invoked or completed.

Keep presentation details in AG-UI and application telemetry.

Identity, retries and privacy

The backend should bind the authenticated application user to the correct CHAP participant. Never trust a participant identifier supplied only by browser state.

Use stable identifiers or idempotency keys so reconnects and event retries do not create multiple CHAP decisions. Define which system is authoritative if the interface reports success but the CHAP write fails.

Avoid copying sensitive shared state into the evidence chain. Where appropriate, retain an opaque reference and content hash rather than the full payload.

When to use each

Use AG-UI alone when you need a rich, interoperable agent interface and application-specific persistence is sufficient.

Use CHAP alone when an existing interface or non-interactive system already transports the work, but you need standard collaboration and evidence semantics.

Use both when a live user-facing agent performs consequential work that must be reviewed, modified or traced across more than one application or organisation.

Related pages

Primary sources

If you are connecting AG-UI to an accountable workflow, star CHAP and describe the event mapping you need in Discussions.

Last reviewed: 25 August 2026.

Clone this wiki locally