SAMP Engineering Notes #02

For decades, network engineers have managed complex infrastructures built from equipment supplied by different vendors, running different operating systems, and exposing different operational capabilities.

Routers, switches, firewalls, servers, and network appliances may have little in common internally.

Yet operators need consistent answers to familiar questions.

What is running? Is it healthy? What has changed? What can I control? And what happens when something fails?

The Simple Network Management Protocol (SNMP) helped establish a common operational approach to these questions.

Today, AI agents are becoming another class of operational infrastructure.

They run continuously, interact with external systems, retain context, execute tools, and sometimes perform actions with significant consequences.

But their management interfaces remain heavily dependent on individual frameworks, runtimes, and deployment environments.

The Simple Agent Management Protocol (SAMP) approaches this problem from the perspective of network and infrastructure management.

Not by copying SNMP, but by applying some of its most valuable architectural lessons to a fundamentally different class of managed systems.

1. What Network Management Taught Us

The importance of SNMP extends beyond its individual protocol operations.

Its architectural contribution was the separation between the internal implementation of a managed system and the interface used to observe and control it.

An SNMP management environment traditionally contains:

• Managed devices exposing operational information.
• SNMP agents providing access to management instrumentation.
• Managers or Network Management Systems (NMS) collecting information and initiating permitted management operations.
• Management Information Bases (MIBs) defining the structure and meaning of managed objects.
• Protocol operations for retrieving, modifying, and receiving notifications about management information.

The underlying device may be implemented differently by each manufacturer.

The management relationship remains recognizable.

This separation helped operators build management platforms that were not entirely dependent on proprietary device interfaces.

It did not eliminate vendor-specific extensions, implementation differences, or interoperability problems.

But it established an important architectural principle:

Operational management should not require intimate knowledge of every managed system's internal implementation.

That principle is the starting point for SAMP.

2. The Terminology Problem: What Is an Agent?

There is an interesting ambiguity in the terminology.

In SNMP, an agent is traditionally the software entity providing management instrumentation for a managed device or system.

In modern AI systems, an agent is usually a software system capable of performing tasks, interacting with tools, maintaining state, and making decisions within its assigned authority.

These are not the same concepts.

An AI agent may use a language model, a planning mechanism, external tools, persistent memory, and framework-specific execution components.

The SAMP Agent is the logical management endpoint representing that AI system to a SAMP Manager.

It does not have to be the AI workload itself.

The endpoint may be:

• Embedded within the agent process.
• Implemented as a sidecar.
• Provided by an external supervisor.
• Exposed through an AI Agent Gateway.
• Implemented by an infrastructure-control component.

This distinction becomes especially important when the AI workload fails.

A management interface embedded within a failed process may become unavailable precisely when operational control is most urgently needed.

An independently operating management endpoint may be able to preserve monitoring, evidence collection, and certain recovery capabilities.

But its placement alone does not prove such independence.

A management endpoint is only as reliable as the failure domains and enforcement mechanisms supporting it.

3. From Device Management to Agent Management

The basic management questions are familiar.

The objects being managed are different.

A network operator may need to know whether an interface is operational, whether a routing adjacency exists, or whether a configuration parameter has changed.

An AI infrastructure operator may need to know:

• Which AI agents are registered?
• Which runtime or framework hosts each agent?
• What capabilities and tools are exposed?
• Is the management endpoint reachable?
• Is the agent trusted?
• Is the underlying workload actually healthy?
• Which management operations are authorized?
• Can a failing agent be isolated or restarted?
• Can the result of a consequential action be verified?

Some of these questions are observable through familiar monitoring mechanisms.

Others require additional management semantics.

For example, a successful heartbeat establishes that a particular endpoint responded.

It does not necessarily establish that the AI workload is functioning correctly.

Likewise, discovering an agent and authenticating its management traffic does not automatically mean that the agent is trusted or that a Manager may invoke every advertised operation.

SAMP separates these concerns explicitly.

4. SNMP and SAMP: Conceptual Relationships

The two protocols share architectural ideas, but their wire formats, information models, and operational contracts are different.

This comparison describes functional relationships, not protocol equivalence.

SAMP QUERY is not an SNMP GET operation encoded in JSON.

SAMP CONFIG is not a direct replacement for SNMP SET.

And SAMP PUSH should not be interpreted as providing the same delivery semantics as an SNMP INFORM.

SNMP already includes sophisticated security and access-control mechanisms, particularly through SNMPv3's User-based Security Model (USM) and View-based Access Control Model (VACM).

It would therefore be incorrect to suggest that authentication, authorization, or controlled management originated with SAMP.

The more relevant question is:

What additional semantics are necessary when the managed entity is an AI agent rather than a traditional network component?

5. Agent Profiles Instead of Device MIBs

SNMP uses MIB modules and object identifiers to represent manageable information.

SAMP defines structured Agent Profiles.

A SAMP Profile can identify an agent and declare the management capabilities and fields it exposes.

It may include:

• Agent identity and framework type.
• Software and profile versions.
• Profile revision and ordering metadata.
• Declared operational fields.
• Exposed management capabilities.
• Configuration and execution policies.
• Management-impact classification.
• Deployment and failure-domain metadata.

The goal is not to expose an AI agent's entire internal state.

A SAMP Profile is a management contract, not an unrestricted inspection interface.

An agent should not be required to disclose private memory, hidden prompts, credentials, or sensitive runtime internals simply to participate in management.

An equally important distinction concerns profile declarations versus operational observations.

An authenticated profile announcement describes a particular version of the management contract.

Operational information obtained through QUERY or PUSH may change continuously without redefining that contract.

This separation is particularly useful in environments where capabilities, runtime state, and external dependencies evolve independently.

6. Reachability Is Not Trust

Imagine a network management system receiving a successful response from a device.

That response tells the operator something about reachability and the specific information returned.

It does not, by itself, establish that the device is authorized to perform an unrelated operation.

AI-agent management requires the same discipline, with explicit recognition of the agent's enrollment relationship.

SAMP defines independent dimensions for trust and liveness.

Trust states:

• discovered
• pending
• trusted
• quarantined
• rejected
• revoked

Liveness states:

• unknown
• reachable
• stale
• offline

These dimensions are managed separately.

A trusted agent can become offline without automatically losing trust.

An agent may be reachable while quarantined or revoked.

An agent may report that its own runtime is operational, while independent monitoring indicates a different condition.

This produces a more accurate operational picture than reducing everything to a single green or red status indicator.

A responsive agent is not necessarily a trusted agent. A trusted agent is not necessarily a healthy agent.

And neither condition independently establishes permission to execute a consequential management action.

7. Configuration Is Not the Same as Execution

SNMP has long supported management writes through SET operations.

SAMP also supports configuration changes, but distinguishes those changes from explicitly declared execution operations.

Two SAMP PDUs are particularly important.

CONFIG

CONFIG applies changes to supported, declared, and writable configuration fields.

The requested fields must satisfy type validation, profile declarations, authorization requirements, and applicable endpoint policies.

A management system cannot assume that every field exposed for observation may also be modified.

EXEC

EXEC requests execution of an explicitly exposed operation.

Such operations must be declared, typed, and permitted by the applicable management and local enforcement policies.

EXEC is disabled by default.

Unlike an unrestricted shell or natural-language command interface, the SAMP core EXEC model requires an explicit operation contract.

SAMP version 0.2 also requires authorization context for consequential CONFIG and EXEC requests.

That context binds the trusted authorization decision to the specific target, operation, request digest, and relevant policy and enrollment state.

The final Policy Enforcement Point must verify the authorization before admitting the operation.

Being authenticated does not mean being authorized. Being authorized for one action does not authorize another.

These requirements are especially relevant when a conversational AI interface is used to request management actions.

A natural-language instruction must be resolved into a deterministic, structured action before it can cross the authorization boundary.

8. The Real Test: What Happens When Something Fails?

One of the most important lessons from network engineering is that a protocol cannot be evaluated only under successful operating conditions.

Failures are not exceptional design concerns.

They are part of normal distributed-system behavior.

Consider an AI agent that has become unresponsive.

A management system requests an authorized restart through a SAMP endpoint.

The endpoint accepts the operation.

The restart occurs.

But the response never reaches the Manager.

What should the Manager do?

If it assumes that the timeout means failure and blindly repeats the request, it may cause an unintended second operation.

If it assumes success, it may report a state it cannot establish.

Neither conclusion is justified.

The correct initial conclusion may simply be:

The outcome is indeterminate.

SAMP version 0.2 addresses this through explicit operation identity, authenticated request binding, recorded outcomes, and recovery semantics.

CONFIG and EXEC outcomes distinguish the authorization decision from the execution result and its audit-persistence status.

The protocol also defines record revisions that allow later evidence to resolve previously uncertain outcomes.

Importantly, recovery of an operation's recorded state does not authorize repeating its external effect.

SAMP does not claim exactly-once execution of arbitrary external operations.

Its objective is to prevent management systems from concealing uncertainty or treating an ordinary retry as automatic permission to repeat a consequential action.

This is where the distinction between protocol correctness and operational correctness becomes critical.

A syntactically valid response is not necessarily proof of an intended external effect.

9. Evidence and Independent Enforcement

Suppose an operator decides that an AI agent must be quarantined.

The management system sends a request.

The agent reports that it has entered a restricted state.

Is the agent actually isolated?

That depends on who performed the isolation and what evidence is available.

If the same compromised process is responsible for enforcing and reporting its own quarantine, the result may not satisfy the operator's security requirements.

SAMP therefore distinguishes a requested management action from confirmed enforcement.

The protocol also provides mechanisms for carrying runtime evidence without imposing a specific external verification technology.

Relevant evidence may come from an independent supervisor, gateway, enforcement component, or verifier, depending on the deployment.

However, evidence must be evaluated according to its actual provenance, freshness, correlation, and verification guarantees.

A signed or authenticated message is not automatically proof of the external event it describes.

Operational assurance depends on the evidence supporting the claim, not merely on the existence of a response.

This becomes increasingly important when agents can affect infrastructure, security controls, business processes, or other external systems.

10. An NMS for AI Agents: AgMS

SAMP's architectural approach is also being explored through an experimental software system.

The Agent Management System (AgMS) applies Network Management System concepts to heterogeneous AI-agent environments.

AgMS provides an Alpha-stage implementation environment for exploring agent registration, monitoring, operational events, management interactions, and failure behavior.

Experimental integrations include different agent runtimes and management-side components.

The objective is to investigate whether a common management interface can provide consistent operational visibility across frameworks without requiring every framework to adopt the same internal architecture.

The development work also provides practical feedback about where management abstractions succeed, where adapters are necessary, and where operational assumptions fail.

AgMS remains under development.

Its current implementation experience must not be confused with complete, independently validated conformance to SAMP version 0.2.

Explore SAMP Implementations

11. Why Not Simply Extend SNMP?

This is a legitimate engineering question.

SNMP already provides mature management infrastructure, standardized operations, structured data models, notifications, and security mechanisms.

NETCONF/YANG, OpAMP, OpenTelemetry, and other existing technologies provide additional capabilities.

Introducing a new protocol carries real costs:

• Another specification to maintain.
• Additional implementations and adapters.
• Security and interoperability requirements.
• Operational complexity.
• The risk of duplicating existing mechanisms.

SAMP must justify those costs.

Its current design explores a management contract centered on AI-agent identity, enrollment, trust-state ownership, dynamic capabilities, explicitly authorized consequential operations, runtime evidence, and failure-aware outcome reconciliation.

Some capabilities may overlap with existing protocols.

Some may eventually be better expressed through mappings or optional integrations.

The Experimental phase is intended to help determine where SAMP-specific semantics are necessary and where existing technologies should be reused.

The purpose is not to reinvent network management. It is to evaluate how established management principles can be applied consistently to AI-agent infrastructure.

SAMP is inspired by SNMP, but it is not SNMP-compatible and does not define a replacement for SNMP-managed infrastructure.

12. The Management Plane Is Not the Intelligence Plane

There is one architectural boundary worth emphasizing.

SAMP does not attempt to manage how an agent thinks.

It does not prescribe model selection, prompting techniques, reasoning algorithms, memory architecture, or task-planning methods.

It does not replace agent-to-agent communication or tool-access protocols.

Its responsibility is the operational relationship between a management authority and the managed endpoint.

This separation allows AI-agent frameworks to evolve without forcing management systems to depend entirely on framework-specific interfaces.

It also allows operational policy and security controls to be evaluated separately from the agent's internal reasoning process.

That is the architectural objective.

Conclusion: Different Systems, Familiar Engineering Principles

SNMP helped establish a common language for managing heterogeneous network infrastructure.

SAMP investigates whether a comparable management-plane approach can serve heterogeneous AI-agent environments.

The protocols are different.

The managed entities are different.

The operational risks are different.

But the fundamental engineering discipline remains familiar.

Discover what exists. Establish what can be trusted. Observe what is happening. Authorize what may change. Verify what actually happened. And never assume that a missing response means an operation did not occur.

As AI agents become operational infrastructure, those questions become increasingly important.

The challenge is not simply to make agents more capable.

It is to make them manageable, observable, and accountable within the environments where they operate.

That is the problem SAMP was designed to investigate.

Technical References

• RFC 3411: SNMP Management Framework Architecture
• RFC 3416: SNMP Protocol Operations
• RFC 3414: SNMPv3 User-based Security Model
• RFC 3415: SNMP View-based Access Control Model
• SAMP Internet-Draft, Revision -04
• SAMP Protocol Overview
• Contribute to SAMP

Technical feedback: [email protected]

SAMP Engineering Notes is a technical article series exploring the architecture, security, implementation, and interoperability challenges of the Simple Agent Management Protocol.

Previous: The Evolution of SAMP: From -00 to -04.

Next: Inside the SAMP Management Plane.