Protocol

An overview of the Simple Agent Management Protocol, including its architecture, operations, agent profiles, trust model, security and relationship to other agent protocols.

Simple Agent Management Protocol

The Simple Agent Management Protocol (SAMP) defines a lightweight, vendor-neutral management plane for heterogeneous AI agents.

It provides a common operational interface through which a management system can discover agents, establish their identity and trust state, inspect their operational status and capabilities, receive events, apply controlled configuration, and invoke explicitly exposed operations under policy control.

SAMP version 0.1 is Experimental and intended for controlled environments, technical evaluation and independent interoperability testing.

Overview

AI-agent environments may contain agents built with different frameworks, models, tool systems and deployment architectures. While emerging protocols address communication, collaboration and tool access, operators still require a consistent way to manage these agents as operational entities.

SAMP introduces two principal roles:

  • The SAMP Manager, which performs management, monitoring and control functions.
  • The SAMP Agent, which exposes a SAMP-compatible management interface for an AI agent or agent runtime.

The protocol does not prescribe how an AI agent reasons, plans, stores memory, selects tools or communicates with other agents. It defines the management relationship between an operational authority and a managed agent.

Architecture

A SAMP deployment consists of one or more SAMP Managers and one or more managed SAMP Agents.

An agent begins in an untrusted or pending condition and may proceed through an enrollment and trust-establishment process before management operations are permitted.

The Manager can then inspect the agent’s profile, monitor its state, receive operational events and perform only those configuration or execution actions explicitly permitted by policy.

SAMP is designed to support heterogeneous environments. A native implementation may expose SAMP directly, while an existing agent framework may use a SAMP adapter or management-side integration.

The protocol is transport-aware but not tied to a specific agent framework, model provider, orchestration platform or cloud environment.

Protocol Operations

SAMP version 0.1 defines the following core operations:

DISCOVER

Initiates agent discovery and the initial exchange required to identify a SAMP-capable endpoint.

PING

Tests reachability and provides lightweight health and liveness information.

QUERY

Requests selected agent profile information, operational state or exposed capabilities.

PUSH

Allows an agent to send operational information or events to a Manager.

SUBSCRIBE

Establishes a subscription to selected event categories or event streams.

UNSUBSCRIBE

Terminates an existing event subscription.

CONFIG

Applies explicitly supported configuration changes under authorization and policy controls.

EXEC

Requests execution of an explicitly exposed operation.

EXEC is disabled by default. Implementations are expected to apply restrictive authorization, policy and audit controls before enabling it.

SAMP operations use correlated request and response semantics, timestamps, sequence information and replay-detection controls.

Agent Profiles

A SAMP Profile describes the identity, state and manageable characteristics of an agent.

Version 0.1 defines profile categories including:

  • identity;
  • health;
  • memory;
  • skills;
  • tools.

Profiles are dynamic. They allow a Manager to determine not only that an agent exists, but also what it is, what it exposes, what state it is in and which management operations may be applicable.

Profile data is subject to validation and authorization. An agent is not required to expose unrestricted internal state, memory content, credentials or sensitive implementation details.

Agent Lifecycle and Trust

SAMP treats enrollment and trust as explicit operational concerns.

The initial trust states are:

  • Pending
  • Trusted
  • Quarantined
  • Rejected

A newly discovered agent does not automatically become trusted. Deployment policy determines the evidence and authorization required for enrollment and trust-state transitions.

A trusted agent may participate in authorized management exchanges.

A quarantined agent remains known to the management system but is subject to restricted operations while investigation or remediation takes place.

A rejected agent is not accepted for normal management operations.

Trust state is distinct from network reachability. An agent may be reachable while remaining untrusted, quarantined or rejected.

Autonomy Classes

AI agents may operate with substantially different levels of independence and authority.

SAMP introduces autonomy classes so that management policy can distinguish between agents that only provide information, agents that recommend actions, agents that act under approval and agents that perform authorized operations autonomously.

Autonomy classification does not grant authority by itself. It provides management context that can be combined with identity, trust state, capability exposure and deployment policy.

Security

SAMP assumes that management operations can affect the confidentiality, integrity and availability of managed agent environments.

Version 0.1 therefore defines or discusses controls for:

  • authenticated management exchanges;
  • message integrity;
  • timestamp and sequence validation;
  • replay detection;
  • request and response correlation;
  • enrollment and trust-state enforcement;
  • rate limiting;
  • restrictive configuration policy;
  • policy-gated execution;
  • error handling and auditability.

The initial specification uses HMAC-SHA-256 for message authentication and SHA-256 over canonicalized JSON for request-digest and replay-processing semantics.

TLS protects transport confidentiality and endpoint communication. Production deployments should use HTTPS and apply appropriate credential management, authorization and key-rotation practices.

EXEC remains disabled by default.

SAMP does not claim to make an unsafe agent safe. It provides protocol mechanisms through which operational policy and security controls can be applied consistently.

Relationship to Other Protocols

SAMP addresses a management-plane relationship that is separate from agent communication and tool-access protocols.

Agent-to-agent protocols focus on communication, collaboration, delegation, task exchange and coordination between agents.

SAMP focuses on operational management between a management system and managed agents.

An agent may use an agent-to-agent protocol for collaboration while simultaneously exposing SAMP for management.

Model Context Protocol

MCP enables models and agents to access tools, resources and context through standardized interfaces.

SAMP does not replace MCP and does not define tool-use semantics. It may report which tools an agent exposes or uses as part of the agent profile, while MCP governs the interaction with those tools.

Open Agent Management Protocol

OpAMP provides management capabilities for telemetry-oriented agents and data-collection components, including configuration, status reporting and lifecycle-related functions.

SAMP draws from similar operational-management principles but is designed around AI agents as managed operational entities, including agent profiles, autonomy classes, enrollment, trust states and policy-gated execution.

The purpose of this distinction is not to create unnecessary protocol duplication. One objective of the Experimental draft is to determine, through technical review and implementation experience, where existing management protocols are sufficient and where AI-agent-specific semantics are required.

Current Specification

The current specification is:

Simple Agent Management Protocol (SAMP)

draft-efstathiou-samp-agent-management-00

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

This is an individual Internet-Draft. It is not endorsed by the IETF and currently has no formal standing in the IETF standards process.

The Internet-Draft remains the authoritative source for normative protocol requirements. This website provides explanatory and project-level material only.