Comparison
UHP vs Simple Agent Management Protocol (SAMP)
UHP standardizes client-to-server execution of a selected complete harness. SAMP is an emerging manager-to-agent management plane for discovery, trust, health, configuration and explicitly allowed control operations.
The one-sentence difference
Section titled “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
Section titled “Current SAMP status”The current document is draft-efstathiou-samp-agent-management-01, last updated 1 September 2026. The document header states Intended status: Experimental and defines SAMP version 0.1, while the IETF Datatracker classifies it as an active individual Internet-Draft, with no RFC stream, and explicitly states that the draft is not endorsed by the IETF and has no formal standing in the IETF standards process.
That maturity boundary matters. SAMP is concrete enough to evaluate as an emerging protocol, but it is not an IETF standard, not a published RFC, and not an adopted UHP extension. No standardized UHP↔SAMP binding or HarnessRouter SAMP integration was verified at this cutoff.
Architectural comparison
Section titled “Architectural comparison”| Dimension | UHP | SAMP 0.1 draft |
|---|---|---|
| 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, lifecycle/trust 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, disabled by default and constrained by policy |
| Configuration scope | Harness/task configuration is part of the server execution contract | CONFIG is profile-declared and agent-wide in v0.1; session-scoped configuration is outside the draft |
| Authority | UHP server owns protocol objects and enforces its execution boundary | Manager owns trust/policy decisions; local agent policy remains independently restrictive |
| Transport | HTTP over TLS; SSE for task streaming | HTTP(S) baseline with a WebSocket mapping |
| Security emphasis | Principal/object isolation, credential handling, server/harness execution boundary | HMAC-SHA256, canonical JSON, replay defense, trust enrollment 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 | 2026-08-11 Draft standard with a runnable conformance suite | Active individual Internet-Draft; v0.1 Experimental-intent work in progress |
Why SAMP EXEC is not a UHP task API
Section titled “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 it to be disabled by default, explicitly enabled for each agent and command, restricted to exec_policy.allowed_commands, and supplied with typed parameters rather than arbitrary free-form arguments. The agent’s local policy and the manager’s policy are both restrictive. A deployment may also require synchronous runtime evidence before an operation is admitted.
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 explicitly defines only agent-wide CONFIG; a transport-independent session model for session-scoped configuration is outside the document. UHP already defines its own server-owned task/session object model.
Failure domains are a first-class SAMP concern
Section titled “Failure domains are a first-class SAMP concern”One of SAMP’s most 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. It says those topologies provide different guarantees and requires the manager not to infer out-of-band enforcement merely from the existence of the endpoint. 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 a control is cooperative or independently enforceable.
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.
Runtime evidence is carried, not standardized
Section titled “Runtime evidence is carried, not standardized”SAMP v0.1 also defines a format-neutral runtime_evidence object. Evidence can arrive asynchronously in PUSH or synchronously in a CONFIG/EXEC response when it gates admission. The envelope separates the evidence issuer from the SAMP sender, includes correlation/freshness information and lets manager policy decide how verified evidence affects trust.
The draft deliberately does not select a preferred evidence format or define verifier policy. It names CCS receipts as one possible binding without requiring CCS. Transport authentication of the SAMP sender does not prove that the sender issued a verdict, and absence of expected evidence must not be treated as proof of correct behavior.
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
Section titled “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
Section titled “A terminology caution around ACP”SAMP draft -01 correctly distinguishes MCP tool use from SAMP management, but its relationship table groups “A2A / ACP” under agent-to-agent communication. 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
Section titled “Current implementation limits”The draft records early implementation evidence rather than a mature compatibility ecosystem. Its implementation-status section names a Rust SAMP Core/Module in the AgMS reference implementation and a Python proof of concept with an AgMS-lite collector plus OpenClaw adapter. The Python path demonstrates DISCOVER, PING, QUERY, PUSH and disabled-by-default EXEC, but the draft explicitly records a canonicalization deviation: the PoC authenticates raw request bytes rather than the RFC 8785 canonical JSON required by the specification. SUBSCRIBE and UNSUBSCRIBE are not implemented in either PoC at the documented cutoff.
The v0.1 scope also leaves federation/multi-manager coordination, fleet-wide transactional operations, RBAC, mandatory mTLS and a formal profile schema language outside the document. Those are material limits when evaluating production readiness.
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 and UHP vs ACP for the neighboring execution, tool, communication and agent-integration boundaries.