> ## Content Index > Fetch the complete content index at: https://samp-protocol.org/llms.txt > Use this file to discover other available public pages before exploring further. # The Evolution of SAMP: From -00 to -04 - URL: https://samp-protocol.org/the-evolution-of-samp-from-00-to-04/ - Published: 2026-11-04T13:37:33.000Z - Updated: 2026-11-06T15:54:06.000Z - Description: From the first Internet-Draft to SAMP v0.2: five revisions exploring AI agent management, trust, authorization, runtime evidence, and operational resilience. - Author: Stelio E. Efstathiou - Tags: Engineering Notes, SAMP Articles Five Internet-Draft revisions. Ten weeks of protocol development. One fundamental engineering question: **How do we manage AI agents as operational infrastructure?** When AI agents move beyond isolated experiments and become persistent operational systems, they introduce management challenges familiar to anyone who has designed or operated large-scale infrastructure. Agents need to be discovered, identified, monitored, configured, and, under carefully defined conditions, controlled. But unlike traditional network devices, AI agents may operate through different frameworks, models, memory systems, execution environments, and levels of operational authority. The Simple Agent Management Protocol (SAMP) was introduced to address this challenge. Its initial Internet-Draft was published on 17 August 2026\. By 26 October 2026, the specification had reached revision -04, introducing SAMP protocol version 0.2. This article examines how the protocol evolved, the engineering problems encountered along the way, and the architectural decisions that shaped its current design. ### The Starting Point: A Management Problem Network engineers have spent decades managing heterogeneous infrastructure. Routers, switches, firewalls, servers, and applications may serve different purposes, but operational management follows recognizable principles. We need to know: - What exists in the environment? - Is it reachable and operational? - What information and capabilities does it expose? - What configuration changes are permitted? - Who is authorized to perform an operation? - What happens when communication fails? - How can we determine whether an operation actually succeeded? These questions become more complicated when the managed entities are AI agents. An agent might be responsive while its underlying workload is stalled. It might expose powerful tools but lack authorization to invoke them. It might report that a corrective operation succeeded without providing independently verifiable evidence. And when a management request times out, retrying it may have consequences. **The central idea behind SAMP is that AI agents need a management plane independent of their reasoning and collaboration mechanisms.** SAMP does not attempt to replace MCP, A2A, OpAMP, or existing observability technologies. It defines a management relationship between a SAMP Manager and a managed SAMP Agent. That distinction has remained fundamental throughout the protocol's development. ### Revision -00: Establishing the Foundation **Published: 17 August 2026** The first revision introduced the essential architectural model. A SAMP Manager maintains information about managed agents and performs management operations. A SAMP Agent exposes an operational interface through which it can announce its presence, report information, and respond to authorized management requests. The initial specification included: - Discovery and enrollment. - Agent identity and management profiles. - Heartbeat and state inspection. - Asynchronous event delivery. - Event subscriptions. - Controlled configuration. - Policy-gated execution. - Authentication and replay protection. - Conformance tiers. The original draft defined nine PDU types, including a separate DISCOVER\_ACK response. The objective was straightforward: establish a concrete protocol that could be reviewed and implemented. But defining operations is only the beginning. The next challenge was to determine exactly what those operations mean under real deployment conditions. ### Revision -01: Clarifying the Operational Contract **Published: 1 September 2026** Revision -01 focused on making the protocol's operational behavior more precise. One important change was the simplification of the PDU model. The separate DISCOVER\_ACK type was removed. DISCOVER requests and responses were represented using the same PDU type, distinguished by the common direction field. The protocol consequently moved from nine PDU types to eight. This was a small change with an important design principle behind it: **A protocol should not introduce additional operations when existing message semantics can express the required behavior clearly.** Revision -01 also refined several other areas. ### Endpoint Deployment and Failure Domains A SAMP endpoint may be embedded within the managed agent, implemented as a sidecar, operated by a supervisor, or exposed through a gateway. However, these deployment models do not offer identical guarantees. If an agent crashes, an embedded management endpoint may disappear with it. An independent supervisor may remain operational and retain the ability to collect evidence or perform recovery actions. Therefore, endpoint placement and its relationship to the managed workload's failure domain became explicit architectural considerations. ### Security and Management Policies The revision clarified authentication-tag handling, request identifiers, replay protection, canonicalization, and configuration and execution policies. CONFIG operations were constrained through declared writable fields and local policy. EXEC remained disabled by default, with explicitly declared commands and typed parameters required for controlled operation. ### Runtime Evidence Revision -01 introduced a format-neutral runtime-evidence interface. The protocol could carry evidence associated with management operations without requiring a particular verification technology. This established an important separation between management messaging and the systems responsible for producing or validating evidence. ### Revision -02: Trust, Liveness, and Execution Uncertainty **Published: 11 September 2026** Revision -02 addressed several foundational operational questions. ### Being Reachable Is Not Being Trusted Traditional monitoring often treats reachability as a primary indicator of operational availability. For AI agents, this is insufficient. An endpoint might respond to a heartbeat while its enrollment has been revoked. An agent might remain trusted while temporarily disconnected. SAMP therefore formalized two independent state dimensions. **Trust** represents the Manager's enrollment and security disposition. **Liveness** represents the observed reachability of the SAMP endpoint. Neither dimension automatically determines the other. This distinction prevents monitoring observations from being mistaken for security decisions. ### Requested Isolation Is Not Confirmed Isolation A Manager may decide that an agent must be quarantined. But requesting quarantine does not prove that isolation occurred. The protocol consequently distinguishes the management decision from the enforcement result. Quarantine enforcement may be requested, applied, failed, or indeterminate. The distinction matters especially when enforcement depends on a component that shares the managed agent's failure domain. ### More Precise Profiles and Outcomes Revision -02 also strengthened typed profile declarations, profile revisions, enrollment semantics, and configuration and execution outcomes. A particularly important development was the explicit treatment of uncertain execution. Consider a management operation that causes an external effect. The operation executes successfully, but the response is lost. The Manager observes a timeout. **Does the timeout mean the operation failed?** No. It means the Manager does not know the result. Automatically repeating the operation could trigger the same external effect again. SAMP therefore developed recorded-state, retry, and outcome semantics that distinguish execution success, failure, and uncertainty. The protocol makes no general exactly-once execution guarantee for arbitrary external effects. ### Revision -03: Authorization Must Be Bound to the Exact Action **Published: 26 September 2026** Revision -03 introduced a more explicit authorization architecture for consequential management operations. This development addressed an important security boundary. Revision -03: Authorization Must Be Bound to the Exact ActionAuthentication proves the identity associated with a management exchange. It does not automatically authorize every operation that identity might request. Likewise, a Manager's trusted relationship with an Agent does not imply unrestricted execution authority. SAMP therefore introduced an authorization-context contract for CONFIG and EXEC. The contract binds a trusted authorization decision to information such as: - The authenticated Manager and originating principal. - The target Agent and its enrollment context. - The exact requested operation. - The authenticated request digest. - The applicable policy context. - Authorization validity and relevant approval or delegation references. The final Policy Enforcement Point must verify the authorization decision before admitting the operation. ### Natural Language Is Not an Authorization Boundary This requirement becomes particularly important when management operations originate from conversational interfaces. A natural-language instruction may express an operator's intention, but it is not itself a deterministic, authorization-ready management request. Before a consequential operation is performed, the intended action must be resolved into a specific target, operation, and parameter set. Authorization can then be evaluated against that exact action. ### Evidence and Recovery Revision -03 also refined deterministic authorization-error behavior, audit-persistence reporting, and bounded evidence-backed resolution of previously indeterminate operations. The objective was not merely to decide whether an operation could execute. It was to establish how its authorization and subsequent outcome could be evaluated, recorded, and safely reconciled. ### Revision -04: SAMP Version 0.2 **Published: 26 October 2026** Revision -04 introduced SAMP protocol-envelope version 0.2. Unlike an ordinary editorial revision, this represents an explicit compatibility boundary. The revision retains the eight core PDU types but refines several important aspects of the protocol. ### 1\. Recorded-State Revisioning CONFIG and EXEC outcome records now include explicit record\_revision semantics. This allows an operation's recorded state to evolve without erasing the history of previous observations. For example, an execution initially recorded as indeterminate may later be resolved through validated evidence. That subsequent resolution is represented as a new authoritative record revision, rather than silently replacing the pRevision -04: SAMP Version 0.2revious state. This strengthens reconciliation and auditability. ### 2\. Evidence Provenance and Time Runtime evidence may originate from independent systems with different observation times and clock characteristics. Revision -04 refines evidence freshnRevision -04: SAMP Version 0.2ess, historical verification, and optional effect-time representations. The specification explicitly avoids inventing an absolute event order when the available evidence cannot establish one. Evidence must be evaluated according to what it actually proves. ### 3\. Profile and Observation Lifecycles An authenticated agent profile and a live operational observation are different kinds of information. A profile announcement describes declared capabilities and management characteristics. QUERY and PUSH may report rapidly changing operational state. Revision -04 clarifies these separate lifecycles, preventing runtime observations from being confused with changes to authenticated profile declarations. ### 4\. Extension and Version Handling The revision introduces optional supported-extension metadata while retaining strict requirements for core protocol operations. SAMP 0.2 also formalizes version-handling boundaries. Earlier experimental implementations cannot be assumed to support the new consequential-operation requirements merely because they previously used SAMP version 0.1. Compatibility must be explicit, not accidental. ### What the Five Revisions Have Taught Us Several engineering principles have become increasingly important throughout SAMP's evolution. **First, observation is not authority.** Knowing that an Agent exists or responds to management traffic does not establish that it is trusted or authorized to act. **Second, a requested operation is not a confirmed result.** Configuration, execution, quarantine, and recovery must distinguish intention from enforcement and observed outcome. **Third, a timeout is not proof of failure.** Distributed management systems must preserve uncertainty rather than manufacture certainty. **Fourth, evidence is only as useful as its provenance and verification.** A runtime's own assertion cannot automatically substitute for independently established facts. **Fifth, protocol simplicity requires disciplined boundaries.** SAMP must not become another agent framework, orchestration system, identity provider, or universal security platform. Its responsibility is the management-plane contract. These principles are not unique to AI systems. Many have been fundamental to reliable distributed infrastructure for decades. What changes is the environment in which they must now be applied. ### From Specification to Implementation Protocol development must eventually confront implementation reality. The Agent Management System (AgMS) is an experimental, Alpha-stage software project developed to explore SAMP-based management across heterogeneous AI-agent environments. Implementation work has exercised discovery, management exchanges, monitoring, events, authentication, framework integration, and controlled operational failure scenarios. This practical experience helps reveal protocol ambiguities and architectural assumptions that may not be obvious from a specification alone. However, successful local tests are not equivalent to independent conformance. The existing implementation experience predates portions of the SAMP-04 authorization, evidence, and recorded-state requirements. Complete conformance and independent interoperability validation remain open engineering objectives. Future articles in this series will examine these implementation challenges in greater detail. ### The Next Challenge: Independent Interoperability SAMP remains an individual Experimental Internet-Draft. It has not been adopted by an IETF Working Group and is not an IETF Standard. Its development now requires continued technical review, independent implementations, negative testing, and interoperability experiments. A particularly important direction is the interaction between SAMP's management-plane mechanisms and complementary technologies for runtime verification and exact-action authorization. These include potential experimental interoperability with **Correctover Conformance Shape (CCS)** and **EMILIA**. Such work should be evaluated through explicit technical contracts and reproducible results, not assumptions of compatibility. The broader objective remains unchanged: **Establish whether heterogeneous AI agents can be managed through a consistent, secure, and interoperable operational management plane.** Five revisions have helped make the problem and the proposed protocol contract more precise. The next challenge is to test those decisions across independently developed systems. ### Review the Protocol The complete publication history is available through the IETF Datatracker: - [SAMP-00, 17 August 2026](https://datatracker.ietf.org/doc/draft-efstathiou-samp-agent-management/00/?ref=samp-protocol.org) - [SAMP-01, 1 September 2026](https://datatracker.ietf.org/doc/draft-efstathiou-samp-agent-management/01/?ref=samp-protocol.org) - [SAMP-02, 11 September 2026](https://datatracker.ietf.org/doc/draft-efstathiou-samp-agent-management/02/?ref=samp-protocol.org) - [SAMP-03, 26 September 2026](https://datatracker.ietf.org/doc/draft-efstathiou-samp-agent-management/03/?ref=samp-protocol.org) - [SAMP-04, 26 October 2026](https://datatracker.ietf.org/doc/draft-efstathiou-samp-agent-management/04/?ref=samp-protocol.org) [Current SAMP Internet-Draft](https://datatracker.ietf.org/doc/draft-efstathiou-samp-agent-management/?ref=samp-protocol.org) [Contribute to SAMP](https://samp-protocol.org/contribute/) Technical feedback: [**ietf@samp-protocol.org**](mailto:ietf@samp-protocol.org) --- *SAMP Engineering Notes is a technical article series examining the design, development, implementation, security, and interoperability challenges of the Simple Agent Management Protocol.* *Next: From SNMP to SAMP: Managing AI Agents.*