Agent Status Protocol (ASP): A Lightweight Specification for State Reporting in Multi-Agent Systems

1.1 Motivation

• Inter-agent links and hidden failures make it difficult to see which agents are alive, what they are doing, and which should no longer be trusted.The number of possible pairwise links grows with fleet size, while crashed, hung, rate-limited, looping, or compromised agents can appear merely slow or operational.Source: §1.1 · p. 2

1.2 Application Scenarios

• ASP addresses enterprise fleets, open-floor conversations, safety pipelines, resource control, and regulated deployments with a shared state view and transition history.The examples include routing work away from degraded agents, exposing floor waits, sharing guardrail flags, reacting to quotas, and recording interventions without storing conversation content.Source: §1.2 · pp. 2–3

1.3 Why an Independent Standard

• ASP aims to replace bespoke framework-to-tool integrations with a lightweight shared vocabulary, protocol-neutral reporting, and governance states that can override agent self-reports.Any agent able to send an HTTP POST can report; state is reported without utterances, prompts, or replies, and a missed heartbeat lets the server mark an agent unreachable.Source: §1.3 · p. 3

1.4 Why Not an Existing Health Protocol

• Binary health checks cannot express agent-specific conditions such as waiting for approval, holding the floor, provider rate limits, exhausted budgets, or quarantine.ASP complements host-process health protocols while adding agent-specific dimensions.Source: §1.4 · p. 4

1.5 Why a State Layer on Top of OpenTelemetry

• ASP adds shared state meanings, rules for interpreting missing signals, ordered transition history, and authority over assertions to existing telemetry.It is framed as state semantics and liveness rules on top of telemetry, rather than an alternative to it.Source: §1.5 · p. 4

1.6 Why Push State Instead of Asking the Agent

• Push reporting lets a server infer failures, accept assertions from other authorities, and retain transitions that polling may miss.Polling also requires each observer to reach every agent, with traffic growing as N × M for N agents and M observers.Source: §1.6 · p. 5

1.7 Scope; 1.8 Non-goals; 1.9 Relationship to Existing Standards

• ASP covers registration, deregistration, heartbeats, state transitions, and live distribution, but excludes agent communication, payloads, tracing, discovery, and capability negotiation.It aligns task, floor, and telemetry attributes with A2A, OFP, and OpenTelemetry conventions without depending on those protocols.Source: §1.7 · p. 5, §1.8 · p. 5, §1.9 · p. 5

1.10 Specification Layers

• ASP separates a transport-independent state vocabulary, JSON transition events, and server behavior into layers that implementations may adopt separately.The vocabulary alone may be used as attribute values in logs, spans, or another protocol’s metadata.Source: §1.10 · p. 5

2.1 Agent Communication Protocols

• Communication protocols expose only partial state: ASP addresses the missing live, aggregated observer view while complementing those protocols and reusing their vocabularies.A2A task states are client-visible, Agent Cards are static, and OFP floor events are conversation-specific; none defines agent liveness, health, or governance.Source: §2.1 · p. 6

2.2 Lifecycle Management in Classical Multi-Agent Platforms

• ASP adopts an explicit lifecycle but extends beyond FIPA's single-platform, single-dimension model and its pre-LLM-agent failure assumptions.The cited LLM-agent failure modes include rate limits, exhausted quotas, unavailable tool servers, and suspected prompt injection.Source: §2.2 · p. 6

2.3 Observability of LLM Agents

• Tracing captures past operations, but ASP adds current, content-free agent state and liveness alongside OpenTelemetry identifiers and OTLP ingestion.The passage notes that spans are exported after operations complete and often carry prompts and model outputs.Source: §2.3 · p. 6

2.4 Failure Detection and Health Checking

• ASP uses agent-pushed heartbeats and timeouts to infer liveness, while treating process liveness as one state dimension among health, tasks, floor, and governance.This differs from orchestrator probes, which are sent to the process.Source: §2.4 · pp. 6–7

2.5 Failures, Guardrails and Multi-Party Conversations

• ASP fills a visibility gap left by guardrails and multi-party conversation work: a common runtime signal for agent state and floor ownership.The reviewed work includes threat detection and decisions about isolation or quarantine, but leaves open how alerts and decisions are exchanged and made visible.Source: §2.5 · p. 7

2.6 What ASP Adds

• ASP combines independently varying lifecycle, health, task, floor, and governance states with server-inferred liveness, governance precedence, and reused protocol vocabularies.The profile reuses A2A task states and OFP floor states, uses OpenTelemetry identifiers, and includes mappings for agents that cannot be modified.Source: §2.6 · p. 7
• ASP events carry state without prompts, outputs, or user data, and its state vocabulary can be adopted without the event and behavior layers.Source: §2.6 · p. 7
• Table 1 compares how existing approaches and ASP expose agent state to observers, marking support, partial coverage, or no coverage.Source: §2.6 · p. 7, Table 1 · p. 8

3 Terminology

• MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY follow the interpretations in RFC 2119 and RFC 8174.Source: §3 · p. 8
• The keywords state requirements for conforming implementations if ASP is adopted; they do not imply standards-body endorsement.Source: §3 · p. 8
• Table 2 defines the terms used in the specification.Source: Table 2 · p. 8

4 Architecture

• Agents or adapters send events to the status server, which aggregates state for observers and streams updates over SSE without polling.Agents initiate connections, so they can operate behind NAT or firewalls without inbound ports; active probing is optional.Source: §4 · pp. 8–9, Figure 1 · p. 9

4.1 Observers

• Observers fetch snapshots, subscribe to updates, and may be dashboards, software systems, or agents that also report on other agents.A component can act as an agent, observer, and reporter; ASP carries the resulting state, not those components’ other interactions.Source: §4.1 · pp. 9–10

4.2 Status Server Placement

• Each deployment runs its own status server; servers may coexist, but aggregation across them is out of scope.The server is independent of the conversation protocol, though a floor manager may report floor transitions through an adapter.Source: §4.2 · p. 10

4.3 Deployment Topologies

• A status-server function set is required, but a dedicated server is not; distributing those functions weakens liveness and governance because no component has an authoritative view.The functions include liveness inference, governance precedence, credential checks, event ordering, distribution, and audit history.Source: §4.3 · p. 10

4.4 Stateful and Stateless Agents

• ASP works best with long-running agents that retain operational state; short-lived agents can be represented through a persistent component reporting for them.The distinction concerns operational state, not conversational memory.Source: §4.4 · p. 10

5 State Model

• An agent’s state is a tuple with one value per independent dimension; changing one dimension does not imply a change in another.Table 3 summarizes the dimensions.Source: §5 · p. 11, Table 3 · p. 11

5.1 Lifecycle

• Lifecycle distinguishes idle, busy, and at-capacity; at-capacity means no further work can be accepted, not that the agent is faulty.The server may assign unreachable and a supervisor may report crashed from any state; an event from an unreachable agent restores the state it reports.Source: §5.1 · p. 11, Figure 2 · p. 12

5.2 Health

• Health transitions are unconstrained: any health state may move to any other.Source: §5.2 · p. 11, Table 5 · p. 12

5.3 Task

• Task state is tracked per taskId, allowing an agent to have several tasks open at once; terminal tasks cannot transition further.States originating in A2A are used unchanged, while other task states are ASP extensions.Source: §5.3 · p. 12, Table 6 · p. 13

5.4 Floor

• Floor state is tracked per conversation and describes participation there, not the agent’s overall state.Leaving a conversation stops floor-change events for it, but the agent remains active and may continue reporting other dimensions or join other conversations.Source: §5.4 · p. 13, Table 7 · p. 13

5.5 Governance

• Governance is optional and may be set by the agent, a guardrail, or an operator; observers should prominently display any state other than normal.Quarantined is intended for agents flagged by prompt-injection detection or by a Coordinator Agent acting on Sentinel Agent alerts.Source: §5.5 · pp. 13–14, Table 8 · p. 14

6 Message Types

• ASP defines five event types, each sent as a JSON object in the body of an HTTP POST.Source: §6 · p. 14

6.1 Common Fields

• Table 9 lists fields common to all events; the examples omit aspVersion, eventId, and seq for brevity.Source: §6.1 · p. 14, Table 9 · p. 14

6.2 register

• An agent registers once with each status server before sending any other event, and deregisters when it stops operating in that deployment.Registration requires heartbeatIntervalSec between 1 and 300; healthUrl and stallAfterSec are optional.Source: §6.2 · p. 15

6.3 heartbeat

• Heartbeats signal liveness and should come from the agent’s main work loop; progressSeq tracks completed work steps when included.The optional activity field gives observers a short code for what a long wait is spent on and does not change state.Source: §6.3 · p. 15

6.4 state_change

• A state_change reports a transition in any dimension other than floor, with required dimension, from, and to fields; task transitions also require taskId.An optional reason must not contain sensitive data.Source: §6.4 · pp. 15–16

6.5 floor_change

• A floor_change reports a transition within a conversation using required conversationId, from, and to fields; role is optional.An agent may participate in several conversations, with state tracked per conversationId.Source: §6.5 · p. 16

6.6 deregister

• On clean shutdown, deregister makes the server set lifecycle to offline and stop liveness monitoring for the agent.Source: §6.6 · p. 16

7 Liveness

• A failed agent cannot be relied on to report its own failure, so ASP distinguishes self-reports from independently established state.The protocol addresses silent agents as well as agents that keep reporting while hung or compromised.Source: §7 · p. 16, §7.2 · p. 17

7.1 Heartbeat Timeout

• If no event arrives within 2.5 declared heartbeat intervals, the server marks the agent unreachable and notifies observers.The threshold tolerates one lost heartbeat plus network jitter; the server may keep last-known task and floor states visible as stale.Source: §7.1 · pp. 16–17

7.2 Beyond Heartbeats

• Heartbeat timeout detects silence but not an agent that continues heartbeating while work stops or reports false state; the further mechanisms are optional.Source: §7.2 · p. 17

7.2.1 Progress

• When work is expected, unchanged progressSeq for stallAfterSec lets the server mark health stalled; tasks waiting by design do not trigger this state.A task can also declare maxDurationSec, after which the server may mark a still non-terminal task timed-out.Source: §7.2.1 · p. 17

7.2.2 Active Probing

• Optional active probing can refine the reason for a missed heartbeat, distinguishing a failed probe from an answering agent whose reporting path has stopped.Probing requires a declared healthUrl reachable by the server and does not restore the agent’s state.Source: §7.2.2 · p. 18

7.2.3 Independent Observation

• Other components may report observations: lifecycle reports from the server or supervisor override self-reports, peer health observations appear alongside them, and governance follows authority precedence.Operator outranks guardrail, which outranks self; only equal- or higher-authority components can clear governance states.Source: §7.2.3 · p. 18

7.2.4 Compromised Agents

• No liveness mechanism alone reveals a compromised agent that emits valid heartbeats and false states indefinitely.ASP limits damage through governance precedence, displaying independent observations alongside self-reports, and optional credential revocation after quarantine.Source: §7.2.4 · p. 18

8.1 Ingest (Agent to Server)

• The ingest rules require ignoring duplicate eventIds and recording older same-sender sequence numbers without letting them overwrite current state.Table 10 and Table 11 are identified as listing ingest endpoints and response codes.Source: §8.1 · p. 19, Table 10 · p. 19, Table 11 · p. 19

8.2 Distribution (Server to Observers)

• Observers should fetch a snapshot before opening the SSE stream, whose server sequence IDs let reconnecting clients receive missed updates.Each SSE message carries the ASP event as data and its event type as the event field; streams may accept filters.Source: §8.2 · p. 19, Table 12 · p. 19

8.3 Alternative Transports

• WebSocket, gRPC streaming, or broker bindings may be defined for high-scale deployments, but they are outside this draft.Any future binding must carry the same event schema.Source: §8.3 · p. 19

9 Mappings to Existing Standards

• Mappings let adapters generate ASP events from existing protocol-speaking agents without modifying those agents.A2A-only agents report no floor dimension because A2A has no notion of floor.Source: §9 · pp. 19–20

9.2 OFP

• OFP uninvite and bye both map to left, while the reason distinguishes convener-directed removal from voluntary departure.The OFP event names should be revalidated against the version in use; manifest exchange has no ASP state counterpart because it is one-time capability information and negotiation is out of scope.Source: §9.2 · p. 20

9.2.1 What an Adapter Can and Cannot Infer

• Conversation events reveal floor transitions and participation, but cannot distinguish a long model call, waiting, or a stuck agent; adapters should leave unobservable dimensions unreported.Lifecycle, health, progress, and activity require runtime signals rather than conversation traffic alone.Source: §9.2.1 · p. 20

9.3 OpenTelemetry

• OpenTelemetry GenAI conventions supply reusable identifiers and metrics, but spans alone cannot express lifecycle, health, or floor states.An agent ingested only through OTLP shows task state and relies on span arrival for liveness; the recommended metrics are optional.Source: §9.3 · p. 21, Table 15 · p. 21

• Moderator names the example agent, while convener is its OFP role in one conversation; agents send events to one server, which forwards state over SSE.The same agent may hold different roles in different conversations, and any agent may be convener.Source: §10 · p. 21
• The Planner reports separate floor-request and floor-granted transitions six seconds apart, while the Research Assistant reports task input required with a clarification reason.The example also shows the Planner registering with its version, protocol, capabilities, and heartbeat interval.Source: §10 · pp. 21–22
• A guardrail can report suspected prompt injection on another agent, and that agent’s later self-report cannot clear the governance state.The server accepts the event when the guardrail credential is authorized and records the guardrail as setter.Source: §10 · p. 23
• After 25 seconds without events against a declared 10-second heartbeat interval, the server marks the Web Browser unreachable; the dashboard sees that transition and retains its last task as stale.The server generates the transition without an agent report, and updates travel by POST in and SSE out rather than dashboard polling.Source: §10 · p. 23

11 Governance with Sentinel Agents

• The Sentinel Agent architecture describes sentinels raising alerts and a coordinator isolating agents, but does not define a common format for their alerts and decisions.Without one, integrations are repeated and quarantine decisions remain invisible to other system components until separately communicated.Source: §11 · p. 23

11.1 Roles

• Sentinels report as guardrails and coordinators as operators, using credentials authorized to report on other agents; monitored agents cannot clear their governance states.A coordinator-set state can be cleared only by the coordinator or a human operator.Source: §11.1 · pp. 23–24

11.2 From Alert to Quarantine

• A sentinel can set under-review, after which a coordinator correlates alerts with health and task states and may quarantine, sandbox, or restore the agent to normal.The resulting decision can revoke floor access, stop task routing, and be distributed to observers; ingest credentials may also be revoked.Source: §11.2 · p. 24

11.3 State as Input to Sentinels

• Sentinels may use state-stream patterns—such as repeated peer timeout observations or oscillating task states—to raise alerts or focus scrutiny.Source: §11.3 · p. 24

11.4 Monitoring the Monitors

• Because sentinel liveness is reported, an unreachable or stalled sentinel makes its monitoring gap visible; a coordinator should treat that gap as a governance event.Governance history records transitions with their source and credential, providing an audit trail for the architecture’s compliance needs.Source: §11.4 · p. 24

12 Security Considerations

• The draft requires authenticated ingest and TLS outside local deployments, while credential issuance, scoping, rotation, and revocation remain deployment-specific.Observer endpoints require authorization, event content excludes prompts and user data, and governance reports take precedence over self-reports.Source: §12 · p. 25
• Security guidance also recommends per-agent rate limits, a 16 KB event-size cap, and append-only event history with operator-set retention.Source: §12 · p. 25

13 Extensibility and Versioning

• Vendor-specific fields belong under reverse-domain namespaces in ext, unknown ext content must be preserved, and custom state values use the x- prefix.Observers should display unknown states as-is, grouping them with a standard state when a hint is available.Source: §13 · p. 25
• Minor versions add only optional fields or states, and servers must accept events from any minor version of a supported major version.The draft uses semantic versioning for aspVersion.Source: §13 · p. 25

14 Open Issues

• Other unresolved questions concern peer-observation quorums, capability updates, serverless bindings and signing, credential profiles, and shared governance reason codes.Source: §14 · p. 26
• Open issues include whether to separate vocabulary, event, and behavior documents; how observers locate agents across servers; and whether to formalize floor tracking, JSON Schema, or pull-mode bindings.The pull-mode question notes that a fuller binding could collect state from agents that never push.Source: §14 · pp. 25–26

15 Future Directions

• A reference status server, dashboard, event schemas, and conformance tests could make the specification's behavior testable and support layer-by-layer validation.The proposal identifies optional Section 7.2 mechanisms as part of what could be tested.Source: §15 · p. 26
• Independent implementations could test ASP mappings in Playground scenarios and with A2A-only or neither-protocol agents to assess state mapping and protocol neutrality.The proposed Playground experiment uses two or three agents and scenarios including floor waits, delays, timeouts, and interrupted status reporting.Source: §15 · pp. 26–27
• A simulated Sentinel Agents integration could examine alert-to-quarantine visibility, whether state patterns complement content analysis, and governance reason codes and peer quorum.Source: §15 · p. 27
• For deployments with thousands of agents, the draft suggests specifying additional streaming bindings, multi-server aggregation guidance, and possibly a common credential profile.The credential profile depends on resolving the open authentication issue in that direction.Source: §15 · p. 27

16 Conclusion

• ASP combines server-inferred liveness, progress signals, and external observations with reused A2A, OFP, and OpenTelemetry vocabularies; it is offered as a proposal for community review and testing.The conclusion says ASP defines state rather than the agent, framework, or vendor.Source: §16 · p. 27

Appendix A: Reference Dashboard

• The dashboard combines lifecycle counts, an attention-sorted agent table, an OFP floor view, and a live event stream for human operators and software observers.The twelve-agent example exercises every state dimension, and all displayed data are illustrative.Source: Appendix A · p. 30, Figure 4 · p. 30
• The agent table reports lifecycle, health, task, floor, and heartbeat age, placing an unreachable agent with a stale task before a quarantined agent whose floor was revoked.Source: Appendix A · p. 30
• The OFP panel shows the convener, floor holder, and request queue, while the SSE stream lists recent state_change and floor_change events newest first.State labels accompany colors so the display remains readable in greyscale.Source: Appendix A · p. 30