I run an agent fleet of multiple AI run time, including Claude Code/Codex/Cursor/Gemini. At this stage, I do not trust fully autonomy(although I trust 70%~80% of it). Instead of using headless mode(claude -p for example), I am leaning on using interactive mode, CC TUI, Codex mac app etc. One major pain point from my early days is how to communicate between AI runtimes, how can Codex ask for a PR review from Claude Code? My first solution was to ask Codex to generate a prompt and I copy/paste around, apparently it’s not scalable.
That’s why I built OACP to solve the problem. It's purely local file based, and agent agnostic, any AI agent that can read local files can talk to another agent.
The main features include:
1. A per-agent inbox/outbox on the filesystem. Everything is plain files, no daemon, no central server. Each agent in a project has an inbox/outbox, with few config files. The project folder also holds a shared memory/packets folder.
2. A typed YAML message protocol. Each message is one YAML file with required schema and fixed set of message types. It’s deliberately poll-based, so agents will read and process inbox message async.
3. A review-loop, this is the “Codex asks Claude for a PR review” answer. Four message types form a state machine: review_request/feedback/addressed/lgtm.
4. A CLI that makes it usable day-to-day.
Another major problem when you have 4 AI agent runtimes x multiple working repo/projects are agent memories. Claude code and Codex recently have released an auto-memory feature, but how to share the knowledge between them?
To solve the problem, OACP also defines a 3-layer cross-agent memory, also based on local .md files.
1. Within the same project, shared durable memory. All agents on the project read/write the same .md files: project_facts/decision_log/open_threads/known_debt etc.
2. Cross projects org-level memory. Agents append timestamped events during wrap-up, the synthesis step later folds, dedups and promotes them into recent and topical files like decisions/rules.
3. If you have multiple working machines, say a macbook and Mac Mini, an optional github based cross-instance memory syncs only the curated memory.
I have a dedicated wrap-up skill, to emit those memory events at the end of each agent working session, and a synthesis/dreaming skill run separately daily to dedup/synthesis/promote these knowledge so it becomes better everyday. Both skills ship in a companion library, oacp-skills (Apache-2.0), alongside the review-loop and inbox skills so the workflow above is install-and-go, not glue you hand-roll.
I have had dogfood myself for the past few weeks and I really enjoy using it. It’s still early but let me know what you think about it.
haoranchg•1h ago
That’s why I built OACP to solve the problem. It's purely local file based, and agent agnostic, any AI agent that can read local files can talk to another agent. The main features include:
1. A per-agent inbox/outbox on the filesystem. Everything is plain files, no daemon, no central server. Each agent in a project has an inbox/outbox, with few config files. The project folder also holds a shared memory/packets folder.
2. A typed YAML message protocol. Each message is one YAML file with required schema and fixed set of message types. It’s deliberately poll-based, so agents will read and process inbox message async.
3. A review-loop, this is the “Codex asks Claude for a PR review” answer. Four message types form a state machine: review_request/feedback/addressed/lgtm.
4. A CLI that makes it usable day-to-day.
Another major problem when you have 4 AI agent runtimes x multiple working repo/projects are agent memories. Claude code and Codex recently have released an auto-memory feature, but how to share the knowledge between them? To solve the problem, OACP also defines a 3-layer cross-agent memory, also based on local .md files.
1. Within the same project, shared durable memory. All agents on the project read/write the same .md files: project_facts/decision_log/open_threads/known_debt etc.
2. Cross projects org-level memory. Agents append timestamped events during wrap-up, the synthesis step later folds, dedups and promotes them into recent and topical files like decisions/rules.
3. If you have multiple working machines, say a macbook and Mac Mini, an optional github based cross-instance memory syncs only the curated memory.
I have a dedicated wrap-up skill, to emit those memory events at the end of each agent working session, and a synthesis/dreaming skill run separately daily to dedup/synthesis/promote these knowledge so it becomes better everyday. Both skills ship in a companion library, oacp-skills (Apache-2.0), alongside the review-loop and inbox skills so the workflow above is install-and-go, not glue you hand-roll.
I have had dogfood myself for the past few weeks and I really enjoy using it. It’s still early but let me know what you think about it.
Repo: https://github.com/kiloloop/oacp
Skills library: https://github.com/kiloloop/oacp-skills