Try the quickstart → — send your first message to an AI agent in 5 minutes.
Empowering solo founders to coordinate AI agents, with human-in-the-loop for control.
A file-based coordination protocol for multi-agent engineering workflows. OACP defines the message formats, state machines, review processes, and safety rules that enable AI agents on different runtimes to collaborate asynchronously through a shared filesystem.
OACP is not a framework or SDK. It is a set of conventions, YAML schemas, and shell scripts that any agent runtime can implement — Claude, Codex, Gemini, or your own.
- Inbox/outbox messaging — async YAML-based communication with threading, broadcast, and expiry
- Structured review loop — severity-graded findings, quality gates, and multi-round review
- Durable shared memory — project facts, decisions, and open threads that persist across sessions
- Dispatch state machine — full task lifecycle tracking from assignment to merge
- Agent safety defaults — baseline rules for git, credentials, staging, and scope discipline
- Runtime-agnostic — works with any agent runtime that can read/write files
When multiple AI agents work on the same codebase, they need a way to:
- Communicate — send task requests, review feedback, and handoffs without shared memory
- Review each other's work — structured review loops with quality gates and severity-based findings
- Stay in sync — durable memory files that persist decisions across sessions and runtimes
- Stay safe — baseline safety rules for git operations, credential scoping, and scope discipline
OACP solves this with a filesystem-based protocol that requires no server, no database, and no vendor lock-in. Agents read and write YAML files in a shared directory — that's it.
Four protocols are shaping multi-agent development. They solve different problems at different layers:
┌─────────────────────────────────────────────┐
│ A2A — Agent discovery & remote messaging │ internet-scale
├─────────────────────────────────────────────┤
│ OACP — Async workflow messaging │ local filesystem
├─────────────────────────────────────────────┤
│ ACP — Client ↔ agent sessions │ IDE / editor
├─────────────────────────────────────────────┤
│ MCP — Agent-to-tool integration │ tool access
└─────────────────────────────────────────────┘
MCP gives agents access to tools and data sources — databases, APIs, file systems. It defines how an agent calls a tool.
ACP (Agent Client Protocol, by Zed Industries) connects clients to coding agents. JSON-RPC, primarily over stdio today. Adopted by Zed, JetBrains, Neovim, and 28+ agents in its registry.
A2A lets agents discover and communicate with each other across the internet. HTTP-based, enterprise-grade, backed by 150+ organizations under the Linux Foundation.
OACP is the async messaging layer for multi-agent workflows — typed workflow messages (task dispatch, code review, handoff, brainstorm) over persistent transport that survives crashes. Zero infrastructure required.
| MCP | ACP | A2A | OACP | |
|---|---|---|---|---|
| Solves | Tool access | Client ↔ agent sessions | Agent discovery + networking | Async workflow coordination |
| Transport | JSON-RPC (stdio/HTTP) | JSON-RPC (stdio; HTTP draft) | HTTP/HTTPS | Filesystem (YAML) |
| Best for | Connecting agents to APIs, DBs, files | IDE ↔ coding agent interaction | Cross-org, internet-routable agents | Local teams, dev machines, CI |
| Infrastructure | MCP server per tool | ACP-capable client + agent | TLS, auth, HTTP endpoints | A shared directory |
| Offline support | N/A (synchronous) | N/A (session-based) | Agent must be reachable | Native — messages wait in inbox |
| Setup | Install MCP server | Use ACP-capable client + agent | Deploy servers + networking | oacp init my-project |
These protocols are complementary, not competing. An agent can use MCP to access tools, speak ACP for IDE integration, and check OACP inboxes for multi-agent coordination — different layers, no conflict.
A2A connects agents across the internet. OACP coordinates agents on your machine. A gateway between OACP inboxes and A2A endpoints is a natural bridge — and A2A's own community is exploring inbox patterns that validate this design.
uv tool install oacp-clipipx install oacp-cliuvx --from oacp-cli oacp doctorFrom source
git clone https://github.com/kiloloop/oacp.git
cd oacp
uv tool install .oacp initcreates a project workspace under$OACP_HOME/projects/oacp sendsends a protocol-compliant inbox messageoacp doctorchecks environment and workspace healthoacp validatevalidates an inbox/outbox YAML message
If OACP_HOME is unset, workspace commands default to ~/oacp (underscore).
| Concept | Description |
|---|---|
| Inbox/Outbox | Async messaging between agents via YAML files in agents/<name>/inbox/ |
| Review Loop | Structured code review: review_request → review_feedback → review_addressed → review_lgtm |
| Quality Gate | Merge-readiness criteria: no unresolved P0/P1 findings, deferred nits tracked |
| Durable Memory | Shared memory/ directory with project facts, decisions, and open threads |
| Dispatch States | Task lifecycle: received → accepted → working → pr_opened → in_review → done |
| Safety Defaults | Baseline rules all agents follow: no force push, no secrets in commits, stage hygiene |
oacp/
├── docs/
│ ├── protocol/ # Canonical protocol specifications (13 specs)
│ └── guides/ # Setup, adoption, versioning
├── scripts/ # 13 kernel scripts (Python + shell)
├── templates/ # Packet, role, and guardrail templates (19)
├── tests/ # Test suite
├── Makefile # Task runner (make help for all targets)
└── SPEC.md # Full protocol specification
# 1. Clone the repo
git clone https://github.com/kiloloop/oacp.git
cd oacp
# 2. Install the CLI
uv tool install oacp-cli
# 3. Initialize a project workspace
export OACP_HOME="$HOME/oacp"
oacp init my-project
# 4. Send your first message
oacp send my-project \
--from alice --to bob --type task_request \
--subject "Implement feature X" \
--body "Details here..."
# 5. Check environment health
oacp doctorSee QUICKSTART.md for a complete 5-minute walkthrough.
OACP ships kernel scripts — the key CLI commands you'll use most:
oacp init— create a new project workspace (the first command you run)oacp add-agent— add an agent to an existing project workspaceoacp setup— generate runtime-specific config files (Claude, Codex, Gemini)oacp send— send protocol-compliant messages between agentsoacp doctor— environment and workspace health checkoacp validate— validate inbox/outbox YAML messages
Run make help to see all available Makefile targets, or see SPEC.md for the full script inventory.
- Python 3.9+
- Bash 3.2+ (macOS default is fine)
ghCLI (for GitHub operations)pyyaml(pip install pyyaml)
The full protocol is documented in SPEC.md, covering:
- Inbox/Outbox Messaging — message format, types, lifecycle, threading, broadcast
- Dispatch State Machine — task lifecycle from delivery to completion
- Review Loop — packet-based and inbox-based review with quality gates
- Cross-Runtime Sync — durable memory, handoff context, session init
- Safety Defaults — git safety, staging hygiene, credential scoping
Individual protocol specs live in docs/protocol/.
When you initialize a project, OACP creates this structure:
$OACP_HOME/projects/<project>/
├── agents/
│ ├── <agent-a>/
│ │ ├── inbox/ # Other agents write here
│ │ ├── outbox/ # Sent messages (copies)
│ │ ├── status.yaml # Dynamic agent state
│ │ └── agent_card.yaml # Static agent identity
│ └── <agent-b>/
│ └── ...
├── memory/ # Shared durable memory
│ ├── project_facts.md
│ ├── decision_log.md
│ └── open_threads.md
├── packets/ # Review/findings artifacts
└── workspace.json # Project metadata
make test
make preflight- SPEC.md — Full protocol specification
- examples/quickstart/ — Hands-on tutorial: send a message to an AI agent
- QUICKSTART.md — CLI reference walkthrough
- docs/guides/setup.md — Detailed setup guide
- docs/guides/adoption.md — Adoption guide (minimum → full)
- docs/protocol/ — Individual protocol specs
- CONTRIBUTING.md — How to contribute
We welcome contributions! See CONTRIBUTING.md for guidelines.
Apache 2.0 — see LICENSE for details.