Agent Status Protocol (ASP): A Lightweight Specification for State Reporting in Multi-Agent Systems
Authors: Diego Gosmar, Deborah A. Dahl, Emmett Coin, Csaba Bolyós, Andreas Zettl
Organizations: Open Voice Interoperability Initiative Linux Foundation AI & Data Turin, Italy · Conversational Technologies Open Voice Interoperability Initiative Linux Foundation AI & Data Plymouth Meeting, PA, USA · ejTalk, Inc. Open Voice Interoperability Initiative Linux Foundation AI & Data Belleville, Michigan, USA · Open Voice Interoperability Initiative Linux Foundation AI & Data Bratislava, Slovakia · Open Voice Interoperability Initiative Linux Foundation AI & Data Berlin, Germany
The Agent Status Protocol (ASP) defines a lightweight way for heterogeneous AI agents to report their operational state to a status server, and for observers such as dashboards to receive that state as soon as it changes. Agents push small JSON events over HTTP POST; the server exposes the aggregated state to observers over Server-Sent Events (SSE). Because an agent that has crashed, hung or been compromised cannot be trusted to report its own failure, ASP does not rely on self-reports alone: the server infers liveness from missed heartbeats, can detect agents that are alive but no longer making progress, and accepts observations from supervisors, guardrails, operators and peers, some of which take precedence over what the agent says about itself while others are shown alongside it. ASP models state along independent dimensions (lifecycle, health, task, floor, governance), so that an agent can be, for example, online, degraded, working on a task and waiting for the floor at the same time. It reuses existing vocabularies: task states from the Agent2Agent (A2A) protocol, floor states from the Open Floor Protocol (OFP), and attribute conventions from the OpenTelemetry GenAI semantic conventions. This paper presents version 0.1 of ASP as a proposal, not as an approved standard. It is a working draft intended to open a discussion, and the authors invite comments, alternative proposals and independent implementations from the community.
Figures & tables
Approach
Lifecycle/health
Liveness
Task
Floor
Governance
Aggregated live view
FIPA Agent Management [ 11 ]
∘
–
–
–
–
∘
A2A [ 2 ]
–
–
✓
–
–
∘
OFP [ 21 ]
–
–
–
✓
–
∘
MCP [ 20 ]
–
–
–
–
–
–
OpenTelemetry GenAI [ 22 ]
–
–
∘
–
–
–
Health probes [ 24 , 16 ]
∘
✓
–
–
–
∘
Table 1: Exposure of agent state to observers in existing approaches and in ASP. ✓: supported; ∘ : partial or limited scope; –: not addressed.
Term
Definition
Agent
An autonomous software component that uses AI models, memory and tools to pursue goals, make decisions or act on behalf of users or other agents, and whose state is reported using ASP, either natively or through an adapter.
Status server
The component that receives ASP events, maintains current state and distributes it. In the reference binding it is an HTTP service run by the operator of a deployment of agents, but its functions may also be embedded in an existing component (Section 4.3 ); its scope is one deployment, not the Internet (Section 4.2 ).
Observer
Any client that consumes aggregated state. The typical observer is a dashboard used by a human operator; other observers are software, such as alerting, autoscaling or orchestration components.
Operator
The human, or the software acting on a human’s behalf (for example an orchestrator, supervisor or autoscaler), responsible for running a deployment of agents. Operator actions such as pausing an agent or setting a governance state reach the status server through a credential authorised for that purpose (Section 12 ).
Event
A single JSON message about one agent, sent to the status server by that agent or by a component authorised to report on it, or generated by the server itself.
Dimension
An independent axis of state (lifecycle, health, task, floor, governance).
Table 2: Terminology.
Figure 1: ASP architecture. Agents and adapters push events; observers receive updates over SSE. Observers include dashboards for human operators and software components; some of them, such as Coordinator Agents or Sentinel Agents, also report on other agents (dashed arrow).
Dimension
Cardinality
Reported via
lifecycle
one per agent
state_change , heartbeat
health
one per agent
state_change , heartbeat
task
one per task
state_change
floor
one per conversation
floor_change
governance
one per agent
state_change
Table 3: State dimensions.
State
Meaning
registering
Announcing itself to the server.
initializing
Loading models, tools and configuration.
online
Active and ready.
idle
Online with no work in progress.
busy
Online with work in progress, and able to accept more.
at-capacity
Online with work in progress and no capacity for further work.
Table 4: Lifecycle states.
Figure 2: Lifecycle transitions. The server-assigned unreachable and the supervisor-reported crashed are reachable from any state and are omitted for clarity. An agent in at-capacity returns to busy when capacity frees up.
State
Meaning
healthy
Operating normally.
degraded
Working with reduced performance, e.g. high latency or fallback to a smaller model.
rate-limited
Temporarily blocked by an upstream provider’s rate limit.
quota-exhausted
Token or cost budget used up.
dependency-down
A required tool, API or MCP server is not responding.
auth-error
Credentials expired or invalid.
Table 5: Health states.
State
Origin
Terminal
Meaning
submitted
A2A
no
Received, not yet started.
queued
ASP
no
Waiting behind other tasks.
working
A2A
no
In progress.
input-required
A2A
no
Needs input from a user or another agent.
auth-required
A2A
no
Needs additional authorisation.
awaiting-approval
ASP
no
Waiting for human-in-the-loop approval.
Table 6: Task states.
State
Meaning
not-joined
Not part of the conversation.
invited
Invited, not yet joined.
joined
Participating and listening.
requesting-floor
Has asked to speak.
has-floor
Currently speaking.
yielded
Has given up the floor.
Table 7: Floor states.
Figure 3: Floor transitions within one conversation. An agent MAY enter the conversation directly in joined without a prior invitation. An invited agent that declines or is uninvited moves directly to left .
State
Meaning
normal
No governance restriction.
sandboxed
Operating with reduced permissions.
quarantined
Isolated after anomalous behaviour, e.g. suspected prompt injection.
policy-violation
Attempted an action forbidden by policy.
under-review
Suspended pending review by an operator, human or software (Table 2 ).
Table 8: Governance states.
Field
Type
Req.
Description
aspVersion
string
yes
Protocol version, e.g. "0.1" .
type
string
yes
One of register , heartbeat , state_change , floor_change , deregister .
agentId
string (URI)
yes
Stable, globally unique agent identifier. A URN is RECOMMENDED.
eventId
string
yes
Unique per event, used for deduplication. UUID RECOMMENDED.
seq
integer
yes
Monotonically increasing per agent and per sender: an agent numbers its own events, and each component that reports on it numbers its own events about that agent. Used for ordering.
ts
string
yes
Event time in RFC 3339 [ 18 ] format, UTC.
Table 9: Common fields of all ASP events.
Method
Path
Purpose
POST
/v1/events
Submit one event.
POST
/v1/events:batch
Submit an array of events, for agents buffering during brief outages.
POST
/v1/traces
OPTIONAL. OTLP/HTTP ingest; the server maps spans to ASP events (Section 9.3 ).
Table 10: Ingest endpoints.
HTTP status code
Meaning
202 Accepted
Event accepted.
400 Bad Request
Malformed JSON or schema violation.
401 Unauthorized
Missing or invalid credentials.
409 Conflict
Event sent before register , or invalid transition (e.g. out of a terminal task state).
429 Too Many Requests
Agent exceeds the server’s rate limit; retry after the Retry-After header.
Table 11: HTTP status codes returned by the ingest endpoints.
Method
Path
Purpose
GET
/v1/agents
Snapshot of current state for all agents.
GET
/v1/agents/{agentId}
Snapshot for one agent, including open tasks and conversations.
GET
/v1/stream
SSE stream of state updates.
Table 12: Distribution endpoints.
A2A element
ASP
Task.status.state
state_change with dimension: task ; values map one-to-one to the A2A-origin states in Table 6 .
Task.id
taskId
contextId
contextId
Agent Card name , version , skills
register fields name , version , capabilities
TaskStatusUpdateEvent
Source events for an adapter observing A2A streaming traffic.
Table 13: Mapping from A2A to ASP.
OFP element
ASP
Conversation id
conversationId
requestFloor
floor_change to requesting-floor
grantFloor
floor_change to has-floor for the recipient
yieldFloor
floor_change to yielded
revokeFloor
floor_change to floor-revoked
invite
floor_change to invited
Table 14: Mapping from OFP to ASP.
OpenTelemetry
ASP
gen_ai.agent.id
agentId
gen_ai.agent.name
name
invoke_agent span start
task working
invoke_agent span end, status OK
task completed
invoke_agent span end, status ERROR
task failed
gen_ai.usage.input_tokens
metrics.tokensIn
Table 15: Mapping from OpenTelemetry GenAI conventions to ASP.
Figure 4: Illustrative ASP reference dashboard: lifecycle strip and counts (top), agent table sorted by attention needed (left), floor state of an OFP conversation (upper right) and live event stream (lower right).
Operational telemetry is predominantly engineered for human reading: systems repeatedly serialize verbose prose, static keys, and redundant context across billions of log lines. As autonomous AI agents become primary operational consumers, feeding them traditional logs wastes scarce context capacity parsing lexical syntax rather than reasoning over system state changes -- all while lacking cryptographic guarantees of provenance or collection completeness. This paper introduces agent-native telemetry, an operational evidence architecture for autonomous machine operators founded on verifiable state deltas rather than human prose. We present the Agent Telemetry Protocol (ATP) and the State-Delta Evidence Ledger, an implementation that structures operational facts into four core evidence primitives (Transitions, Observations, Relations, and State Checkpoints) governed by content-addressed schemas, while isolating uncurated text as digest-verified opaque references. Producers sign and hash-chain batches for atomic collector append. Verified records feed two parallel agent access paths: a stateless protocol decoder emitting compact positional rows, and a stateful semantic gateway serving bounded graph capsules. We prove an information-preservation lower bound and formalize a ledger-relative verified negative theorem for provable event non-occurrence. On distributed microservice benchmarks (AIOpsLab and OpenTelemetry Astronomy Shop), ATP reduces raw wire payload and modeled cloud query scan costs by 96.4% relative to OpenTelemetry JSON, reduces LLM context tokens by 88.8% and query operations by 66.2%, detects all 500 tested adversarial storage mutations, and yields zero successful prompt injections across 50 adversarial trials per ATP configuration.
When multi-agent LLM systems produce bad answers, not all failures are equal: some answers are grounded in the right material but incomplete, while others are simply ungrounded and should be stopped. Current retry strategies treat both cases identically (try again and hope for the best), leaving human supervisors unable to tell whether a retry was warranted or whether the system should have halted instead. We introduce the Argent Signaling Protocol (ASP), a compact machine-readable header that accompanies every AI-generated response with structured quality signals: certainty (@C), grounding (@G), stochasticity (@S), and an assumption index that classifies the evidentiary basis of each claim. These signals enable a controller to distinguish repairable failures from containment failures and route each case differently. We evaluate ASP in two modes. In standalone mode, a 27-question document-grounded QA benchmark over the Array BioPharma/Ono license agreement compares baseline prompts against ASP-instrumented controller actions across three local GGUF models. On Qwen~(0.8B), ASP improves pass rate from 11.1% to 33.3% and mean term coverage from 36.7% to 65.4%; on Dobby~(8B), ASP produces 4 fail-to-pass recoveries, raising pass rate from 33.3% to 44.4%; on SmolLM3~(3B), ASP alternates between repair and containment per question. Aggregate improvement is meaningful (12/81 to 21/81 passes). In multi-agent mode, an ASP sidecar sits between a retrieval agent and a downstream decision agent; the sidecar blocks 100% of ungrounded upstream outputs from reaching the downstream agent (24/27 blocked, 0 ungrounded propagations).
Large language model (LLM) multi-agent systems (MASs) solve complex tasks through interacting agents, yet their reliability is difficult to analyze because failures depend on both individual agents and how information and errors propagate across the system. Existing approaches largely treat this as post-hoc failure attribution, but do not provide a common model across heterogeneous MAS architectures or support broader analysis of information influence and observability. We introduce AgentSoV, a virtual-sensing framework that models MAS execution as a stochastic dynamic system through Stream of Variation (SoV). AgentSoV maps heterogeneous trajectories into diagnostic stages, constructs virtual measurements from observable outputs, and learns cross-stage variation propagation with a state-space model. Its representation is architecture-aware in stage dependencies yet architecture-agnostic in analytical language, supporting chain-structured, orchestration-based, and directed acyclic graph (DAG)-structured MASs. Without re-executing the MAS, AgentSoV supports three system-level analyses: failure attribution identifies where abnormal variation enters; stage-input influence quantifies how strongly intermediate inputs affect downstream outcomes; and virtual-sensor placement selects complementary observations under a monitoring budget. Experiments across multiple MAS architectures demonstrate a unified approach to fault localization, information influence, and observability. AgentSoV reframes agentic execution as a dynamic system to model rather than merely text to inspect, providing insights for MAS structure and component design.
Congjing Zhang, Siyuan Xu, Yunfei Bai +3
Department of Industrial & Systems Engineering, University of Washington · Department of Electrical & Computer Engineering, Texas A&M University · Amazon