Status codes for agents¶

A shared, machine-readable vocabulary for agents and applications to report progress, outcomes, human input, and recovery.

Explore the code space Read ASC 0.1

Example status ASC 0.1 · experimental

Phase WAITING

Primary 3002

Conditions 0..n

Events 0..n

Retry EXPLICIT

ASC 3002 HUMAN_APPROVAL_REQUIRED

Browse the code classes¶

The first digit is the safe fallback when a consumer does not recognise a specific code.

Why ASC exists¶

HTTP status codes let a client act on a response without knowing how the server is built. Agent integrations lack that shared vocabulary, so every agent and application pair invents terms for running, waiting, partial success, human input, and recovery. ASC defines those meanings once so applications can act on them consistently.

Why ASC exists

A retryable failure is not the same thing as a safe retry.
ASC retry contract

The five parts of a status report¶

Each part answers a different control-flow question and remains independently useful.

Phase
Where is this scope in its lifecycle?
Primary status
What is the best current summary?
Conditions
What other durable facts remain true?
Events
What happened without replacing the outcome?
Retry contract
May another attempt happen safely?

Learn the model

Use ASC with existing protocols¶

ASC does not replace HTTP, gRPC, A2A, MCP, OpenTelemetry, or framework-native types. It gives each of them a stable agent-status payload.

Start implementing Protocol bindings

A resumable human gate

{
  "spec_version": "0.1.0",
  "status": {
    "code": 3002,
    "name": "HUMAN_APPROVAL_REQUIRED",
    "scope": "task",
    "phase": "WAITING",
    "terminal": false
  },
  "occurred_at": "2026-08-08T12:00:00Z"
}

ASC 0.1 is experimental

The draft is experimental. Implement it, identify ambiguous boundaries, and propose changes with concrete cases.

Open an RFC Contribute