Comparison
UHP vs AG-UI
UHP standardizes execution through configured complete harnesses; AG-UI standardizes how user-facing applications exchange run input and events with agents. They address different boundaries and can be composed.
The short version
Section titled “The short version”UHP and AG-UI standardize different interoperability planes. UHP 2026-09-12 defines a client-to-server contract for selecting, configuring and executing a complete agent harness. AG-UI defines an application-to-agent interaction contract: a user-facing application sends a run input and consumes an event stream for messages, tools, state, lifecycle and interactive continuation.
A product can therefore use both. A frontend could speak AG-UI to an agent-facing application layer while that layer uses UHP to run the selected underlying harness. The reviewed primary sources do not define a standard AG-UI↔UHP binding, and no native AG-UI surface in HarnessRouter was verified at this cutoff.
Maturity boundary
Section titled “Maturity boundary”AG-UI’s repository describes it as the Agent-User Interaction Protocol, an open event-based protocol for connecting agents to user-facing applications. Its current specification material is explicitly marked draft, not yet ratified, describing intended 1.0 behavior without a compatibility promise until a version is frozen.
That status matters when comparing versions. The TypeScript package @ag-ui/core is currently 0.0.59 in the checked source tree, but that package version is not a ratified AG-UI protocol 1.0 version. The repository also publishes dated package release trains; the latest observed release at this cutoff is release/2026-09-11.
Boundary comparison
Section titled “Boundary comparison”| Dimension | UHP 2026-09-12 | AG-UI intended 1.0 draft |
|---|---|---|
| Primary boundary | Product/client ↔ UHP server ↔ configured complete harness | User-facing application ↔ agent/runtime |
| Main unit | Harness execution, configuration, session and response surfaces | Run input plus producer→consumer event stream |
| Identity | Harnesses, responses, sessions and server resources | threadId, runId, optional parentRunId |
| Input | UHP request surfaces select/configure the harness and execute work | RunAgentInput requires thread, run and messages; may include context, tools, state, protocol version and resume data |
| Tools | Harness-owned runtime/tool configuration, including MCP and optional Harness Plugins | Frontend tools advertised by the application and executed on the application side |
| State | Session/resource state is owned by the UHP server/harness boundary | Shared application/agent state can be supplied and synchronized through protocol events |
| Interrupt / resume | Harness/session lifecycle through UHP’s execution model | Draft input includes resume data for interrupted interactive runs |
| Versioning | Date-stamped UHP versions; current draft is 2026-09-12 | Draft proposes in-band protocolVersion negotiation and future frozen MAJOR.MINOR identifiers |
| UI semantics | UHP is not a user-interface protocol | AG-UI directly targets user-facing interaction, including streaming and generative UI patterns |
| Current standard status | Published UHP Draft with conformance package 2026.9.12 | Intended 1.0 draft; not yet ratified |
What AG-UI standardizes
Section titled “What AG-UI standardizes”The current draft uses one RunAgentInput to open an exchange. threadId, runId and messages are required; optional fields include parentRunId, protocolVersion, frontend tools, context, state, forwardedProps and resume.
The frontend-tool distinction is important. AG-UI describes tools in RunAgentInput as tools provided and executed by the application, not the agent backend. That is a different ownership boundary from configuring a complete harness or its MCP servers under UHP.
AG-UI also makes event finality visible. Its ecosystem uses lifecycle events such as RUN_STARTED, RUN_FINISHED and RUN_ERROR, alongside message, tool and state events. The repository’s own current integration tests explicitly distinguish a surface rendering from a run actually reaching RUN_FINISHED; this is application/agent event-stream finality, not UHP response conformance.
Version negotiation is different
Section titled “Version negotiation is different”UHP uses a date-stamped protocol coordinate and a matching conformance package. AG-UI’s intended-1.0 draft instead describes in-band negotiation: the application may send RunAgentInput.protocolVersion, and the producer can report the negotiated version on RUN_STARTED.protocolVersion.
The draft also defines compatibility rules around additions and downgrade behavior: older peers should tolerate unknown additions, while a lossy downgrade should be surfaced rather than silently pretending equivalence. These are draft semantics until AG-UI freezes a version.
How it relates to MCP and A2A
Section titled “How it relates to MCP and A2A”AG-UI’s first-party project description places it beside two other planes: MCP gives agents tools, A2A connects agents to agents, and AG-UI brings agents into user-facing applications. That model is useful, but UHP adds another distinct boundary: complete-harness execution and lifecycle behind a stable server contract.
A practical stack can therefore contain all four without treating them as substitutes:
- AG-UI for application/user ↔ agent interaction.
- UHP for application/service ↔ complete harness execution.
- MCP for agent/harness ↔ tools and context servers.
- A2A for agent ↔ remote agent collaboration.
The exact composition is implementation-specific. A translation layer between AG-UI and UHP would need explicit mappings for run/session identity, message and tool events, state, cancellation/finality and error semantics. No reviewed source establishes that mapping as a standard today.
What not to infer
Section titled “What not to infer”- AG-UI support in a framework does not imply native UHP support.
- UHP conformance does not imply AG-UI compatibility.
@ag-ui/core 0.0.59is an SDK coordinate, not a ratified protocol version.- AG-UI’s intended
1.0draft should not be cited as a frozen compatibility contract. - The presence of MCP middleware inside the AG-UI repository does not merge MCP and AG-UI into one protocol boundary.
- No native HarnessRouter AG-UI endpoint or UHP↔AG-UI adapter was verified in the reviewed HarnessRouter
a7406cbdtree.
Primary sources
Section titled “Primary sources”- AG-UI repository overview at checked main
74793369 - AG-UI draft-status banner
- AG-UI draft
RunAgentInput - AG-UI draft versioning and negotiation
@ag-ui/corepackage metadata- AG-UI release
2026-09-11 - UHP
2026-09-12architecture at checked HarnessRouter main