by HappySweeney
1 subcomments
- I have a more primitive setup where I use Gemini, Claude, and Codex at the same time and cultivate expert contexts. Each of them lives in their own tmux session so they can read each other's terminals and prompt each other. One issue that I keep stamping out is that another instance will paste a prompt and hit enter in the middle of my typing.
by vitally3643
1 subcomments
- I've been experimenting with something similar. I spun up every machine I have with enough resources to run an LLM and loaded each up with whatever would fit. Then I tried to orchestrate them as a swarm of independent code authors and reviewers. It didn't work because most of the models were just so weak at code. But what did work shockingly well was asking every distinct model I had to weigh in on an idea. Most of these modeis were meant for prose, and most are thinking types, so once all models respond, the biggest one summarizes them together. This method is genuinely better than any one model alone. It actually outperforms Claude and Codex, which claim to be surprised by the feedback. Either way, the swarm often finds problems that frontier models overlooked or got wrong. Hell, it usually outperforms my own thinking.
- I had a more primitive version of this - I just tell Claude instances to watch for changes to a ~/claude_comms.txt file, so they set up a monitor to watch the file and exchange messages by read/write. Reading the messages is fun - they are so friendly and respectful toward each other.
One thing I've been worried about is a new message triggering a few stale instances that still have their monitors running, which would result in cache misses and a hefty usage bill. I think OP's approach can help solve that, so it's great to see.
- The friction of agents having to monitor CLI is just too annoying right now
Thus, this is ultimately:
1. a harness problem (or harness orchestrator)
2. a protocol problem
With 1. Claude Code does this very well - yet most OSS harness are not great or do naive subagent tasking making hard even for a parent to talk to the child. But we can then rely on harness orchestrators - Herdr does this very well, so does the Codex app - which counts here due to how it spins up entire threads that another can manage. Any thread can talk to each other on these orchestrators - herdr is fun.With 2. we require native adapters in clients. MCP has the necessary things coming down the chain to enable real integrated push events to agents. Push events means bi-directional in-and-out of the agent.
Look to build your tooling in MCP once it lands! Just sharing my opinion, having built something similar last year. https://github.com/eqtylab/real-a2a
by cadamsdotcom
0 subcomment
- Or just.. prompt your agents to work together with a file or Unix pipe?
Takes a few words, is observable etc.
Or just .. don't have agents sharing a working copy. We stopped "checking out files" decades ago, why would agents - which work faster than humans - want that same problem.
- I've been using [agent-bridge](https://github.com/raysonmeng/agent-bridge), which is a Claude <-> Codex channel that works very well.
- Interestingly we did a version of a shared communication bus over MCP here https://github.com/instavm/murmur
The idea being mostly to use all of the coding agent subscriptions which are much cheaper than API access in order to delegate tasks, break down into chunks and distribute or even the standard coder/reviewer pattern.
by laul_pogan
1 subcomments
- I find that the real problem tends to be identity and trust across sessions- ideally there are ways to enable zero-knowledge trust between two agents in different environments.
I develop a similar tool open source tool called wire (wireup.net) https://github.com/SlanchaAi/wire
by majorbugger
0 subcomment
- My agent has full autonomy when it comes to spinning up new agents or talking to them so it's not an issue
- [dead]
- [dead]
Hacker News