If COP is the mindset, ARP Standard is the contract.
ARP Standard v1 exists for one reason:
So teams can build bounded, auditable agentic systems with replaceable parts — without rewriting everything when the ecosystem shifts.
What the Standard is
ARP Standard v1 is a set of versioned API contracts and schemas for executing capabilities as runs:
- capability definitions, versioned and portable,
- execution records for runs and steps,
- bounded candidate menus,
- enforceable constraint envelopes,
- policy decision artifacts.
It’s the interoperability layer for “agentic execution” — at the level that matters for reliability and operations.
What the Standard is not
To keep the ecosystem healthy, ARP Standard intentionally does not standardize:
- planner algorithms
- prompting strategies
- memory architectures
- your preferred framework internals
- deployment topology
The Standard defines the seams — not the guts.
Why standardize artifacts, not planners?
Because in production, reliability comes from:
- enforceable bounds that define what is allowed,
- durable evidence of what happened,
- and replaceable implementations so you can swap parts without rewriting.
Planner internals will evolve fast. Artifacts and enforcement points must remain stable.
The core nouns
ARP Standard centers on a small set of portable objects:
- NodeType: a versioned capability definition with schemas, metadata, and envelope defaults.
- Run: the top-level execution record.
- NodeRun: an execution instance of a NodeType within a Run.
- CandidateSet: a bounded menu of capabilities for a specific mapping decision.
- ConstraintEnvelope: enforceable limits covering structure, candidates, budgets, and gates.
- PolicyDecision: structured allow/deny/require-approval results tied to checkpoints.
If you get these nouns right, you get portability, auditability, and predictable enforcement.
A concrete example: an enforceable ConstraintEnvelope
{
"structural": { "max_depth": 3, "max_total_nodes_per_run": 25 },
"candidates": {
"allowed_node_type_ids": [
"billing.initiate_refund",
"billing.create_case_for_agent",
"support.escalate_to_human"
]
},
"budgets": { "max_wall_time_ms": 45000, "max_steps": 35, "max_external_calls": 10 },
"gates": { "side_effect_class": "write", "require_approval": true }
}The Standard’s component contracts at a high level
ARP Standard defines network-shaped boundaries so implementations are swappable.
Typical roles include:
- a Run Gateway for client entrypoints,
- a Run Coordinator as the run authority for enforcement and durable history,
- Executors for atomic and composite capability execution,
- a Registry for versioned capability definitions,
- Selection for bounded candidate menus,
- a PDP for policy decisions.
You can co-locate components in dev. The contract stays the same.
Conformance: what it means
“Conformance” is simple:
- your component implements the required endpoints,
- your payloads validate against the published schemas,
- and required semantics are preserved, including errors, cancellation, envelopes, and required artifacts.
Conformance is what makes the ecosystem real.
If you build your own component, conformance is how other teams can safely integrate it without bespoke glue.
What you can do with the Standard
Adopt incrementally
You don’t need to implement everything.
Many teams start by:
- wrapping a small set of atomic capabilities,
- adopting bounded candidate menus,
- recording durable run artifacts,
- then introducing stronger policy checkpoints over time.
Implement components without lock-in
Because the contracts are standard, you can:
- swap selection strategies,
- swap registries,
- swap executor implementations,
- compare against the reference stack.
Where to read the Standard
- Marketing overview: /standard
- Docs portal: /spec
- SDKs: docs.agent-runtime-protocol.com/arp-standard/sdk
Next in the series: JARVIS: why a standard needs a reference implementation