[dmsc] Re: [agent2agent] Re: SAMP: an operational management protocol for heterogeneous AI agents

[Aijun Wang <[e-mail]>]

Hi, Stelio, Guigui and Sumit:

Let’s move this discussion to the DMSC mailing list.

As you may know, DMSC defines an AI agent gateway-based approach.【Please review the DMSC charter here: https://github.com/ietf-dmsc/Charter/blob/main/dmsc-charter.md.】

While reviewing the initial draft https://www.ietf.org/archive/id/draft-efstathiou-samp-agent-management-00.html, I also questioned where the SAMP agent would be deployed.

If we compare SAMP to SNMP as a reference management solution, note that SNMP operates between routers/gateways and management systems — it does not run on end hosts themselves.

>From your earlier conversations, I think you have established that deploying SAMP directly on individual AI agents is unsuitable. There needs to be a standalone entity hosting this service to monitor all connected AI agents under its purview, whether those agents exhibit malicious behaviour or fully compliant behaviour.

I therefore propose that the next revision of SAMP be built atop the AI agent gateway architecture. 

As stated in the DMSC charter excerpt below:

l  Operational visibility, observability, and policy control for AI agent communications and collaboration flows.

Then, SAMP aligns directly with one of DMSC’s core objectives.

We previously hosted a non-WG-forming BoF session at IETF 126 【session link: https://datatracker.ietf.org/meeting/126/session/dmsc】, and we welcome you to join our efforts to advance this work collaboratively.

 

Best Regards

 

Aijun Wang

China Telecom

 

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Saturday, August 22, 2026 7:33 AM
To: [e-mail]
Subject: [agent2agent] Re: SAMP: an operational management protocol for heterogeneous AI agents

 

Sumit,
 
The IPMI analogy is exactly right, and it sharpens the point better than my original comment did. A baseboard controller that depends on the host it is supposed to power-cycle is not a baseboard controller — it is a kernel module. The same applies to a verification component that runs inside the agent's failure domain.
 
On the concrete question for the draft: I think the distinction you are asking for — operations that must succeed against an uncooperative agent versus those that need only work against a cooperative one — is the most important architectural decision SAMP has to make, and it is better made explicitly than left to implementation. If SAMP does not state where the agent-side endpoint runs relative to the agent's failure domain, a reader will assume out-of-band and get in-band, which is the worst of both: the appearance of control without the substance.
 
This is also where the runtime verification plane I mentioned in point 3 connects. CCS receipts are designed to be verifiable by a party that is not the agent, because the signing key is RP-pinned and the verification path does not traverse the agent's own process. A PUSH verdict that carries a CCS receipt is only useful if the push path terminates at a manager that is itself outside the agent's failure domain — otherwise you get exactly the situation you describe: a compromised agent does not emit the verdict, and silence reads as health.
 
On health versus progress: your finding that admitted-but-never-scheduled work stays legitimately pending through the entire measurement window is the kind of empirical result that protocol text should reflect. I agree that SAMP should not carry a progress notion — that belongs to the workload — but stating explicitly that a healthy status establishes liveness only, not forward progress, would prevent the stronger reading.
 
Thanks for the detailed response.
 
Guigui Wang
Correctover — Runtime Verification for Agent Systems

  <https://larkmail-openapi.feishu.cn/gw/v1/edm/track?7676632036307635423>