Implementations

From Protocol Design to Experimental Implementation

The Simple Agent Management Protocol (SAMP) is being developed alongside experimental software implementations intended to evaluate its architecture, operational semantics, security mechanisms, and applicability to heterogeneous AI-agent environments.

The current specification, SAMP version 0.2, is defined in draft-efstathiou-samp-agent-management-04, published on 26 October 2026.

Implementation development has progressed beyond the initial minimal proof-of-concept stage.

The Agent Management System (AgMS) provides an experimental management environment in which SAMP concepts and protocol operations are exercised against actual AI agents, framework adapters, and managed runtime environments.

AgMS is currently in Alpha development.

Its purpose is to validate the management model through practical engineering, expose protocol ambiguities, investigate security and failure scenarios, and contribute implementation experience to future SAMP revisions.

AgMS is not production-ready, independently certified, or claimed to be fully conformant with SAMP version 0.2.

Current Implementation Status

SAMP implementation development currently includes the following experimental components.

Agent Management System (AgMS)

AgMS is a management application inspired by established Network Management System (NMS) architecture and designed around the operational requirements of heterogeneous AI-agent environments.

Its development work includes:

• A central management interface for multiple AI agents.
• Agent registration and inventory management.
• Agent identity and profile information.
• Operational status and health monitoring.
• Trust and liveness state management.
• Management request and response handling.
• Periodic collection of operational information.
• Event ingestion and management notifications.
• Authentication and message-integrity controls.
• Agent-specific integration components.
• Operational event history and diagnostic information.
• Controlled failure scenarios and recovery observation.

AgMS provides a practical environment for investigating how AI-agent management behaves when systems are functioning normally, when communications are interrupted, and when individual components become unavailable.

The current implementation should be understood as an evolving engineering system rather than a completed commercial product or certified protocol reference implementation.

SAMP Core Components

Experimental implementation work has included Python-based management components and Rust-based SAMP protocol components.

The development scope includes:

• PDU encoding and decoding.
• Common message-envelope processing.
• Agent profile representation.
• Request and response correlation.
• Authentication and canonicalization.
• Protocol operation handling.
• Error processing.
• Management endpoint integration.
• Automated protocol and component testing.

These components provide implementation experience for the SAMP specification.

Their existence does not establish complete implementation coverage or conformance to every requirement introduced in revision -04.

SAMP Agent Endpoints and Sidecars

A managed AI agent may expose SAMP directly or through an associated management component.

AgMS development has included experimental sidecar and adapter integrations that allow existing AI-agent runtimes to participate in SAMP-oriented management without replacing their internal architecture.

Such components may:

• Expose an agent's management identity and declared capabilities.
• Report endpoint health and operational observations.
• Respond to supported management queries.
• Deliver events and diagnostic information.
• Validate authenticated management requests.
• Enforce local restrictions on supported operations.
• Reject unsupported or policy-disabled requests.

A sidecar's presence does not automatically establish independent enforcement capability.

Its actual guarantees depend on the underlying process, host, control interface, and failure-domain relationship.

Heterogeneous Agent Integration

One of SAMP's primary objectives is to support AI agents built using different frameworks, runtime systems, and model providers.

AgMS has been developed and exercised in a heterogeneous environment that includes coding agents and other AI-agent runtimes.

Experimental integration work has involved technologies such as:

• Codex CLI, through management-side and sidecar integration.
• OpenClaw, through SAMP-oriented adapter development.
• Hermes, as part of the heterogeneous runtime environment.
• Agent Zero, as part of the broader agent integration environment.
• Additional experimental agent services and management integrations.

These integrations may differ substantially in their supported management operations, exposed profile information, endpoint deployment models, and security capabilities.

Inclusion in the experimental environment does not imply that every framework has a complete, independently validated SAMP 0.2 implementation.

The objective is to determine which management capabilities can be expressed consistently across different runtimes, which require framework-specific adapters, and which operational guarantees cannot be provided by a particular integration.

Framework adapters must not expose credentials, private prompts, unrestricted memory content, or sensitive runtime information merely because such information is accessible through the underlying framework.

Operational Management and Monitoring

SAMP distinguishes between an agent's trust relationship, endpoint reachability, and observed operational behavior.

AgMS provides an experimental environment for evaluating these distinctions.

Discovery and Enrollment

A SAMP Agent initiates DISCOVER exchanges with a Manager.

Experimental implementations evaluate agent identification, profile announcements, registration, and subsequent management eligibility.

Discovery does not automatically establish trust or authorize management operations.

Liveness and Health

SAMP uses agent-initiated PING operations for heartbeat reporting.

Management-side observations and supported QUERY operations can provide additional operational information.

SAMP distinguishes between:

• unknown
• reachable
• stale
• offline

These liveness states are separate from enrollment and trust decisions.

An endpoint may be reachable while its managed workload is impaired. Likewise, an agent may become unreachable without automatically losing its existing trust designation.

Periodic Collection and State Inspection

AgMS includes development work for periodic collection of management information and presentation of agent state through a central interface.

Collection behavior depends on the supported management interface, adapter, endpoint availability, and applicable policy.

Where relevant, operational information should distinguish observation time, reception time, source, and subject.

A shared runtime's availability must not be represented as proof that every agent associated with that runtime is healthy.

Operational Events

SAMP PUSH provides an agent-to-Manager mechanism for delivering asynchronous operational events.

Experimental implementation work has exercised event ingestion, event presentation, and associated diagnostic workflows.

The base protocol does not guarantee durable PUSH delivery or provide a general historical event-retrieval mechanism.

Implementations must not silently treat successful HTTP delivery as proof that an event has been durably processed.

Security Implementation

SAMP version 0.2 defines baseline security requirements that implementation work must evaluate.

These include:

• HMAC-SHA256 message authentication.
• RFC 8785 JSON Canonicalization Scheme (JCS).
• Request identification and authenticated correlation.
• Timestamp and freshness validation.
• Replay and duplicate-request protection.
• Credential and enrollment binding.
• Profile declaration and revision validation.
• Trust and liveness separation.
• Restrictive configuration and execution policies.
• Typed operation validation.
• Authorization-context enforcement for consequential operations.
• Recorded-operation and audit requirements.
• Fail-closed behavior where mandatory security state cannot be established.

Non-loopback deployments require HTTPS support and authenticated management communication.

EXEC is disabled by default and requires explicit provisioning.

An authenticated or trusted Manager does not automatically possess authority to execute consequential operations.

Authorization and Execution Boundaries

SAMP-04 defines authorization requirements for CONFIG and EXEC operations, including binding a trusted authorization decision to the exact management request.

The final Policy Enforcement Point must verify the applicable authorization and local restrictions.

SAMP also defines recorded operation outcomes, revision ordering, and safeguards against unsafe re-execution after failures or uncertain responses.

Existing AgMS development experience predates portions of these requirements.

Full implementation and validation of the SAMP-04 authorization, evidence, and recorded-state contracts must therefore be assessed separately rather than inferred from earlier successful tests.

Failure Injection and Recovery Testing

A central objective of AgMS development is to examine how management systems behave when agents, runtimes, or communication paths fail.

Controlled experimental scenarios have included:

• Temporarily unavailable agent endpoints.
• Management API timeouts.
• Lost or delayed heartbeat observations.
• Interrupted communications.
• Transient runtime failures.
• Agent state changes during management workflows.
• Recovery and renewed operational visibility.

These scenarios provide useful implementation experience, particularly around distinguishing temporary communication failures from persistent runtime conditions.

Additional protocol-oriented testing is required for:

• Duplicate consequential requests.
• Lost CONFIG or EXEC responses.
• Indeterminate execution outcomes.
• Restart and recorded-state recovery.
• Conflicting operation revisions.
• Expired or invalid authorization contexts.
• Stale, missing, or contradictory evidence.
• Quarantine requests without confirmed enforcement.
• Replay protection after state loss.

A timeout is not proof that an operation failed, and recovery must not silently authorize repeated execution of a consequential action.

These are central engineering concerns in SAMP version 0.2.

SAMP Conformance Tiers

SAMP version 0.2 defines four additive conformance tiers.

SAMP-Observe

Required operations:

• PING
• DISCOVER
• QUERY
• PUSH

This tier establishes the baseline operational observation capabilities.

SAMP-Subscribe

Includes SAMP-Observe plus:

• SUBSCRIBE
• UNSUBSCRIBE

This tier introduces event subscription management.

SAMP-Configure

Includes SAMP-Subscribe plus:

• CONFIG

Configuration remains subject to field declarations, typed validation, authorization, recorded outcomes, and applicable policy restrictions.

SAMP-Execute

Includes SAMP-Configure plus:

• EXEC

Execution support requires the applicable authorization, admission, outcome, audit, and recorded-state safeguards.

Support for a conformance tier does not imply that potentially consequential operations are enabled in a particular deployment.

Conformance Claims

Conformance must be evaluated separately for Manager and Agent endpoint roles.

All tiers are subject to the mandatory implementation requirements defined in Section 11 of the current Internet-Draft.

A local implementation, automated test suite, or successful demonstration does not establish independent conformance.

No complete SAMP 0.2 conformance claim is currently made for AgMS or its associated experimental adapters.

An independently validated reference interoperability suite is not yet available.

Protocol and Implementation Versioning

Experimental implementations must identify the exact SAMP specification they target.

Current protocol baseline:

draft-efstathiou-samp-agent-management-04

Protocol envelope version:

0.2

Base profile-format version:

0.1

These identifiers serve different purposes.

The Internet-Draft revision identifies a document revision, while the protocol-envelope version identifies the wire protocol.

SAMP 0.2 introduces changes to consequential-operation outcome handling, including mandatory record_revision semantics.

Earlier experimental protocol version 0.1 implementations must not be assumed to support these requirements.

SAMP 0.2 does not define automatic protocol downgrade or mixed-version consequential-operation compatibility.

Any compatibility bridge must be explicitly implemented and documented.

Legacy implementation behavior must not be silently interpreted as native SAMP 0.2 behavior.

Demonstration Environment

An experimental AgMS demonstration environment has been developed to illustrate SAMP-oriented management of heterogeneous AI agents.

AgMS Alpha Demo:

https://demo.samp-protocol.org/demo

The demonstration is intended to illustrate management concepts and selected implementation capabilities, including agent visibility, operational events, management workflows, and controlled failure scenarios.

The environment remains experimental and may be updated, reset, restricted, or temporarily unavailable during development.

A successful demonstration must not be interpreted as independent protocol conformance, a security certification, or a guarantee of production suitability.

Independent Interoperability Testing

Independent interoperability testing remains a major objective of the SAMP project.

Meaningful testing should involve independently developed Manager and Agent components wherever possible.

Priority areas include:

• PDU serialization and protocol version handling.
• JCS canonicalization and HMAC interoperability.
• Agent enrollment and authenticated profile ordering.
• QUERY validation and response semantics.
• PUSH event processing.
• Subscription ownership and expiration.
• CONFIG and EXEC authorization.
• Recorded-state recovery and retry fencing.
• Runtime evidence correlation and validation.
• Trust transitions and quarantine enforcement.
• Endpoint deployment and failure-domain assumptions.

Both successful exchanges and negative test results are valuable.

Interoperability reports should document the exact draft revision, implementation versions, deployment environment, supported conformance tier, observed results, and unresolved limitations.

External Protocol Interoperability

The SAMP project also welcomes experimental interoperability work with independently developed mechanisms for runtime verification and exact-action authorization.

Potential research areas include:

• Correctover Conformance Shape (CCS): Optional runtime-evidence and verification-format interoperability.
• EMILIA: Potential exact-action authorization and independently verifiable authorization-evidence interoperability.

These are opportunities for technical collaboration, not declarations of completed integration.

Any claimed interoperability result should be supported by documented experiments and clearly identified implementation versions.

Source Code and Repositories

AgMS development currently includes private development repositories and experimental implementation components.

Official public source repositories, implementation instructions, test vectors, and interoperability artifacts will be announced when suitable for independent use.

The absence of a public repository does not determine the maturity or validity of the SAMP protocol.

Likewise, the availability of source code does not establish conformance.

Official resources will be referenced from:

https://samp-protocol.org/

No implementation repository should be treated as an authoritative replacement for the published Internet-Draft.

Participation

Independent implementers, framework developers, researchers, and infrastructure operators are invited to participate.

Particularly useful contributions include:

• Independent SAMP Manager implementations.
• Independent SAMP Agent endpoints.
• Framework adapters and sidecars.
• Positive and negative protocol test cases.
• Security and authorization analysis.
• Failure-injection experiments.
• Runtime-evidence verification integrations.
• Interoperability reports.
• Documented implementation limitations.
• Proposed corrections to the Internet-Draft.

Technical contact:

[email protected]

Security-sensitive implementation findings:

[email protected]

For additional information about contributing, please visit:

https://samp-protocol.org/contribute/

Current Specification

Simple Agent Management Protocol (SAMP)

• Protocol version: 0.2
• Internet-Draft: draft-efstathiou-samp-agent-management-04
• Publication date: 26 October 2026
• Intended status: Experimental
• Submission type: Individual Internet-Draft

Official specification:

https://datatracker.ietf.org/doc/draft-efstathiou-samp-agent-management/04/

The published Internet-Draft remains the authoritative source for SAMP protocol requirements and conformance definitions.

SAMP is currently an individual Internet-Draft and has not been adopted or endorsed by the IETF.

Important Notice

SAMP and AgMS are distinct projects with complementary roles.

SAMP defines the management protocol. AgMS is an experimental software implementation used to investigate that protocol in operational environments.

AgMS implementation experience can inform future SAMP development, but AgMS-specific behavior does not automatically become a normative SAMP requirement.

Neither project should be represented as production-certified, independently validated, or endorsed by the IETF.

The objective remains practical and measurable:

Build the management plane. Test it against real agents. Investigate how it fails. Improve the protocol through engineering evidence.