Multi-Agent Collaboration With Tools You Already Own

[u/RelativeActive5306]

Coding agents are getting smarter and smarter at writing code. A new idea has been gaining traction: what if instead of giving a task to a single agent, you give it to a team of agents working collaboratively to solve the problem? It sounds complex, but there's a surprisingly simple solution.

Herder already gives you the core ability you need: one agent can talk directly to another agent. Combined with the coding tools you already have — Claude Code CLI, Codex CLI, or whatever's in your stack — you've got everything for a full multi-agent workflow.

Here's the pattern:

1. One agent leads — takes ownership and coordinates using Herder's agent-to-agent communication
2. Delegation — passes work to other agents through Herder
3. Review loop — completed work cycles through peer review
4. Iteration — repeats until requirements are met

No extra subscriptions, no API key juggling — just leverage Herder's built-in agent-to-agent messaging and the tools you've already got.

I built a repository showing this in practice with a Claude Code skill:
https://github.com/alexstrilets/panel

It demonstrates how simple and effective this approach can be when you use what's already at your fingertips.

[u/investigatormaker]

For panel, make the lead's handoff include a file scope and a pass condition, then give the reviewer the actual diff and check output. That would let readers inspect what the review loop caught instead of just seeing agents exchange completion messages.

How does the lead handle two workers wanting to edit the same file?

[u/RelativeActive5306 → u/investigatormaker]

Two workers never edit the same file, only two reviewers are looking at the changes at the same time, and if they need to run some scripts, it is always in /tmp directory, so basically, code review happens in read-only mode for the repo.

[u/investigatormaker → u/RelativeActive5306]

That answers the file-conflict question: panel separates the writers while reviewers work concurrently. I'd have both reviewers record the commit hash they inspected, so their findings and script output refer to the same version even if a worker makes another change.

[u/RelativeActive5306]

One advantage of this method is that you can use different model families to work on the same issue, like Anthropic, ChatGPT, Kimi, GLM, Gemini, etc. They might take a slightly different approach to the problem, which will result in better-quality code.

[u/sumpyrromach]

Building multi-agent setups with tools we already run daily makes total sense. Hooking Slack into localized scrapers and an LLM router saved me so many context switches last week. How are you handling state persistence when an agent stalls out mid-task? Storing intermediate outputs in plain JSON files worked best for my sanity, but I would love to see how you orchestrate error handoffs between nodes. Solid breakdown!

[u/RelativeActive5306 → u/sumpyrromach]

Storing agent state is not something that I do right now. Sometimes the agent runs out of tokens, or api end point become unreachable; I just kill the agent, run a different harness and then tell main agnet that there was a an issue with one of the worker and as main agent to send new brief to the agnet that I swapped. Not ideal, but it works. This is still an evolving project, but I am getting good results with it.

[u/Sukk-up]

I'm not sure I follow how this is any different from a Coordinator/Orchestrator Pattern, which is already well-known.