UHP vs Simple Agent Management Protocol (SAMP)

Require the consequential-operation contract from draft-03

The current SAMP -03 document, dated 26 September 2026, adds mandatory CONFIG/EXEC authorization-context verification bound to the exact action and authenticated Manager/Agent context. It also defines late evidence-backed resolution of indeterminate outcomes and peer-visible audit_persistence. Protocol/profile version remains experimental 0.1; mixed -02/-03 consequential operations require explicit compatibility or lockstep updates. This source and UHP 2026-09-28 Draft were reopened 4 October 2026.

Manager observation	Operational interpretation
Endpoint reachable	Liveness only; trust/admission remain separate
Authority decision verified	Permission for the bound operation; effect not yet proven
Indeterminate outcome	Preserve the operation identity and original uncertainty
Later effect evidence resolves it	Append resolution; do not treat it as permission for another execution
Audit persistence failed/unknown	Surface the missing durability evidence

Use UHP for harness task/session execution and SAMP only where a management plane is required. A service restart or quarantine command must have its own authority and effect evidence. The older -02 change list below remains useful chronology. Its 0.1 label does not establish wire compatibility with the current consequential-operation contract.

The one-sentence difference

UHP standardizes how a product or client asks a server to execute work on a selected, configured complete harness. SAMP proposes how an operator-facing manager discovers, observes, trusts, configures and conditionally controls managed AI agents.

The distinction is a task plane versus a management plane. UHP’s central abstraction is a server-owned Response representing one harness task, with Sessions for continuation. SAMP’s central relationship is a SAMP Manager ↔ SAMP Agent management interface around agent identity, profile, liveness, trust, state, events and narrowly exposed control operations.

Current SAMP status

Current revision is draft-efstathiou-samp-agent-management-03, dated 26 September 2026. It remains an individual Internet-Draft with intended Experimental status; protocol/profile 0.1 does not identify a frozen wire contract. The -02 chronology follows at its original date.

The 12 September review covered draft-efstathiou-samp-agent-management-02, published 11 September 2026. It has intended status Experimental, expires 15 March 2027, and continues to define SAMP protocol/profile version 0.1. That reviewed revision was an individual Internet-Draft, not an RFC or adopted IETF standard.

That maturity boundary matters. SAMP is concrete enough to evaluate as an emerging management-plane protocol, but no standardized UHP↔SAMP binding, HarnessRouter SAMP integration or SAMP adoption by UHP was verified at this cutoff.

Revision -02 is not merely editorial. Its own change log says it introduces experimental wire-contract changes relative to -01 while deliberately retaining protocol/profile version 0.1. Mixed -01 and -02 implementations are therefore not presumed interoperable unless they update together or use an explicitly identified compatibility profile.

What changed in draft-02

Compared with -01, the 11 September revision materially tightens ownership, state and admission semantics:

• Trust and liveness are separate Manager-owned dimensions. A reachable endpoint is not automatically trusted, and ordinary liveness changes do not silently rewrite trust decisions.
• Quarantine records enforcement separately from decision. requested, applied, failed and indeterminate describe enforcement status; only affirmative confirmation can be presented as applied isolation.
• Profiles gain typed declarations and revisions. The draft adds a minimal recursive type model plus profile_revision / ordering semantics rather than leaving field shape largely informal.
• CONFIG/EXEC share a common admission/outcome model. Admission authority, execution outcome and evidence are kept distinct instead of collapsing policy approval and successful effect into one state.
• Retry and finality behavior is tighter. Identical-byte retry handling occurs before freshness rejection; recorded-state retention, concurrent duplicate handling and restart safety are explicit, and the draft makes no exactly-once execution claim.
• Subscriptions and enrollment are more precise. Fixed subscription expiry/replacement behavior, enrollment boundaries and endpoint-side pre-admission evidence rules are defined more explicitly.
• Management-impact classes restrict rather than grant authority. The advisory class, for example, prohibits advertising and accepting CONFIG/EXEC.

These changes strengthen SAMP’s management semantics without turning it into a harness task protocol.

Architectural comparison

The matrix describes the management/execution layer distinction; use current -03 authority requirements above for consequential operations.

Dimension	UHP 2026-09-12	SAMP draft-02 / v0.1
Primary boundary	Product/client ↔ UHP server ↔ complete harness	SAMP Manager ↔ SAMP Agent management endpoint
Primary purpose	Execute tasks through interchangeable configured harnesses	Discover, observe and manage heterogeneous AI agents
Core work/state model	Responses, Sessions, task lifecycle, events, files and artifacts	Agent profile, trust/liveness state, management PDUs and subscriptions
Main operations	Discovery/catalogues, task execution/streaming, continuation, cancellation, files/artifacts	PING, DISCOVER, QUERY, PUSH, SUBSCRIBE, UNSUBSCRIBE, CONFIG, EXEC
Execution meaning	A Response is a harness task	EXEC is an explicitly exposed management command constrained by policy
Configuration scope	Harness/task configuration is part of the server execution contract	CONFIG is policy-declared agent management; session-scoped configuration remains outside core v0.1
Authority	UHP server owns protocol objects and enforces its execution boundary	Manager owns admission/trust decisions; endpoint/local policy remains independently restrictive
Transport	HTTP API; streaming/event semantics defined by UHP	HTTP(S) baseline with WebSocket mapping
Security emphasis	Principal/object isolation, credential handling, server/harness execution boundary	HMAC-SHA256, canonical JSON, replay defense, enrollment, trust/liveness separation and policy-gated control
Deployment topology	Server-to-harness execution is implementation-defined	Endpoint may be embedded, sidecar/supervisor, gateway or independent infrastructure, with failure-domain metadata
Maturity	Draft standard with runnable conformance suite	Active individual Internet-Draft; Experimental-intent v0.1 work in progress

Why SAMP EXEC is not a UHP task API

The presence of an execution verb creates superficial overlap, but the semantics are different.

SAMP EXEC is a management operation. The draft requires execution to be profile/policy controlled and subject to both Manager admission and endpoint-local enforcement. Draft-02 makes the distinction sharper by defining a common CONFIG/EXEC admission-and-outcome model: approval to attempt an operation is not the same fact as the operation’s resulting effect.

UHP instead makes task execution the protocol’s primary purpose: a client creates a Response against a configured harness and receives a defined lifecycle, event stream, continuation/session behavior and file/artifact surfaces. Treating SAMP EXEC as equivalent to a UHP Response would erase the difference between a bounded management command and general harness work execution.

The same caution applies to configuration. SAMP v0.1 remains an agent-management contract; UHP defines its own server-owned task/session object model.

Failure domains are a first-class SAMP concern

One of SAMP’s useful architectural ideas is that a reachable management endpoint does not automatically prove independent control authority.

The draft allows the SAMP endpoint to live inside the managed agent, in a sidecar or supervisor, in an AI Agent Gateway, or in other infrastructure. These topologies provide different guarantees. Draft-02 explicitly says deployment metadata describes survival/shared-failure properties rather than letting labels such as “sidecar” or “gateway” stand in for proof of isolation.

A profile should declare whether the endpoint shares the managed process, host or failure domain, whether management/evidence paths survive managed-process failure, and whether controls are cooperative or independently enforceable. A manager must not infer out-of-band enforcement merely because a SAMP endpoint exists.

That is relevant to harness operations because a supervisor outside an agent’s failure domain can potentially provide stronger quarantine, restart, termination and evidence-survival guarantees than code embedded inside the agent itself. It is still a SAMP deployment/control model, not a requirement added to UHP.

Trust, liveness and quarantine are separate facts

Draft-02 makes this separation explicit:

• trust_state is the Manager’s security disposition, with states such as discovered, pending, trusted, quarantined, rejected and revoked.
• liveness_state is observed reachability: unknown, reachable, stale or offline.
• quarantine enforcement_status records whether isolation was merely requested, affirmatively applied, failed or remains indeterminate.

An agent can therefore be trusted but offline, or quarantined but still reachable. A Manager cannot present requested/indeterminate quarantine as confirmed isolation. This is a management-plane state model, not a UHP Response lifecycle.

Runtime evidence is carried, not standardized

SAMP v0.1 defines a format-neutral runtime_evidence concept. Evidence can arrive asynchronously in PUSH or participate in CONFIG/EXEC admission. The envelope separates the evidence issuer from a SAMP endpoint that merely relays it and includes correlation/freshness information so Manager policy can decide how verified evidence affects admission or trust.

Draft-02 keeps Correctover Conformance Shape (CCS) optional and Informative; it does not select a required evidence format or define verifier policy. Transport authentication of a SAMP sender does not prove that sender issued the evidence verdict.

Therefore SAMP can compose with runtime-attestation/evidence systems, but it does not make those formats part of UHP and it does not turn UHP conformance into runtime-attestation evidence.

Coexistence is plausible without protocol fusion

A system could expose both protocols at different boundaries. For example:

• a product backend could use UHP to submit user/workflow tasks to an interchangeable harness server; and
• an operator control plane could use SAMP to discover the deployed agent runtime, observe its health/trust state, subscribe to operational events, change explicitly writable settings or invoke explicitly allowed management commands.

The same runtime could participate in both paths, but the object models and authority remain separate unless an implementation defines an explicit bridge. No primary source reviewed here defines a standard mapping between UHP Responses/Sessions and SAMP profiles, trust states, CONFIG or EXEC.

A terminology caution around ACP

SAMP draft -02 still groups “A2A / ACP” under agent-to-agent communication in its relationship table. That shorthand should not redefine ACP for implementers. The official Agent Client Protocol (ACP) defines the client/editor/tool ↔ agent integration boundary, while A2A is agent-to-agent communication. This guide therefore retains the primary ACP project’s own boundary in UHP vs ACP.

Current implementation limits

Draft-02 deliberately narrows its implementation claim. It records earlier Python AgMS work exercising envelopes, discovery, query, events, subscriptions, configuration, authentication, replay handling and disabled-by-default execution, plus framework-adapter development experience.

But that implementation experience predates the complete remediated trust/liveness, typed-declaration, outcome and recorded-state requirements in -02. The draft explicitly makes no claim that those implementations conform to all current requirements and says independent implementation/interoperability validation remains to be performed. Local document checks and same-team tests are not treated as conformance or exactly-once evidence.

The v0.1 scope also leaves federation/multi-manager coordination, fleet-wide transactional operations, RBAC, mandatory mTLS, general cancellation, persistence extensions and a dedicated media type outside the base document.

What not to infer

Caution

• An active individual Internet-Draft is not an IETF standard or IETF endorsement.
• SAMP draft-02 retaining protocol/profile 0.1 does not mean it is wire-compatible with draft-01; the draft explicitly says mixed implementations are not presumed interoperable.
• A SAMP Agent is not automatically a UHP harness or UHP server.
• SAMP EXEC is not the same abstraction as a UHP Response/task.
• SAMP runtime evidence is not a UHP conformance result or a mandatory evidence format.
• A product using SAMP does not thereby adopt UHP, and a UHP implementation does not thereby support SAMP.
• No HarnessRouter SAMP backend/management binding or native SAMP→UHP mapping was verified at this cutoff.

Related pages

See UHP architecture, Security, Harness composition, UHP vs MCP, UHP vs A2A and UHP vs ACP for the neighboring execution, tool, communication and agent-integration boundaries.

Primary sources

• Current SAMP draft-03 — current authorization, resolution and audit contract.

• IETF Datatracker: Simple Agent Management Protocol (SAMP)

• SAMP draft-02 HTMLized text

• SAMP draft-02 archive copy

• UHP 2026-09-12 protocol source