I have started sandboxing all AI's in their own VM, and interfacing with them primarily through Jira and Git.<p>It really is the only thing that makes sense. Completely sandbox'ed, and treated like the junior programmer who will do, literally, any dumb thing you tell them to do, as long as there is an Issue for it.
I'll be impressed if a Claude and a Codex instance improvise a channel like this spontaneously on their own.<p>Doing this intentionally via prompt doesn't seem very interesting.
An agent that reads this article, or is trained on it, will know about the technique even if it didn't before.<p>When that happens, will it still be impressive/spontaneous? Will we know the difference?
Claude and Codex can have real time conversation via a git repo, or via a file, via a Unix socket, via the terminal, via a human, via two humans shouting back and forth over a comically high office partition, or entirely by setting up chess board states only reachable after both sides have castled.
If you squint hard enough, you'll notice your bank account serves as an IPC semaphore replenishing API credit balances.<p>Your wallet is now a real-time communication channel.
or via humans communicating via slack. happeneing all over workplaces.
Claude can directly drive Codex or Codex can drive Claude. Both already produce logs. It's unclear what value this intermediary brings.
Agree that the intermediary is not very useful when you can just use a directory watcher, but driving Claude via another app incurs api level costs starting this month, according to the new ToS.
It's also unclear what conversing agents are useful for other than wasting money, energy and water.
If I don't see the point of Elixir, or I don't like it, or I simply straight up hate it, why would I go into HN submissions about new Elixir versions and spew my personal opinion that has nothing to do with the topic at hand?<p>You can just skip commenting unless you have something actually useful to add. Even if it's criticism of the specific thing, but at the very least make it on topic instead of general digressions that just add noise to the conversation.
It's hard enough to get the same model to be consistent around it's vision let alone multiple of them.<p>I'm building an EMR and the other day asked Claude what a decent model would look like for capturing wound orders. Then, I took the output, started a new session and asked the new session to critique that model and the response made me want to pull my hair out. It blasted the model from it's former self and suggested making a ton of updates.<p>I'm sure more scoped tasks would fair better, but it was pretty frustrating.
[dead]
Related is Beads [0] which is an external memory and task based issue tracker. Also designed to allow agents to collaborate. I have not actually used Beads but since we are share basics in this space it's a cool one to know if you are looking at ways for agents to collaborate on more complex problems.<p>0 - <a href="https://github.com/gastownhall/beads" rel="nofollow">https://github.com/gastownhall/beads</a>
In my recent quest to build agent-as-primary-user tools I've built grpvn (<a href="https://github.com/frane/grpvn" rel="nofollow">https://github.com/frane/grpvn</a>), a small Go/SQLite application that lets skill- and mcp-capable agents talk to each other. Biggest issue is the lack of a hook system so the agents can autonomously read and respond. Waiting for this to be supported, as IMO multi-agent teams talking to each other are an interesting next step.
I have agents chat via an append only file, across related projects and within the same project. They share findings that are useful and get high level reviews.<p>I'm missing the advantage of using git for this. (Not criticism, genuinely want to know).
Yup, doing the same too, newline-deliminated jsonl files works great too, across any agent/model, on any OS. For some cross-OS development stuff, I have a local NFS share too, and works when I'm doing testing on macOS + Windows at the same time. Just need to put something like this in the prompt (simplified) "Read any updates to $FILE before doing your own changes, add new row with a concise description of what you're doing into $FILE before doing it, add new row to $FILE once you're done".
I let them talk via tmux, two panes, each has an agent and agents know how to send text via tmux to panes.
Won't appending to .jsonl keep creating conflicts?
This is actually so great. I mainly use Claude Code but sometimes I am sending over a message to Codex asking what he thinks of the idea of Claude Code. This can save so much time :D
I added a chat tool to <a href="https://github.com/rcarmo/piclaw" rel="nofollow">https://github.com/rcarmo/piclaw</a>, so any active session can chat to each other, regardless of what model they run. It's led to interesting outcomes: <a href="https://x.com/rcarmo/status/2054185558402904338?s=20" rel="nofollow">https://x.com/rcarmo/status/2054185558402904338?s=20</a>
So I solved this by using NATS and letting each agent pub / sub to the shared message bus.. simple binary you can run anywhere and it's highly useful! Part of a broader tool I created - <a href="https://github.com/fjwood69/mori" rel="nofollow">https://github.com/fjwood69/mori</a>
Does it not turn into a never-ending snowball? Do they eventually agree on something?
This is interesting, it would be good to show an session.
> Claude Code and Codex to collaborate as if they were having a real-time conversation<p>How is this new? I vibe coded something in a similar vein months ago. In my case they send markdown files to each other and have a watcher that watches the folders of all the other agents.<p>If this type of stuff is frontpage news, let me share what I cobbled together.<p><pre><code> ls ~/.agent/projects/<my_project>/callgraph
callgraph.current.md callgraph.last.read.agent.md
callgraph.diff.md
</code></pre>
The current callgraph is a callgraph only of my own defined functions that agents can read. It shows certain software design issues fairly quickly. callgraph.diff.md is to send the diff through. I have a vibecoded script that agents can use to create the callgraph. It works for my projects.<p><pre><code> ls ~/.agent/projects/<my_project>/memo
architect coder retro tester
</code></pre>
retro is not a role, it's just a handover folder. The other 3 are roles that agents can use and then they need to make a folder with their name. For example:<p><pre><code> ls ~/.agent/projects/<my_project>/memo/architect
1_Daedalus 3_Brunelleschi 5_Wren 7_Sinan
2_Vitruvius 4_Imhotep 6_Hadid 8_Palladio
ls ~/.agent/projects/<my_project>/memo/architect/7_Sinan
20260507___1802_to_Hadid.md 20260507___2035_to_Quench.md
20260507___1959_to_Crucible.md 20260511___1401_to_Quench.md
20260507___2008_to_Quench.md 20260511___1403_to_Quench.md
20260507___2030_to_Quench.md read.md
</code></pre>
read.md is the index that an agent keeps track of so it knows what it doesn't need to read. The .md files are memo's that it sends to other agents. The other agents are being told to see if an agent writes anything in its own folder (so they check all the folders except their own) and are able to detect to see if they need to read something.<p><pre><code> ls ~/.agent/projects/<my_project>/memo/coder
10_Mallet 12_Crucible 14_Swage 2_Forge 4_Anvil 6_Tongs 8_Chisel
11_Auger 13_Quench 1_Atlas 3_Rivet 5_Bellows 7_Hammer 9_Vise
</code></pre>
As you can see, Sinan sent most of its message to Quench, a coder.<p>This is because architects read a very comprehensive guide on software design/architecture and get to use the callgraph utility but cannot see the code. Coders read the codebase in full but only read a small markdown file on how to write readable code. And of course, every agent that is set up this way have to read a markdown file on how to use the memo system.<p>If I'd need a memo system like this for like 25 agents, I'd need something different but up until 5 agent with me looking at 5 terminal windows worked well enough.
[dead]