[dead]
Agent-talk: Enabling coding agents to work together
11–20 of 28 posts
Re: Agent-talk: Enabling coding agents to work together
#12The 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 Code…
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.
Re: Agent-talk: Enabling coding agents to work together
#13I 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 woul…
Can you tell me more about the cache misses causing a hefty bill? I think I read somewhere that interacting with a CC instance that has been idle for over an hour can cause a cache miss. Is this what you are referring to? How hefty of a bill are we talking? (using Fable for instance)
Re: Agent-talk: Enabling coding agents to work together
#14I'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.
Re: Agent-talk: Enabling coding agents to work together
#15Or 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.
Re: Agent-talk: Enabling coding agents to work together
#16I 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 woul…
Can you tell me more about the cache misses causing a hefty bill? I think I read somewhere that interacting with a CC instance that has been idle for over an hour can cause a cache miss. Is this what you are referring to? How hefty of a bill are we talking? (using Fable for instance)
Iirc the cache hit is 10% of normal input token cost. After the hour you are charged 100% input token cost for the whole conversation.
Re: Agent-talk: Enabling coding agents to work together
#17I'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 t…
Which llms are in the swarm? What is the “weighing in” prompt?
Re: Agent-talk: Enabling coding agents to work together
#18Interestingly 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.
Re: Agent-talk: Enabling coding agents to work together
#19I 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
interesting, are ai agents talking to each other and being certain of each others identities a problem?
My tool has a public-good relay and the ability to chat between environments, so it's important to resolve ID to operator or company
Re: Agent-talk: Enabling coding agents to work together
#20[dead]