A transport-agnostic wire protocol for submitting, observing, and controlling long-running AI agent jobs.
Current draft: v1 — Standards Track — expires November 13, 2026
ARCP defines the durable execution envelope around AI agent work: sessions, jobs, resumable event streams, capability-bounded leases, and delegation. It stays agnostic about agent implementation and tool transport — MCP exposes tools, OpenTelemetry handles telemetry export, and ARCP composes with both.
Four concerns, scoped tightly:
- Identity — who is talking, what session, what trace
- Durability — resumable streams, gap-free sequencing, idempotent submission
- Authority — leases over filesystem, network, tools, sub-agents, and cost
- Observability — structured events, progress, metrics, streamed results
- Sessions — authenticated, resumable, with capability negotiation in
session.hello/session.welcome - Liveness — explicit
session.ping/session.pongheartbeats (§6.4) - Flow control —
session.ackfor window-based event acknowledgement (§6.5) - Introspection —
session.list_jobsfor read-only job inventory (§6.6) - Idempotent submission —
idempotency_keyonjob.submitfor safe retries - Subscription —
job.subscribeto attach to a running job from a different session, without inheriting cancel authority (§7.6) - Agent versioning —
name@versionidentifiers with inventory advertised insession.welcome(§7.5) - Leases — capability-bounded authority over
fs.*,net.fetch,tool.call,agent.delegate - Time-bounded authority —
lease_constraints.expires_at(§9.5) - Budget enforcement —
cost.budgetcapability with runtime-maintained counters and per-currency tracking (§9.6) - Delegation — sub-agent jobs with strict lease subsetting (§10)
- Progress reporting — structured
progressevents (§8.2) - Result streaming —
result_chunkevents for large outputs (§8.4) - Trace propagation — W3C Trace Context across sessions, jobs, and delegations (§11)
- Fifteen-code error taxonomy — including
BUDGET_EXHAUSTED,LEASE_EXPIRED,AGENT_VERSION_NOT_AVAILABLE(§12)
Out of scope, deliberately:
- Agent implementation
- Tool exposure (use MCP)
- HITL UX
- Agent state persistence across process restarts
- Telemetry export (use OpenTelemetry)
- Auth mechanisms beyond bearer tokens
- Scheduling, priority, federation, pause/resume, LLM token streaming — deferred
Eleven first-party SDKs track the same spec version. Pick the one closest to your stack.
| Language | Repo |
|---|---|
| TypeScript | typescript-sdk |
| Python | python-sdk |
| Go | go-sdk |
| Rust | rust-sdk |
| Java | java-sdk |
| Kotlin | kotlin-sdk |
| Swift | swift-sdk |
| Ruby | ruby-sdk |
| PHP | php-sdk |
| C# | csharp-sdk |
| F# | fsharp-sdk |
The full draft lives in SPEC.md.
| Section | Contents |
|---|---|
| §1–2 | Introduction, conventions, terminology |
| §3–5 | Protocol overview, transport, wire format |
| §6 | Sessions: hello/welcome, resume, heartbeats, ack, listing |
| §7 | Jobs: lifecycle, cancellation, versioning, subscription |
| §8 | Events: kinds, ordering, result streaming |
| §9 | Leases: grammar, enforcement, subsetting, expiration, budget |
| §10–11 | Delegation, trace propagation |
| §12 | Error taxonomy |
| §13 | Worked examples (heartbeat, ack/back-pressure, subscribe, expiration, budget, chunked result, versioning) |
| §14 | Security considerations |
Draft specification distributed for review. Implementations are encouraged but should expect breaking changes before v1 is finalized. The wire format is the contract — anything not specified here is implementation-defined.
Capability negotiation is the forward-compatibility story: both peers advertise a features list in session.hello / session.welcome, and the effective feature set is their intersection. New features land behind new flags so older clients keep working.
Issues and pull requests welcome. For protocol-level changes, open an issue first to discuss intent before sending a PR — once a feature flag ships in a registered implementation it is effectively frozen.
When proposing changes, please indicate:
- Which section(s) are affected
- Whether the change is backward-compatible with the feature-negotiation rules in §6.2
- Whether it introduces a new feature flag, error code, event kind, or capability namespace (these require IANA-registry coordination per §15)
[TBD]