Rendered at 14:50:32 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
untitled-now 5 hours ago [-]
Protocol itself looks interesting , i would like to see an online version for people who are not tech savvy, so i would suggest that as a great next improvement that will make the adoption faster.
Why ? Because some people are not tech savvy and use AI as vibe coding tools ,so if you give someone to install python in their computer, then install libraries and so on, you lost them .
haoranchg 2 hours ago [-]
Absolutely, I have a Mac app releasing soon.
haoranchg 9 hours ago [-]
Also want to add some color here, I think this works better if you have multiple agent sessions open at the same time, and/or a coordinator agent, that’s when communication/dispatching becomes a real bottleneck.
Taking myself as an example: I have a coordinator agent maintaining a 100+ issue backlog across 5+ projects, and most of the time I have 3+ sessions open working in parallel. Cross-runtime communication is really an essential function for me.
boundless88 11 hours ago [-]
I've had similar thoughts before, and I've seen some frameworks used to assign different tasks to various agents so they can work together to complete a job. But let me be honest, with the improvement in model capabilities and the increasing cost of maintaining these frameworks, there's less and less room left for such tools to survive. The best solution might be to use a single agent and train its preferences over time.
haoranchg 10 hours ago [-]
I do agree with you, and the agent ecosystem is quite different today, compared to when I first started building this with Opus 4.6 and GPT-5.3.
But still I don't want to bet on one runtime as a single point of failure, and different vendors have different strengths (and outages / rate limits). That’s why I am building this in an agent agnostic way.
haoranchg 21 hours ago [-]
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.
Taking myself as an example: I have a coordinator agent maintaining a 100+ issue backlog across 5+ projects, and most of the time I have 3+ sessions open working in parallel. Cross-runtime communication is really an essential function for me.
But still I don't want to bet on one runtime as a single point of failure, and different vendors have different strengths (and outages / rate limits). That’s why I am building this in an agent agnostic way.
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