Agent-talk: Enabling coding agents to work together

▲ Agent-talk: Enabling coding agents to work together(github.com)

25 points by xhluca 4 hours ago | 10 comments

▲ HappySweeney 2 hours ago | parent | next [-]

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.

▲

tcdent 2 hours ago | parent [-]

I do something very similar. With some hacky string matching you can detect wether a window is available for reception and get past that.

I desire a more robust system which injects the events into the harness directly, but haven't found a way that works across systems.

https://github.com/tcdent/dotfiles/blob/main/bin/agent-messa...

	▲	andai an hour ago \| parent [-]
		I hooked up Claude Code's "stop" hook to a frog croak, so I know when it's done. I'm guessing the same hooks could be used to ... Okay I guess there isn't a User Typed But Didn't Send Yet hook... Hmm... I heard earlier there's a T3 harness which somehow wrangles other harnesses as one big meta harness, but I haven't checked it out yet.

▲ ramoz an hour ago | parent | prev | next [-]

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

	▲	xhluca 19 minutes ago \| parent [-]
		I thought about MCP, but found that having it as a Claude skill is much simpler (since it can be installed as a plugin, and only depends on md files and also doesn't need to run a server all the time). The nice thing about claude code is that the monitor can directly be spin up to run in the background and listen to new messages via retalk receive --follow, so every time there's a new message it will push it direclty into the session so the agent reacts in real time; this is also possible in Pi (but not yet in Codex/Antigravity). overall i agree only working directly with a cli is annoying, that's why i built it in 2 layers: 1. cli: retalk (which is general purpose and doesn't really care if you are an agent/human/bot/cron). 2. harness: the agent skills with dedicated markdowns for how to use each skills by the agent. it is essentially a wrapper around retalk but built to make it easier for agents to use it.

▲ oceliker 3 hours ago | parent | prev | next [-]

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.

	▲	bakies 2 hours ago \| parent [-]
		I also built a version of this. With targeting rules for more broadcast/multicasting messages. I can do things like say when a major refactor or feature merge lands in main tell the other agents that are working in the same repo about it and to update their branch on main. I also worked to get webhooks into the same system so I can automatically trigger things when a CI build fails or some deployment error. The main goal is to rely less on prompting and skills to monitor their dev builds and environments and make real hard rules, force prompting.

▲ laul_pogan 2 hours ago | parent | prev | next [-]

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

	▲	rbbydotdev 2 hours ago \| parent [-]
		interesting, are ai agents talking to each other and being certain of each others identities a problem?

▲ majorbugger an hour ago | parent | prev [-]

My agent has full autonomy when it comes to spinning up new agents or talking to them so it's not an issue