SAMP Engineering Notes #06

SAMP in Practice: Introducing AgMS Alpha.

Designing a protocol is one challenge.

Making it work with real systems is another.

And discovering what happens when those systems fail is where engineering becomes particularly interesting.

The Simple Agent Management Protocol (SAMP) was developed to address a fundamental operational problem: how to manage heterogeneous AI agents through a consistent, vendor-neutral management plane.

But a protocol specification alone cannot demonstrate whether its architecture works in practice.

It must be implemented, exercised, challenged, and tested against real operational conditions.

This is why the Agent Management System (AgMS) was created.

Inspired by traditional Network Management Systems (NMS), AgMS is an experimental management application designed to explore SAMP-based operational management across heterogeneous AI-agent environments.

AgMS is currently in Alpha development.

It is neither a production-certified management platform nor an independently validated implementation of every SAMP version 0.2 requirement.

It is something equally important at this stage of development:

A working engineering environment in which protocol assumptions can be tested against real AI agents, real communication paths, and real failures.

1. The Problem: Running Agents Is Not the Same as Managing Them

Imagine an infrastructure environment containing several AI agents.

One agent performs software development tasks.

Another investigates security events.

A third coordinates automation workflows.

Others provide research, operational assistance, or access to external tools.

Each may use a different framework, model provider, memory mechanism, and execution environment.

Individually, these systems may function correctly.

But operating them together raises familiar infrastructure-management questions.

• Which agents are currently available?
• Which framework and runtime does each agent use?
• Which agents are performing useful work?
• Which agents have stopped responding?
• Which capabilities are exposed for management?
• Which operational events require attention?
• How can an operator distinguish a transient communication failure from a persistent problem?
• Which management actions are permitted?
• What evidence exists about the outcome of an intervention?

Without a common management approach, operators may depend on separate dashboards, framework-specific APIs, terminal sessions, logs, and manually maintained inventories.

That may be manageable for a small experiment.

It becomes increasingly difficult as the environment grows.

The ability to deploy an AI agent does not automatically provide the ability to manage it reliably.

This is the distinction that motivated both SAMP and AgMS.

2. From Network Management Systems to AgMS

Network engineers have spent decades developing systems capable of managing heterogeneous infrastructure.

A traditional NMS does not need to understand the complete internal implementation of every router, switch, or firewall.

Instead, it communicates through defined management interfaces, collects operational information, evaluates state, receives notifications, and performs permitted management operations.

This separation allows the management platform to concentrate on operational visibility and control.

AgMS applies the same architectural philosophy to AI agents.

The objective is not to create another AI-agent framework.

Nor is it to replace the tools agents use for reasoning, communication, or task execution.

The objective is to manage AI agents as operational infrastructure.

In this architecture:

• SAMP defines the management protocol.
• AgMS provides the experimental management application.
• SAMP-compatible endpoints expose management information and operations.
• Framework adapters translate between framework-specific runtime information and the management interface.
• Operators interact with the management environment through a central application.

This relationship resembles the distinction between an established management protocol and the Network Management System using that protocol.

However, SAMP and AgMS remain separate projects.

SAMP is the protocol. AgMS is an implementation environment.

AgMS-specific application features do not automatically become normative SAMP requirements.

3. What Has Actually Been Built?

AgMS development has progressed beyond the initial minimal proof of concept.

The Alpha environment includes practical work across several areas.

Centralized Agent Visibility

AgMS provides a management interface in which information about multiple managed agents can be presented together.

The objective is to reduce dependence on individual framework consoles for routine operational visibility.

Agent Registration and Inventory

The management environment maintains information about known agents and their exposed management identities.

This supports the development of a consistent inventory across different runtime environments.

Operational Monitoring

The application supports management-side observation of agent status, reachability, and available operational information.

Periodic collection mechanisms allow management observations to be refreshed without requiring the operator to manually interrogate each endpoint.

Management Protocol Processing

Experimental SAMP components handle message envelopes, supported operations, request correlation, authentication, validation, and errors.

Implementation work has included Python-based management components and Rust-based protocol components.

Events and Diagnostics

Operational events and relevant diagnostic information can be collected and presented to the operator.

This provides an experimental foundation for investigating failures and changes in managed-agent behavior.

Framework Integration

AgMS development includes adapters, sidecars, and integration mechanisms intended to expose management functionality for different AI-agent runtimes.

Controlled Failure Testing

The Alpha environment has been exercised using scenarios involving timeouts, temporarily unavailable endpoints, interrupted management communication, and recovery.

These capabilities provide meaningful engineering experience.

They do not imply that every supported operation, every adapter, or every SAMP-04 security requirement has been independently validated.

4. Managing Heterogeneous Agents

One of the most important requirements for AgMS is heterogeneity.

A management protocol that works only with a single agent framework would solve a much narrower problem.

Real environments may contain coding agents, conversational agents, autonomous workflow engines, and specialized operational agents.

AgMS development has involved several such technologies.

Examples include:

These integrations do not all provide identical capabilities.

Some may expose management information through a sidecar.

Others may rely on an adapter or another integration component.

Some operations may be supported only in a restricted form.

A framework's inclusion in the AgMS environment does not establish that it implements the entire SAMP 0.2 protocol.

That is an important distinction.

Heterogeneous management does not require identical internal implementations. It requires well-defined management contracts and clearly documented differences.

The engineering challenge is to determine which management semantics can be implemented consistently and where framework-specific limitations must remain explicit.

5. The Management Endpoint Is Not Necessarily the AI Agent

An important architectural decision in SAMP is that the management endpoint and the underlying AI workload are not necessarily the same component.

Consider a coding agent operating through a command-line environment.

Its primary purpose is to process instructions, inspect files, generate code, and interact with development tools.

It was not necessarily designed to expose a complete operational management protocol.

A sidecar or adapter can provide a SAMP-oriented management interface without redesigning the coding agent itself.

The resulting arrangement separates two responsibilities.

The AI workload performs its assigned tasks.

The management endpoint exposes the supported operational-management contract.

For example, an adapter may expose:

• Management identity.
• Endpoint reachability.
• Declared capabilities.
• Selected runtime observations.
• Supported diagnostic information.
• Operational events.
• Explicitly permitted management controls.

However, an adapter must not imply capabilities that the underlying runtime cannot provide.

An adapter that can observe a process does not necessarily possess authority to terminate it.

A sidecar that can report availability does not necessarily survive the workload's failure.

And a management endpoint that exposes runtime information must not automatically disclose credentials, hidden prompts, or unrestricted memory content.

These are implementation boundaries, not merely documentation details.

6. A Typical AgMS Management Workflow

Consider a hypothetical coding agent connected to the experimental AgMS environment through a SAMP-compatible sidecar.

The management workflow may proceed through several stages.

Discovery

The endpoint announces its identity and management profile through DISCOVER.

The Manager processes the announcement and maintains the relevant registry information.

Discovery alone does not establish trust.

Enrollment and Trust

The management environment evaluates the endpoint according to its configured enrollment and trust requirements.

SAMP separates authoritative trust state from observed reachability.

An endpoint responding to requests is not automatically trusted.

Heartbeat

The endpoint sends PING requests toward the Manager.

This is a distinctive aspect of SAMP's management model.

PING is Agent-initiated.

Valid heartbeat exchanges contribute to the Manager's assessment of endpoint reachability.

Operational Queries

The Manager requests supported information through QUERY.

The endpoint returns values permitted by its declared management interface.

Event Reporting

The endpoint may report operational conditions through PUSH.

The management application can present relevant events and diagnostic information.

Controlled Intervention

Where a declared management operation is supported, the Manager may request a configuration change or execution action.

Such operations remain subject to applicable authorization, policy, and enforcement requirements.

Not every experimental integration supports consequential management operations.

EXEC remains disabled by default under the SAMP specification.

This workflow illustrates how a heterogeneous agent can participate in a common management environment.

It is not a claim that every current AgMS adapter implements every stage or every SAMP-04 requirement.

7. From Periodic Monitoring to Operational Awareness

One of the practical advantages of a centralized management environment is the ability to observe changes over time.

A single query provides a snapshot.

Repeated observations can provide additional operational context.

For example, an endpoint may respond successfully to a management request, then become temporarily unavailable, and later recover.

The management application can present those observations as a sequence rather than as isolated responses.

This matters because operators rarely investigate a failure using only the current state.

They want to understand:

• When was the endpoint last observed?
• What was its previous state?
• Was there a communication timeout?
• Was the failure temporary?
• Did the endpoint recover?
• Did the workload itself recover, or only the management interface?
• Were relevant events recorded?

AgMS includes development work for periodic collection and operational state presentation.

But the collected information must be interpreted carefully.

Endpoint reachability is not workload correctness.

A successful management request does not establish that an AI agent is successfully completing its assigned tasks.

This distinction, introduced in the SAMP specification, becomes especially important when building a real dashboard.

8. When the Management System Finds a Real Problem

There is a particularly important difference between a demonstration designed to show a failure and a management system that discovers an actual operational problem.

In the experimental AgMS environment, management visibility has already helped identify real issues affecting individual agent runtimes.

These were not simply failures invented for a scripted presentation.

They were operational conditions encountered while working with the agent environment.

That experience matters because it illustrates the practical value of management separation.

An agent may fail to complete its assigned work.

An adapter may stop responding.

A runtime dependency may become unavailable.

An external service may introduce delays or timeouts.

Without consolidated monitoring, these conditions may remain visible only in separate application logs or terminal sessions.

With management-side observations, the operator has a more consistent starting point for investigation.

This does not mean AgMS automatically diagnoses every failure.

Nor does it mean that every unavailable endpoint represents a failed workload.

It means that a management system can make operational conditions visible and help an engineer determine what requires investigation.

A useful management system does not need to prevent every failure. It needs to help operators recognize, understand, and respond to failures.

This is one of the central lessons carried from traditional NMS engineering into AgMS.

9. Failure Injection: Engineering Beyond the Happy Path

Successful protocol exchanges are necessary.

They are not sufficient.

Distributed systems fail in ways that do not always produce clean error messages.

A request may time out.

A service may become temporarily unavailable.

A response may be delayed.

A process may recover before the next management observation.

AgMS development has included controlled scenarios intended to exercise these conditions.

Examples include:

• Management API timeouts.
• Temporarily unreachable endpoints.
• Lost or delayed heartbeat observations.
• Interrupted communication paths.
• Transient runtime failures.
• Recovery after temporary loss of availability.

These tests help evaluate how the management application presents failures and subsequent recovery.

A Typical Failure Scenario

Imagine a managed endpoint that normally responds to periodic management interactions.

A communication interruption occurs.

The Manager no longer receives expected responses.

The operational interface must represent the condition without inventing information about the underlying workload.

Later, communication is restored.

A fresh authenticated exchange establishes renewed endpoint reachability.

The application may then update its operational presentation.

But the recovery of reachability does not automatically establish that every workload subsystem is healthy.

Nor does it independently change the agent's trust disposition.

This is precisely why SAMP separates trust, liveness, and operational observations.

Failure Injection Is Not Complete Conformance Testing

There is another important distinction.

A demonstration showing a recoverable API timeout does not establish correct handling of every consequential EXEC retry scenario.

Likewise, a successful heartbeat-recovery test does not prove compliance with all enrollment-replacement or recorded-operation requirements.

SAMP-04 defines substantially more demanding contracts for authorization, operation identity, audit persistence, replay handling, and outcome reconciliation.

Those require their own implementation and testing evidence.

Passing a failure demonstration is useful. Claiming guarantees that were not tested is not.

10. Making Operational Behavior Visible

One of AgMS's development objectives is to present agent-management behavior in a form operators can understand.

This is particularly important when demonstrating distributed operations.

A traditional command-line trace may contain the necessary technical information.

However, an operator needs to identify the operational significance of those messages.

A useful management interface should answer:

• Which agent is involved?
• What is its current observed state?
• What event occurred?
• What management operation was requested?
• Is an intervention awaiting approval?
• What is known about the result?
• Has a temporary failure recovered?
• What remains uncertain?

AgMS includes an experimental Presenter Mode developed to make management workflows and failure transitions visible during demonstrations.

This presentation layer is an AgMS application feature.

It is not a required SAMP protocol component.

That separation is intentional.

SAMP defines the exchange. AgMS determines how to present it to the operator.

Other management applications may implement entirely different interfaces while preserving the same protocol contract.

11. Security Is Part of the Implementation, Not an Optional Addition

Management interfaces are powerful operational surfaces.

A system capable of observing agents may eventually support configuration changes, process control, or other consequential operations.

Therefore, even experimental management environments require security boundaries.

AgMS development has exercised mechanisms including:

• HMAC-SHA256 authentication.
• JSON Canonicalization Scheme processing.
• Authenticated request correlation.
• Replay-related validation.
• Controlled management interfaces.
• Restrictive operation exposure.
• HTTPS-protected management communication.

These mechanisms support practical evaluation of the SAMP security model.

However, the complete SAMP-04 contract introduces additional requirements, especially for consequential CONFIG and EXEC operations.

These include exact-action authorization, final PEP verification, recorded outcomes, authoritative record revisions, and safeguards for indeterminate effects.

Earlier successful implementation tests do not prove that these later requirements have all been implemented correctly.

The Human Authorization Boundary

AgMS demonstrations may include operator approval in a management workflow.

But a user-interface approval is not automatically equivalent to complete compliance with SAMP-04's authorization context.

For consequential operations, the enforcement component must validate the applicable trusted authorization decision and exact request binding.

The operational principle remains simple:

A management interface must not create authority merely because it provides a button for an action.

The protocol, authorization infrastructure, and enforcement component each have distinct responsibilities.

12. What AgMS Alpha Does Not Yet Prove

Alpha software can provide valuable engineering evidence without being suitable for unrestricted production deployment.

AgMS is no exception.

There are several boundaries that must remain explicit.

Complete SAMP 0.2 Conformance

No claim is made that AgMS and all associated endpoints satisfy every mandatory requirement of SAMP-04.

Independent Interoperability

Same-team integration tests do not establish general interoperability between independently developed implementations.

Universal Framework Support

A successful integration with one framework does not imply that every agent framework can provide equivalent capabilities.

Independent Enforcement

A functioning sidecar does not automatically guarantee containment, restart, or recovery when its managed workload or host fails.

Exactly-Once Execution

SAMP does not promise exactly-once execution of arbitrary external effects.

AgMS must not imply such a guarantee from local request correlation or retry tests.

Production Certification

AgMS is not presented as a production-certified, independently security-audited management system.

These limitations are not reasons to dismiss experimental development.

They identify the work required before stronger claims can be supported.

Engineering maturity is demonstrated by the guarantees a system can prove, not by the guarantees its documentation promises.

13. The Relationship Between SAMP and AgMS

The distinction deserves to be stated clearly.

This separation protects both projects.

SAMP must remain implementable without requiring AgMS.

AgMS may evolve its user interface, storage architecture, visualizations, and operational workflows without changing the SAMP protocol.

The relationship is complementary.

A protocol should not depend on one application to define its meaning. An application should not silently redefine the protocol it claims to implement.

That principle is essential for meaningful interoperability.

14. The AgMS Experimental Demonstration

A demonstration environment has been developed to illustrate selected SAMP-oriented management capabilities.

The demo focuses on operational visibility, heterogeneous agent integration, event handling, management workflows, and controlled failure scenarios.

AgMS Alpha Demo:

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

The environment is experimental.

Its availability, connected agents, exposed capabilities, and presentation may change as development progresses.

A successful demonstration is evidence of the behavior actually exercised.

It is not independent protocol certification.

Visitors should distinguish demonstrated application functionality from mandatory SAMP-04 requirements that remain subject to separate implementation and conformance validation.

For engineers evaluating the design, the most useful questions are not limited to whether the dashboard looks convincing.

They include:

• Which parts are implemented through native SAMP endpoints?
• Which use adapters or management-side integrations?
• What information is directly observed?
• Which information is inferred from another component?
• What happens when the management endpoint becomes unreachable?
• What does the interface show when an outcome is unknown?
• Which controls are independently enforceable?
• Which behaviors have reproducible test evidence?

These questions help turn a demonstration into a useful technical evaluation.

15. What Comes After Alpha?

The next engineering objective is not merely to add more agents to the dashboard.

Increasing the number of managed endpoints is useful only when the underlying management contracts remain correct.

Several priorities follow from the current implementation experience.

Protocol Alignment

Evaluate and implement the mandatory SAMP 0.2 behaviors that are not yet fully validated in AgMS.

Particular attention is required for authorization-context enforcement, recorded-state revisions, and consequential-operation recovery.

Independent Implementations

Test SAMP exchanges between separately developed Manager and Agent components.

This helps identify assumptions that might remain hidden when both endpoints share the same implementation.

Negative and Adversarial Tests

Validate behavior when messages are malformed, authentication fails, authorization expires, records conflict, or an operation's result is genuinely unknown.

Failure-Domain Validation

Determine which management and evidence paths survive specific workload, host, and communication failures.

Evidence and Authorization Interoperability

Investigate optional interoperability with complementary technologies.

Potential areas include runtime-evidence verification involving Correctover Conformance Shape (CCS) and exact-action authorization involving EMILIA.

These are research and interoperability opportunities, not declarations of completed integrations.

Operational Documentation

Publish implementation findings, limitations, negative test results, and reproducible interoperability reports.

Such documentation is essential if external implementers are to evaluate the protocol independently.

16. The Most Important Engineering Lesson

Building AgMS has reinforced an important distinction.

There is a difference between an AI agent performing useful work and an infrastructure system knowing whether that agent is manageable.

An agent may perform its tasks correctly without exposing sufficient operational visibility.

Another agent may expose a responsive management endpoint while its workload is impaired.

A management operation may be correctly authorized but have an unknown execution outcome.

A dashboard may display a reported success while independent verification remains unavailable.

The management plane must preserve these distinctions.

This is not a problem unique to AI agents.

Network engineers have encountered similar challenges in distributed infrastructure for decades.

But AI-agent environments introduce their own operational characteristics and security consequences.

AgMS provides a practical environment in which those characteristics can be investigated.

And SAMP provides the proposed protocol contract against which they can be evaluated.

Conclusion: The Protocol Meets Operational Reality

The Simple Agent Management Protocol began with a familiar engineering question:

How do we manage heterogeneous AI agents as operational infrastructure?

AgMS represents the next part of that investigation.

Through experimental Manager components, agent integrations, monitoring workflows, sidecars, event processing, and controlled failure scenarios, the project has moved beyond a protocol description into practical implementation.

The experience is useful precisely because the environment is not perfect.

Endpoints become unreachable.

Communication fails.

Runtimes behave differently.

Some management capabilities cannot be expressed identically across frameworks.

And important protocol requirements still need further implementation and independent testing.

These are not inconveniences to conceal.

They are part of the evidence required to improve the design.

A management system should not merely show that an agent is running. It should help operators understand what can be trusted, what can be controlled, what has failed, and what remains uncertain.

That is the practical engineering objective behind AgMS.

And it is why SAMP's management-plane architecture must continue to be evaluated against real operational systems.

We designed a management protocol for AI agents. Then we built an experimental management system to discover where the design works, where it fails, and what must be improved.

The protocol defines the contract.

The implementation challenges the assumptions.

The evidence guides the next revision.

That is how engineering progresses.

Technical References

• SAMP Internet-Draft, Revision -04
• SAMP Protocol Overview
• SAMP Implementations
• AgMS Alpha Demo
• 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: Authorization, Evidence and Safe Execution.

Next: What Happens When an AI Agent Fails?