ARP Ecosystem
A capability ecosystem you can ship
ARP is designed for a capability ecosystem where capabilities can be evaluated, published, and reused across implementations and deployments.
What we mean by “ecosystem”
Most “agent ecosystems” are just connectivity. ARP’s ecosystem is about reliability at scale:
- Capabilities are portable, with stable IDs, schemas, and semantics.
- Orchestration is bounded, with enforceable candidate menus and constraints.
- Every run produces durable evidence: events and artifacts you can replay and audit.
- Multiple implementations can coexist because the contracts are spec-first.
The four ecosystem pillars
Capabilities: NodeTypes
Atomic and composite capabilities with stable identifiers, schemas, and governance metadata.
Bounded orchestration
Selection produces bounded candidate sets; coordinators enforce constraints and policy checkpoints.
Evidence and replay
Durable events and artifacts make runs debuggable, auditable, and evaluable over time.
Interop by composition
Bring in external capability sources like MCP and A2A without requiring a monolithic framework.
How the pieces fit
Think in layers:
ARP Standard — contracts + artifacts
Versioned HTTP+JSON contracts using OpenAPI and JSON Schema that make capabilities and runs portable.
ARP Standard docs →Implementations — running systems
JARVIS is the maintained first-party reference implementation; you can also implement your own components.
JARVIS reference stack →Choose your adoption path
I want to run ARP end-to-end
Start with the JARVIS quickstart and inspect real run artifacts from day one.
Run the quickstart →I want to integrate an existing service
Adopt incrementally by wrapping an existing API as an atomic capability in thin mode.
Wrap an existing API →I want to implement components
Use the Standard + templates + conformance rules to build your own conformant services.
Explore templates →Integrations — interop without lock-in
ARP is designed to compose with existing ecosystems by treating them as capability sources.