FRESH

Hacker News

Home

Show HN: Cross-agent messaging and shared memory over the local filesystem

9 points by haoranchg

by haoranchg

0 subcomment

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.

by boundless88

1 subcomments

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.

by haoranchg

0 subcomment

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.
Repo: https://github.com/kiloloop/oacp
Skills library: https://github.com/kiloloop/oacp-skills

by Oracles_Tech

0 subcomment

[dead]