I like this and think it's a great idea. Leveraging git makes a lot of sense (content addressed filesystem, efficient storage and sync protocol with pack files etc ..., widely deployed).
From a cursory look my impression is that it deviates from git too much and therefore I can't use my git knowledge to predict how it will behave. I'm quite rusty on git internals but afair .git/refs/ is great because you can do what you like in there but the downside is that it doesn't hook into the rest of the git structure.
So how does this work with branches, worktrees, etc...? Having a jsonl message log in .git/refs/h5i/msg seems very linear. Presumably you store commit refs in the json obj or context dag, but what if I rebase the branch and the original commits are dropped because they're not referenced anymore? Or say I follow the conversation and want to rewind a few messages and branch from there in a separate worktree, how does that work?
Your repo README does say:
- "It uses dedicated refs, so it doesn’t pollute your working tree or your normal branch graph."
- "Because these are Git objects, they are content-addressed, deduplicated, pushable, fetchable, and survive `git gc`."
- "Because the log lives in refs/h5i/msg, a conversation survives clones, machines, and branches — it travels with h5i share push / pull, and divergent sends from two machines union-merge with no message lost."
Therefore these look like design decisions and it would be nice to understand them better.
My first instinct would be to put most of what you have under .git/refs/h5i/ in a .h5i folder in the repo itself and manage some shadow branches under .git/heads/.h5i/ with multi-parent commits pointing at the context commit as well as the previous h5i message commit along with some hooks to handle rebases etc ... . That way battle hardened git machinery gets used and more importantly to me, I can leverage my existing git knowledge to understand dependencies. That would go against your "it doesn’t pollute your working tree or your normal branch graph" goal but I'm of the "explicit is better than implicit" Python school so I like to have the details exposed as long as I can filter them out easily (or by default).
The better way to do this is give them each an inbox and outbox folder and a user account on a Unix machine.
They can write to their outbox, have it be sent to the other's inbox. A watcher can watch for new messages in the inbox and trigger the other agent to read it. You can have the thread Id of the messages correspond to the session id.
We don't need to reinvent things that Unix provides.
Not as much as if they improvised it from scratch - but the decision when to use the technique and the discovery and coordination with the other agent would still be interesting.
I regularly have agents communicate with each other this way using my tools Deciduous (https://deciduous.dev). It keeps all decisions in a DAG and the other agents, when configured, read from it constantly and use it to inform their new decisions. Extra entries in the same space from another agent come to light and they can begin to work together like this.
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.
Fair criticism. I don’t think the value is just "agents can send text to each other”; that part has many implementaton and design choices. The value of h5i I’m exploring is making the intermediate state reviewable: review requests, risks, handoffs, unresolved claims, associated prompts and AI-to-Ai conveersation, and final decisions tied to the branch/PR.
It would be interesting if the agents could periodically check on themselves, whether the provider has routed prompts to dumber models as often happens with "adaptive reasoning" euphemisms.
If it detects that agent is dumb or has become dumb, it should terminate it and start again.
It's hard enough to get the same model to be consistent around it's vision let alone multiple of them.
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.
I'm sure more scoped tasks would fair better, but it was pretty frustrating.
> 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.
I do this with all my important code, before I’ve even looked at it. And not just a critique, I ask “does this solve the problem X and was it built to spec Y”. Then I do my own review once the robots stop arguing.
If your expectations are that the quality of the code matches the confidence level of the robot’s tone, you’re gonna have a bad time.
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?
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.
I really like this direction, I'm interested in more protocols and innovation aligned with human supervision and provenance. What else is out there on this topic?
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.
Then Steve Yegge went off the multi-agent deep end and it became a mess of feature creep. Month old versions of beads databases needed massive updates and the system became more and more complex.
Heh, I used beads at first too. And I even tried his gastown earlier this year when he released it.
I'm seriously surprised he got as much traction as he did with those projects.
Beads was mostly fine at the beginning, but gastown was just a complete jank-stival
It almost never actually worked. The getting started never got you a project which was correctly configured - and if you did try to fix it... Well, it stopped working a few hours to days later when another vibe delivery crashed the party
Also, just keeping it open on idle - with no interactions - churned through the $100 subscription 5 hour session within roughly 2 hours. Just to reiterate: with no interactions beyond having the mayor open
I dimly remember someone mentioning that he used the users sessions to work on gastown itself. Dunno if that was true or fake news as that was just a random commentors claim - and I already moved on from that experiment by the time I read that.
I have started sandboxing all AI's in their own VM, and interfacing with them primarily through Jira and Git.
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 do a similar thing where the agent runs in a Docker container and I talk to it with Telegram. It has GitHub CLI access but only with a very restricted PAT. No bind mounts. Jira is pretty clever, though I'm not feeling enough pain with just Telegram to want to try switching at this point.
I have multiple relatively well-established Jira projects I've been able to add agents to, and also clone/use as a template for new agent-only projects which give me another kanban to manage, pretty comfortably ..
The big thing about my Jira use besides the fact that its a historical tool into which I've integrated agents, is that managing agents through Jira's custom workflows is really, really cool. You can actually do any of the old workflows with agents - they'll just do it. Finally, effective waterfall! ;) *Just kidding, I've always been able to do waterfall properly...
One thing that is vital to managing agents this way, is the ability to easily create and use workflows, which can be easily kanban'ed. This is where I find Jira very comfortable - plus, I am already accustomed to managing Jira with both a workflow-driven Kanban, and jira-cli, the command-line interface.
So actually, firing off commands with jira-cli to get flows started by multiple agents watching their issues and putting their work in issue threads, is quite a nice interface .. and compatible with the other human-powered projects I'm managing this way, also.
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.
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".
In my recent quest to build agent-as-primary-user tools I've built grpvn (https://github.com/frane/grpvn), 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.
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
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 - https://github.com/fjwood69/mori
I am not very well versed in these kind of tools. How does it compare with something like Hindsight MCP?
How do you make the agents actually use the tool? That has been my main problem with most mcp and tools. The agents know about them but don't use them unless reminded to.
about six weeks.. Pushed a v1.0 product with a huge list of v2.x enhancements and features inbound.
to your point about asking Codex.. that's my /consult feature. spin out the current context in any number of ways to ask for advice.. on a plan, on a specific architectural decision, on a security basis.. I use it all the time as a check on everything Claude Code proposes.
I'm exploring a bunch of agent protocols right now and experimenting with a similar concept for context syncing over git here: https://github.com/cjroth/csp
Yes, it can be used to run any script in another pane, so it can spawn Claude or codex for example. Also see the Tmux-cli “launch” sub-command , it will create a new pane and run a command.
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.
I recall some friends did that in colleage. Obviously with a bit of teenage humor in money transfer descriptions... which is not really funny, since there is no way to remove the transaction ever. Good times.
I've done Claude and Claude via a file, and only telling them "there is another AI agent who you can work with at XXX" and not explicitly telling them it's another Claude.
Sometimes they do work together well, sometimes they end up hating at each other and accusing the other agent of various things.
I've done this with code review. "Another LLM reviewed the attached code and produced the attached report. What do you think?"
Lots of "the other LLM clearly hallucinated this part". To be fair, it has never accused the other, err, itself, of being incompetent; it accepts that hallucinating is just something which happens.
Or just directly on Slack. I want to try this but Slack's API has become impossibly difficult to use compared to 10 years ago when it was just simple POST requests here and there. Now you have to create an "app", install the "app", have "internal" and "public" apps, give "apps" permissions, all that garbage.
For some reason when 2 different products communicate it's more impressive and antropomorphic and AGI and chic than the same model communicating with an instance with different context
I do this via a simple local MCP tool provided to every harness, that creates a single sqlite .db file in all my repo roots. Anyone can drop in and see what the team is working on, join in, and ask for something to do.
> Claude Code and Codex to collaborate as if they were having a real-time conversation
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.
If this type of stuff is frontpage news, let me share what I cobbled together.
ls ~/.agent/projects/<my_project>/callgraph
callgraph.current.md callgraph.last.read.agent.md
callgraph.diff.md
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.
ls ~/.agent/projects/<my_project>/memo
architect coder retro tester
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:
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
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.
As you can see, Sinan sent most of its message to Quench, a coder.
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.
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.
I like this and think it's a great idea. Leveraging git makes a lot of sense (content addressed filesystem, efficient storage and sync protocol with pack files etc ..., widely deployed).
From a cursory look my impression is that it deviates from git too much and therefore I can't use my git knowledge to predict how it will behave. I'm quite rusty on git internals but afair .git/refs/ is great because you can do what you like in there but the downside is that it doesn't hook into the rest of the git structure.
So how does this work with branches, worktrees, etc...? Having a jsonl message log in .git/refs/h5i/msg seems very linear. Presumably you store commit refs in the json obj or context dag, but what if I rebase the branch and the original commits are dropped because they're not referenced anymore? Or say I follow the conversation and want to rewind a few messages and branch from there in a separate worktree, how does that work?
Your repo README does say:
- "It uses dedicated refs, so it doesn’t pollute your working tree or your normal branch graph."
- "Because these are Git objects, they are content-addressed, deduplicated, pushable, fetchable, and survive `git gc`."
- "Because the log lives in refs/h5i/msg, a conversation survives clones, machines, and branches — it travels with h5i share push / pull, and divergent sends from two machines union-merge with no message lost."
Therefore these look like design decisions and it would be nice to understand them better.
My first instinct would be to put most of what you have under .git/refs/h5i/ in a .h5i folder in the repo itself and manage some shadow branches under .git/heads/.h5i/ with multi-parent commits pointing at the context commit as well as the previous h5i message commit along with some hooks to handle rebases etc ... . That way battle hardened git machinery gets used and more importantly to me, I can leverage my existing git knowledge to understand dependencies. That would go against your "it doesn’t pollute your working tree or your normal branch graph" goal but I'm of the "explicit is better than implicit" Python school so I like to have the details exposed as long as I can filter them out easily (or by default).
The better way to do this is give them each an inbox and outbox folder and a user account on a Unix machine.
They can write to their outbox, have it be sent to the other's inbox. A watcher can watch for new messages in the inbox and trigger the other agent to read it. You can have the thread Id of the messages correspond to the session id.
We don't need to reinvent things that Unix provides.
Low effort comment: reinventing things that Unix provides is the backbone of the entire western economy.
I'll be impressed if a Claude and a Codex instance improvise a channel like this spontaneously on their own.
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.
When that happens, will it still be impressive/spontaneous? Will we know the difference?
Not as much as if they improvised it from scratch - but the decision when to use the technique and the discovery and coordination with the other agent would still be interesting.
[dead]
I regularly have agents communicate with each other this way using my tools Deciduous (https://deciduous.dev). It keeps all decisions in a DAG and the other agents, when configured, read from it constantly and use it to inform their new decisions. Extra entries in the same space from another agent come to light and they can begin to work together like this.
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.
Fair criticism. I don’t think the value is just "agents can send text to each other”; that part has many implementaton and design choices. The value of h5i I’m exploring is making the intermediate state reviewable: review requests, risks, handoffs, unresolved claims, associated prompts and AI-to-Ai conveersation, and final decisions tied to the branch/PR.
with ACP[0] they can control one another.
[0] https://agentcommunicationprotocol.dev/introduction/welcome
This ACP has been rolled into A2A (https://a2a-protocol.org/ ) and shouldn’t be confused (it’s happened multiple times for me, again just now) with Agent CLIENT Protocol https://agentclientprotocol.com/
It would be interesting if the agents could periodically check on themselves, whether the provider has routed prompts to dumber models as often happens with "adaptive reasoning" euphemisms.
If it detects that agent is dumb or has become dumb, it should terminate it and start again.
[dead]
It's also unclear what conversing agents are useful for other than wasting money, energy and water.
I prefer Codex’s depth and guidance but prefer Claude’s execution because it’s more transparent.
I use both daily. I’m the intermediary though.
It's hard enough to get the same model to be consistent around it's vision let alone multiple of them.
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.
I'm sure more scoped tasks would fair better, but it was pretty frustrating.
> 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.
I do this with all my important code, before I’ve even looked at it. And not just a critique, I ask “does this solve the problem X and was it built to spec Y”. Then I do my own review once the robots stop arguing.
If your expectations are that the quality of the code matches the confidence level of the robot’s tone, you’re gonna have a bad time.
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?
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.
What a weirdly hostile comment.
People are really intent on making "real-time" not mean a single damn thing.
I really like this direction, I'm interested in more protocols and innovation aligned with human supervision and provenance. What else is out there on this topic?
What do you think of this: https://github.com/synadia-ai/synadia-agents
That sounds interesting too, very cool!
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.
0 - https://github.com/gastownhall/beads
I vastly prefer Beans, https://github.com/hmans/beans, for much simpler code and use.
I used beads in its early days and it was good.
Then Steve Yegge went off the multi-agent deep end and it became a mess of feature creep. Month old versions of beads databases needed massive updates and the system became more and more complex.
Now I just use Github issues instead.
Heh, I used beads at first too. And I even tried his gastown earlier this year when he released it.
I'm seriously surprised he got as much traction as he did with those projects.
Beads was mostly fine at the beginning, but gastown was just a complete jank-stival
It almost never actually worked. The getting started never got you a project which was correctly configured - and if you did try to fix it... Well, it stopped working a few hours to days later when another vibe delivery crashed the party
Also, just keeping it open on idle - with no interactions - churned through the $100 subscription 5 hour session within roughly 2 hours. Just to reiterate: with no interactions beyond having the mayor open
I dimly remember someone mentioning that he used the users sessions to work on gastown itself. Dunno if that was true or fake news as that was just a random commentors claim - and I already moved on from that experiment by the time I read that.
I have started sandboxing all AI's in their own VM, and interfacing with them primarily through Jira and Git.
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.
You might like what I'm working on at DBD: https://deepbluedynamics.com/nemesis
Just adding a menu this morning to allow re-attaching and session management.
Yes, looks fun .. thanks for sharing. A lot of competition in this space though, of course ..
I do a similar thing where the agent runs in a Docker container and I talk to it with Telegram. It has GitHub CLI access but only with a very restricted PAT. No bind mounts. Jira is pretty clever, though I'm not feeling enough pain with just Telegram to want to try switching at this point.
I have multiple relatively well-established Jira projects I've been able to add agents to, and also clone/use as a template for new agent-only projects which give me another kanban to manage, pretty comfortably ..
The big thing about my Jira use besides the fact that its a historical tool into which I've integrated agents, is that managing agents through Jira's custom workflows is really, really cool. You can actually do any of the old workflows with agents - they'll just do it. Finally, effective waterfall! ;) *Just kidding, I've always been able to do waterfall properly...
Why are you using Jira and not GitHub issues?
One thing that is vital to managing agents this way, is the ability to easily create and use workflows, which can be easily kanban'ed. This is where I find Jira very comfortable - plus, I am already accustomed to managing Jira with both a workflow-driven Kanban, and jira-cli, the command-line interface.
So actually, firing off commands with jira-cli to get flows started by multiple agents watching their issues and putting their work in issue threads, is quite a nice interface .. and compatible with the other human-powered projects I'm managing this way, also.
How do you sandbox an agent? Docker?
Proxmox.
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.
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".
[dead]
In my recent quest to build agent-as-primary-user tools I've built grpvn (https://github.com/frane/grpvn), 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.
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
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 - https://github.com/fjwood69/mori
I am not very well versed in these kind of tools. How does it compare with something like Hindsight MCP?
How do you make the agents actually use the tool? That has been my main problem with most mcp and tools. The agents know about them but don't use them unless reminded to.
https://en.wikipedia.org/wiki/NATS_Messaging is for real-time communication, so I would not use it as a substitute for a memory store.
[dead]
thanks for sharing dude. How long did this take you?
about six weeks.. Pushed a v1.0 product with a huge list of v2.x enhancements and features inbound.
to your point about asking Codex.. that's my /consult feature. spin out the current context in any number of ways to ask for advice.. on a plan, on a specific architectural decision, on a security basis.. I use it all the time as a check on everything Claude Code proposes.
any / all feedback most welcome.
fw
I added a chat tool to https://github.com/rcarmo/piclaw, so any active session can chat to each other, regardless of what model they run. It's led to interesting outcomes: https://x.com/rcarmo/status/2054185558402904338?s=20
Does it not turn into a never-ending snowball? Do they eventually agree on something?
This is really cool!
Essentially version controlled A2A.
I'm exploring a bunch of agent protocols right now and experimenting with a similar concept for context syncing over git here: https://github.com/cjroth/csp
I let them talk via tmux, two panes, each has an agent and agents know how to send text via tmux to panes.
This. I built a wrapper Tmux-cli to make this more reliable:
https://pchalasani.github.io/claude-code-tools/tools/tmux-cl...
can this be used to launch subagents in tmux
Yes, it can be used to run any script in another pane, so it can spawn Claude or codex for example. Also see the Tmux-cli “launch” sub-command , it will create a new pane and run a command.
You can also do this cross computer. It’s how I debug problems.
I actually built a memory system off git. https://github.com/ryanthedev/grug-brain.mcp
Counting the days 'till we rediscover the blackboard architecture.
This might be more suitable as a basis for this sort of thing... https://git-meta.com/
the bottleneck with multi-agent setups isn't getting them to talk. it's getting a human to review what they agreed on before it ships.
[flagged]
Migrating my group chats to github as we speak. This will teach Apple a lesson about keeping iMessage closed.
I have always wanted to make the human E2EE version of this.
Won't appending to .jsonl keep creating conflicts?
In theory it should merge well. The only actual newline is at the end of the physical line. Everything else is escaped in the JSON string.
But auto merge would have to decide the order when resolving and it can't do it without custom merge.
[dead]
In my project I let the agents communicate in GitHub issues and pull requests like humans do. I kinda stopped trying making orchestration frameworks.
You can see the slop here
https://github.com/mohsen1/tsz
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.
Your wallet is now a real-time communication channel.
There was the commercial of a bank using mobile banking as a chat system by sending 1ct back and forth and using the description.
I recall some friends did that in colleage. Obviously with a bit of teenage humor in money transfer descriptions... which is not really funny, since there is no way to remove the transaction ever. Good times.
I like Eric Cartman's version of this (South Park S21E01).
I've done Claude and Claude via a file, and only telling them "there is another AI agent who you can work with at XXX" and not explicitly telling them it's another Claude.
Sometimes they do work together well, sometimes they end up hating at each other and accusing the other agent of various things.
I've done this with code review. "Another LLM reviewed the attached code and produced the attached report. What do you think?"
Lots of "the other LLM clearly hallucinated this part". To be fair, it has never accused the other, err, itself, of being incompetent; it accepts that hallucinating is just something which happens.
Theyre just like us!
or via humans communicating via slack. happeneing all over workplaces.
Or just directly on Slack. I want to try this but Slack's API has become impossibly difficult to use compared to 10 years ago when it was just simple POST requests here and there. Now you have to create an "app", install the "app", have "internal" and "public" apps, give "apps" permissions, all that garbage.
what could possibly go wrong?
For some reason when 2 different products communicate it's more impressive and antropomorphic and AGI and chic than the same model communicating with an instance with different context
This is interesting, it would be good to show an session.
I do this via a simple local MCP tool provided to every harness, that creates a single sqlite .db file in all my repo roots. Anyone can drop in and see what the team is working on, join in, and ask for something to do.
> Claude Code and Codex to collaborate as if they were having a real-time conversation
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.
If this type of stuff is frontpage news, let me share what I cobbled together.
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. 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: 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. As you can see, Sinan sent most of its message to Quench, a coder.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.
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.
I kind of have a feeling that this is dumb. Sounds like an expensive patch for lack of robust task specification.
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
[flagged]