Independent developer guide. Not affiliated with HarnessRouter or the official UHP project.

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.

Page reviewed 4 Oct 2026 Source and review policy

UHP: 2026-09-28AG-UI: 1.0 released / 1.1 draft@ag-ui/core: 1.0.1

Use released AG-UI 1.0 for a new integration

The current release contract is AG-UI 1.0. The draft notice now identifies the next working draft as 1.1 and says no SDK implements it yet. The checked @ag-ui/core source is 1.0.1 with agui.protocolVersion: "1.0"; package patch and protocol version remain distinct. Both AG-UI and UHP 2026-09-28 Draft were checked on 4 October 2026.

Need	Use	Integration check
Application messages, frontend tools and synchronized state	Released AG-UI 1.0	Declare/validate the actual supported contract
Complete remote harness execution	UHP	Retain Response/Session lifecycle and artifact ownership
Reconnect and replay application history	AG-UI transport/processing rules	Preserve run identity; do not execute replayed tool calls again
Explore upcoming behavior	AG-UI 1.1 draft	Keep experimental code separate from a released-1.0 claim

The 1.0 versioning rules distinguish unknown additions from malformed known fields. A shim may adapt for an older peer, but must not invent content or repair malformed values into apparent validity. For a UHP bridge, retain the original event/result evidence and report any lossy UI projection. An attractive finished message is not proof of the outer execution outcome; terminal evidence must still come from the executing owner.

The September intended-1.0 analysis that follows records the earlier draft, not the current release status.

The short version

UHP and AG-UI standardize different interoperability planes. UHP 2026-09-28 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

AG-UI now publishes a normative 1.0 specification and separately labels the next 1.1 draft as work in progress with no SDK implementation yet. The checked TypeScript core package is 1.0.1, with protocol coordinate 1.0. Use the released specification for a new integration; do not infer draft support from a package version.

The preserved 13 September 2026 source snapshot used @ag-ui/core 0.0.59, release train release/2026-09-11 and intended-1.0 draft language. Those coordinates explain the old source links below; they are superseded for current implementation guidance.

Boundary comparison

The table uses the current released 1.0 application/agent boundary; the draft 1.1 is a separate development surface.

Dimension	UHP `2026-09-28`	AG-UI released `1.0`
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	Released input includes resume data for interrupted interactive runs
Versioning	Date-stamped UHP versions; current draft is `2026-09-28`	In-band `protocolVersion` declaration and released versioning/compatibility rules
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.28.post3`	Released `1.0`; next `1.1` is a draft

What AG-UI standardizes

The released 1.0 contract 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

UHP uses a date-stamped protocol coordinate and a matching conformance package. AG-UI 1.0 declares the consumer version in RunAgentInput.protocolVersion and the producer version on RUN_STARTED. Although the input field is optional in the schema for legacy peers, a 1.0 consumer must declare its version unless it knows the peer predates that field.

The released contract distinguishes unknown additions from malformed known values. A downgrade may reshape content for an older peer but may not invent it or repair a malformed value into apparent validity; loss must be surfaced under the versioning rules.

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

AG-UI support in a framework does not imply native UHP support.
UHP conformance does not imply AG-UI compatibility.
@ag-ui/core 1.0.1 is a package coordinate; the protocol coordinate is 1.0.
AG-UI’s next 1.1 draft should not be cited as implemented SDK behavior.
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 a7406cbd tree.

Primary sources

Current: AG-UI 1.0 run input, 1.0 versioning, 1.1 draft notice. The pinned links below preserve the September review.

Use released AG-UI 1.0 for a new integration

The short version

Maturity boundary

Boundary comparison

What AG-UI standardizes

Version negotiation is different

How it relates to MCP and A2A

What not to infer

Primary sources

Related pages