Skip to content
UHPUHPDeveloper Guide
Independent resource · Not affiliated with HarnessRouter · Site data checked 29 Aug 2026

Comparison

UHP vs Agent Event Protocol (AEP)

UHP standardizes how clients execute work through complete agent harnesses. Agent Event Protocol (AEP) standardizes how agent activity is observed, replayed and, experimentally, controlled across direct and relayed deployments. They are complementary planes with different event guarantees.

Verified: UHP: 2026-08-11Agent Event Protocol: pre-v0.1

First, disambiguate the acronym

Section titled “First, disambiguate the acronym”

This page uses AEP to mean the open-source Agent Event Protocol project maintained by the agenteventprotocol organization. It is unrelated to the separately tracked IETF individual Internet-Draft named Agent Enrollment Protocol (AEP). The two projects solve different problems and share only an acronym.

One-sentence difference

Section titled “One-sentence difference”

UHP is a client-to-server contract for selecting and executing complete agent harnesses; Agent Event Protocol is an observer/control-plane contract for emitting, relaying, replaying and optionally controlling agent activity across heterogeneous runtimes.

They can coexist. A UHP-served harness could emit AEP events to an observer or relay, but neither specification currently defines a standardized UHP↔AEP binding.

Current status

Section titled “Current status”
SurfaceCurrent verified status
UHPPublished version 2026-08-11, Draft standard, with a 52-check conformance suite across Core, Extended and Full.
Agent Event ProtocolPre-release / pre-v0.1. The repository’s versioning policy labels the current protocol unit aep: "0.1", but no v0.1 Git tag or GitHub Release exists. Before the first tag, the project explicitly assumes no compatibility obligation.
AEP specification setAEP-0001 Core/Envelope, AEP-0002 Taxonomy, AEP-0003 Bindings, AEP-0004 Control, AEP-0005 Bridges and AEP-0007 Message/Stream are Draft; AEP-0006 Structured Input Requests, AEP-0008 Text Answers/Response Channels and AEP-0009 Assessment are Accepted at this cutoff.
AEP control profileExperimental within the pre-v0.1 line; authenticated duplex transport is required and current control behavior may still change before a stable release.

The 0.1 protocol attribute therefore describes the current development schema/specification unit; it must not be reported as a released AEP v0.1 standard.

Architecture at a glance

Section titled “Architecture at a glance”
DimensionUHP 2026-08-11Agent Event Protocol pre-v0.1
Primary boundaryProduct/client ↔ UHP server ↔ selected complete harness.Agent/runtime emitter ↔ observer, relay, bridge or control consumer.
Primary purposeExecute tasks through interchangeable harness backends with discovery, sessions, files, streaming, cancellation and stored Responses.Normalize activity telemetry and attention/control events across heterogeneous agents and tools.
Core object modelHarness, Response/task, Session, File, Container and Event.Event envelope plus taxonomy; emitter, consumer and relay roles.
TopologyClient talks to a UHP server, which adapts implementation-defined harness runtimes.Direct emitter→consumer and relayed/fan-out topologies are first-class.
TransportHTTP/TLS; SSE for streaming/event feeds.Binding-dependent; project materials cover stdio JSONL, HTTP, SSE and WebSocket.
Ordering identityResponse stream sequence_number starts at 0 and increases exactly by 1; no gaps.Session stream uses (epoch, seq); gaps are legal, regressions are not.
Delivery/replayDropped stream does not abort the task; stored Response is authoritative. Optional Last-Event-ID resume can continue after a sequence number without requiring replay.At-least-once delivery semantics, consumer deduplication by (source, id), resume tokens using session/epoch/sequence, and optional bounded relay replay.
ControlUHP defines task cancellation and lifecycle endpoints.Experimental control events cover attention responses, cancel, pause and resume with accepted/rejected acknowledgements.
Human/attention interactionNo general protocol-wide attention-request/answer event family in 2026-08-11.Explicit attention.requested, attention.answered, attention.resolved and attention.timeout lifecycle plus structured-input/text-answer profiles.
Conformance focusServer behavior and protocol capability classes.Role-oriented emitter, consumer and control-capable behavior in the pre-v0.1 spec suite.
Security identityBearer authentication, per-principal object scoping and UHP security requirements.source and agent are asserted identities rather than cryptographic proof in 0.1; authenticated bindings are required off-host and unconditionally for control.

AEP’s event envelope and the fleet-observer boundary

Section titled “AEP’s event envelope and the fleet-observer boundary”

AEP-0001 defines a common envelope with identifiers and execution context including aep, id, type, subject, time, source, agent, session, run, step, seq, epoch, cause, traceparent, severity, capture, plus optional event data.

Its design test is deliberately observer-oriented: a core event should still make sense to an operator watching many agent sessions that the operator did not initiate. That distinguishes AEP from a task-submission API. Session identity is emitter-scoped, so fleet consumers aggregate by (source, session) rather than assuming a globally unique bare session identifier.

AEP also defines capture levels (none, metadata, redacted, full) with metadata as the default, making disclosure level an explicit part of the event contract rather than assuming every observer receives full prompts, tool inputs or outputs.

The event guarantees are not equivalent

Section titled “The event guarantees are not equivalent”

The biggest implementation mistake would be treating UHP and AEP sequence fields as interchangeable.

UHP response streaming is task-centric and contiguous. A streaming Response emits SSE events whose sequence_number starts at zero and increases by exactly one. Gaps are not allowed. Exactly one terminal event is last. If the client disconnects, the underlying task continues and the stored Response remains the source of truth; clients reconcile by retrieving the Response or following server event surfaces.

AEP ordering is observer/session-centric and tolerant of missing observations. Its stream identity is (epoch, seq), gaps are legal, and consumers must tolerate at-least-once delivery and deduplicate by (source, id). The protocol also defines resume identity and allows relays to offer bounded replay.

A bridge between them therefore needs explicit state translation. Copying UHP sequence_number into AEP seq, or assuming AEP gap tolerance means a UHP Response stream may skip events, would violate one side or the other.

Attention and experimental control

Section titled “Attention and experimental control”

AEP’s attention lifecycle is a material addition to the interoperability landscape because it treats human/operator attention as portable runtime activity rather than a vendor-specific UI event. The project separates request, answer, resolution and timeout events, with AEP-0006/AEP-0008 adding structured-input and response-channel detail.

AEP-0004 then defines an experimental control profile in which commands, acknowledgements and outcomes are themselves ordinary AEP events. Current commands include:

  • control.attention.respond
  • control.cancel
  • control.pause
  • control.resume

A control-capable target can accept or reject a command, including reasons such as unsupported, unauthorized, busy, refused or invalid. The default acknowledgement window is 10 seconds. The target remains sovereign and may refuse. Relays must route a command to at most one claimant and fail closed if ownership is ambiguous.

This is not a universal authorization model. AEP explicitly leaves who may command whom to deployment policy. Authenticated duplex transport is required for control, including localhost use. UHP 2026-08-11 defines cancellation for UHP tasks, but it does not define a general pause/resume/attention-control event plane equivalent to AEP’s current experimental profile.

Relationship to MCP, A2A, ACP and OpenTelemetry

Section titled “Relationship to MCP, A2A, ACP and OpenTelemetry”

AEP-0001 is unusually explicit about what the protocol is not:

  • It is not an A2A delegation or task-exchange protocol.
  • It is not MCP tool/context provisioning.
  • It is not ACP editor-to-agent driving.
  • It is not a frontend rendering protocol such as AG-UI/A2UI.
  • It is not a replacement for OpenTelemetry distributed tracing; the project instead defines bridge work toward OTLP.

That scope makes AEP closer to a portable agent activity/event plane than to a competing execution API. A harness can still use MCP internally, communicate with remote agents over A2A, be driven through ACP, expose tasks through UHP, and emit AEP events around the same run.

Reference implementation evidence

Section titled “Reference implementation evidence”

The official agenteventprotocol/reference repository provides a runnable relay, CLI, bridges, an MCP server and adapter coverage for multiple agent runtimes. Its documented adapter set includes Claude Code, Codex, Gemini CLI, Qwen Code, OpenCode, Kilo Code, Cline, Hermes, Antigravity, Pi, VS Code/Copilot and Kimi Code. The reference repository also vendors a specification commit and gates its own conformance/checking against that pinned revision.

This is useful implementation evidence for AEP, but the adoption boundary is important: an adapter maintained by the AEP project does not establish native AEP adoption by Anthropic, OpenAI, Google, Qwen, OpenCode, Nous, Pi or any other upstream harness/vendor.

How AEP could compose with UHP

Section titled “How AEP could compose with UHP”

A practical deployment could look like this:

Product / IDE
    │
    │ UHP task/session API
    ▼
UHP Server ──implementation adapter──► Harness
                                      │
                                      │ AEP activity events
                                      ▼
                              AEP relay / observers
                                      │
                                      ├─ dashboard
                                      ├─ audit/automation
                                      └─ control-capable operator

That composition is currently implementation-defined. No primary source reviewed establishes:

  • a normative UHP↔AEP mapping;
  • a HarnessRouter AEP integration;
  • AEP as part of the UHP protocol;
  • UHP adoption by the Agent Event Protocol project;
  • AEP adoption by HarnessRouter; or
  • a standard translation from AEP control commands into UHP task/session operations.

A future bridge would need to define identity mapping, event-type mapping, sequence/replay semantics, cancellation ownership, attention correlation, authentication and authorization rather than assuming the two event models line up automatically.

Security boundary

Section titled “Security boundary”

AEP’s pre-v0.1 core treats source and agent as asserted identity fields, not cryptographic proof. The specification requires authenticated bindings when traffic leaves the host, and requires authentication for control even on localhost. Signed identity documents remain experimental, while event signing is deferred before a multi-tenant relay profile.

UHP has a different trust boundary: authentication applies to the UHP HTTP service and protected objects are scoped per principal. UHP security also covers file/container access, credential handling, error hygiene and transport expectations. Deploying both protocols therefore creates two separate authorization decisions: who may execute/manage a UHP task, and who may observe or control the corresponding AEP activity stream.

What is not established

Section titled “What is not established”
  • Agent Event Protocol has not reached its first tagged v0.1 release.
  • AEP’s experimental control profile is not a stable industry-standard remote-control plane.
  • AEP reference adapters are not proof of native vendor adoption.
  • UHP does not normatively depend on AEP.
  • AEP does not replace UHP’s harness selection, task/session, file/container or stored-Response contracts.
  • No standardized UHP↔AEP bridge or HarnessRouter integration was verified at this cutoff.

Sources

Section titled “Sources”
Section titled “Related pages”