Comparison
UHP vs Agent Infrastructure Control Protocol (AICP)
UHP standardizes client-to-server execution through complete agent harnesses. AICP is an emerging infrastructure-control protocol for capability discovery, bounded situations, intents, exact plans, authorization, durable operations, verified outcomes and reconciliation.
The one-sentence difference
Section titled “The one-sentence difference”UHP is a client-to-server contract for selecting and executing work through a configured complete agent harness; AICP proposes a provider-facing infrastructure control contract that turns an autonomous principal’s desired outcome into a bounded Situation, exact Plan, authorized durable Operation and verified Outcome.
They sit at different boundaries. UHP standardizes the harness execution surface exposed to products and clients. AICP standardizes the semantics between an autonomous infrastructure-control client and a provider/control plane that can inspect, plan, authorize, execute and verify consequential infrastructure changes.
Current AICP status
Section titled “Current AICP status”The current document is draft-paxton-aicp-00, dated 2 September 2026. The IETF Datatracker classifies it as an active individual Internet-Draft and explicitly states that the document is not endorsed by the IETF and has no formal standing in the IETF standards process.
There is also a maturity detail worth preserving exactly: the draft text header says “Intended status: Standards Track”, while the Datatracker metadata currently shows RFC stream: (None) and Intended RFC status: (None). This guide therefore treats AICP as a work-in-progress individual proposal, not as an adopted IETF standard or Working Group specification.
The draft defines core protocol version 0.1 and explicitly warns that pre-1.0 versions may make incompatible changes. It expires on 6 March 2027 unless updated, replaced or otherwise progressed.
No UHP reference appears in the reviewed AICP draft, and no standardized UHP↔AICP mapping, HarnessRouter AICP integration or native UHP adoption by the AICP project was verified at this cutoff.
Architectural comparison
Section titled “Architectural comparison”| Dimension | UHP 2026-08-11 | AICP 0.1 / draft-00 |
|---|---|---|
| Primary boundary | Product/client ↔ UHP server ↔ configured complete harness | Autonomous principal/client ↔ infrastructure control provider |
| Primary purpose | Execute tasks through interchangeable harness backends | Govern consequential infrastructure intent from situation through verified outcome |
| Core objects | Harness, Response/task, Session, File, Container and Event | Capability Document, Situation, Intent Request, Plan, Operation, Outcome and Problem; Operation Events carry incremental changes |
| Execution authority | UHP server owns protocol objects and adapts the selected harness | Provider derives identity, delegation, permissions and approval from authenticated server-side context |
| Planning | Harness behavior is implementation-defined behind the UHP task boundary | Plan is a first-class durable object tied to the Situation and Intent Request |
| Authorization | UHP security applies at server/object/task boundaries | Authorization and approval are explicitly bound to the exact Plan revision and re-evaluated before effect |
| Durability | Stored Response and Sessions provide UHP task continuity | Plans, Operations, Outcomes and events are designed to outlive a client session and support recovery/reconciliation |
| Effects | UHP reports task lifecycle/output; harness side effects remain implementation-specific | Effect state, uncertainty, compensation and verified outcome are explicit control-plane semantics |
| Transport | HTTP/TLS with SSE streaming | Transport-independent core model plus an HTTP binding; MCP and A2A mappings are described separately |
| Conformance | Current runnable UHP suite: 63 checks across Core, Extended and Full | Draft defines Core Provider, Core Client and Profile conformance plus twelve minimum test cases |
| Maturity | Published 2026-08-11 Draft standard in the UHP project | Active individual Internet-Draft, draft-00; not IETF-endorsed or adopted |
AICP makes the control graph durable
Section titled “AICP makes the control graph durable”AICP’s core control loop is built around seven linked durable object classes:
- Capability Document — what the authenticated principal is allowed to discover about supported profiles/actions.
- Situation — bounded observed context relevant to a decision.
- Intent Request — the desired outcome, targets, constraints and success criteria.
- Plan — the exact proposed material effects and revision to be authorized.
- Operation — durable execution state for that exact Plan revision.
- Outcome — expected-versus-observed result and verification evidence.
- Problem — machine-actionable failure/recovery information.
The links between those objects form an audit/resumption graph rather than a transcript of model reasoning. A resumed client can retrieve the current Operation and follow its lineage back to the exact Plan, originating intent and Situation without reconstructing authority or effects from chat history.
That is a different abstraction from UHP’s Response/Session model. UHP persists a harness task and its continuation state; AICP persists the infrastructure control decision and effect lineage around a consequential change.
Exact-plan binding is a first-class safety invariant
Section titled “Exact-plan binding is a first-class safety invariant”The draft separates feasibility, authorization, approval and execution readiness. A provider must derive authority from authenticated context rather than accepting permission claims carried in request bodies.
For explicit plan execution, the HTTP binding requires the exact planRevision plus a strong If-Match entity tag. A stale or mismatched Plan must not execute, and an approval for one revision cannot silently authorize a newer revision. The draft also requires conservative handling of uncertain effects: a client must not blindly replay a consequential request when the effect may already be partial, possible or unknown.
These rules address infrastructure-control hazards such as time-of-check/time-of-use changes, approval substitution, replay, duplicate effects and retry storms. They are AICP semantics, not new UHP requirements.
HTTP binding and conformance are concrete but still draft work
Section titled “HTTP binding and conformance are concrete but still draft work”AICP specifies an HTTP interaction pattern for discovery, capability listing, Situation acquisition, Intent submission, Plan retrieval/execution, Operation retrieval/control, events and Outcome retrieval. Accepted asynchronous execution returns a durable Operation resource rather than treating 202 Accepted as sufficient on its own.
The draft also defines conformance roles:
- a Core Provider implements the core object/lifecycle semantics in at least one binding;
- an HTTP Provider additionally implements the HTTP binding;
- a Core Client validates versions/extensions, treats prose as non-authoritative, executes only exact Plan revisions, handles event deduplication and avoids unsafe retries; and
- Profile conformance requires both sides to share the profile semantics needed for domain interoperability.
Core conformance alone therefore does not imply semantic interoperability for an infrastructure domain whose profile is not shared.
Relationship to MCP and A2A is explicit
Section titled “Relationship to MCP and A2A is explicit”AICP deliberately layers with existing agent protocols instead of claiming to replace them.
For MCP, the draft recommends a compact tool surface such as aicp.discover, aicp.situation, aicp.plan, aicp.execute, aicp.observe and aicp.control. An MCP adapter must preserve the same Plan, policy, Operation, error and audit semantics and must not create an authorization bypass around the HTTP binding. MCP task facilities may represent long-running delivery, but the AICP Operation remains the authoritative infrastructure-effect record.
For A2A, an agent may delegate infrastructure work to another agent or carry AICP objects as artifacts. The draft keeps the state machines separate: an A2A task describes inter-agent work/conversation, while an AICP Operation describes infrastructure execution and effects.
That scope separation is consistent with UHP’s own need to keep tool access, inter-agent communication and complete-harness execution as distinct protocol boundaries.
Do not confuse the AEP reference
Section titled “Do not confuse the AEP reference”AICP section 15.3 references Agent Execution Protocol (AEP), specifically draft-sato-soos-aep-02. That draft describes a governed reasoning-loop boundary whose ACT transition can invoke AICP and whose SENSE/OBSERVE transitions can consume AICP state.
This is not the open-source Agent Event Protocol (AEP) covered on this site’s UHP vs AEP page. The acronym is overloaded. AICP’s cited Agent Execution Protocol and the site’s Agent Event Protocol are different projects with different object models and authors.
How AICP and UHP could coexist
Section titled “How AICP and UHP could coexist”A practical implementation could use both without merging their protocols:
Product / IDE │ │ UHP task/session API ▼UHP Server ──adapter──► Complete harness │ │ infrastructure-control action ▼ AICP client │ ▼ AICP Provider / Control Plane │ ▼ Cloud / Kubernetes / provider APIsIn that topology, UHP answers which harness executes the task and how the client observes/continues that harness work. AICP answers how a consequential infrastructure action is discovered, planned, authorized, executed, verified and reconciled after the harness chooses to perform infrastructure control.
A bridge would need an explicit policy for identity propagation, approval ownership, task↔Operation correlation, cancellation semantics, evidence retention and error translation. None of those mappings is standardized by UHP or AICP today.
Security relevance
Section titled “Security relevance”AICP’s security model is unusually direct about autonomous infrastructure control. The draft covers confused-deputy and cross-tenant risks, stale-plan/TOCTOU attacks, approval substitution, prompt injection/schema poisoning/tool shadowing, replay/duplicate effects, compromised adapters, secret handling, blast-radius limits and audit integrity.
Notably, descriptions and resource labels are treated as untrusted data rather than protocol authority. High-rate autonomous callers are constrained by provider-side limits on scope, spend, concurrency and destructive actions, and a client’s stated risk tolerance cannot override provider policy.
These are useful architectural patterns for systems that let agent harnesses perform infrastructure changes, but they do not alter UHP’s current normative security chapter.
What not to infer
Section titled “What not to infer”Related pages
Section titled “Related pages”See UHP architecture, Security, Harness composition, UHP vs MCP, UHP vs A2A, UHP vs SAMP and UHP vs AEP for neighboring execution, management, tool, communication and event/control boundaries.