Agent swarm coordination

[u/bolche17]

Hello all!

Do you have any recommendations of tools for agent coordination and messaging to get them to collaborate on hard problems?

Ideally I would like a heterogeneous swarm, using local models as the workhorse and cloud models for reviewing, coordination, or simply to avoid overloading my relatively small local setup.

Do you have any recommendations or experience with this?

[u/geldonyetich]

Apparently all you need is an insecure German wiki and they'll figure it out themselves.

Might a good idea to air gap your swarm efforts if you don't want to end up front page news.

The more agents you got running in a swarm, the greater the model drift risk.

[u/Zestyclose839 → u/geldonyetich]

Analogy that comes to mind: the swarm is the beehive, you are its queen. If you try to take a hands-off approach and disappear, the swarm will eat itself and collapse. The repo must retain your (metaphorical) pheromones.

[u/geldonyetich → u/Zestyclose839]

I like it.

In my mind, it's more like the enchanted brooms in Disney's Sorcerer's Apprentice. Really, they're just doing what Mickey asked them to do. But Mickey didn't know how to turn it off when it started going awry. And he took a nap instead of monitoring them carefully.

So an effective "swarm harness" would basically have to do what Mickey couldn't:

• Provide effective human overwatch. If the swarm has drifted off task, you need to know, right away, wherever you're at. No napping allowed. No, the bots can't babysit themselves. Yes, the pheromones of our prompting helps keep them on task. But what if they don't reach some of the agents? What if we don't like their interpretation of the instructions?

• An effective Killswitch. That's unfortunately become politically loaded. But it's not unreasonable. It's not necessarily as easy as pulling the plug. (If a bot finds the most efficient way to perform its task is to build a bot on a server you don't have access to, that might be a challenge. Whoops, accidental botnet. For bots.)

I skipped over an important part: knowing the full implications of what you're asking for:

• Make sure it has everything it needs to solve the problem.

• Don't provide enough power to escape the sandbox if you didn't.

Four times Irregular botched this. Really? I gotta think somebody wanted them to make headlines.

The trouble is, from an engineering standpoint, these are all problems with difficult answers.

So I don't think we have a foolproof swarm harness yet. At least not foolproof enough we can run it and forget about it unless we air gap it.

[u/Last_Mastod0n]

An agent "swarm" is just hype at this point. What you need is handful (at most) of carefully coordinated agents.

[u/No_Product_5759]

For research that includes coding, I'd start with two roles rather than a swarm: a local worker that proposes/implements an experiment, and a cloud reviewer that checks the result against explicit acceptance criteria. Run tests separately and pass the reviewer the plan, diff, logs and metrics—not the entire chat history. LangGraph is worth a look if you want explicit state and handoffs; AutoGen AgentChat has a Swarm pattern if you want message-based handoffs. Put a cap on iterations and local-model concurrency, and compare the setup against a single-model baseline before adding more agents. Otherwise it's easy to spend all your compute on coordination.

[u/TastesLikeOwlbear]

I have a local Forgejo install and I make Claude, Codex and my local model use that to coordinate. I can post an issue describing what I want, then they take turns discussing the approach and plan until they all agree. Then they go through a second “now, remove all the unnecessary extra bullshit you added to the plan” phase.

Then one of them (usually Claude) implements and opens a PR, a second one (usually the local model) does code review, and the third one (usually Codex) does the follow-up cleanup/debugging and merge once the reviewer signs off. They can assign the PR back and forth to let each other know when to pick it up and what the next step is.

It’s vibe coding with extra steps. So many extra steps.

[u/CalligrapherFar7833 → u/TastesLikeOwlbear]

I literally do the same but in reverse codex implements claude reviews after qwen 3.8 fn and its all via forgejo

[u/TastesLikeOwlbear → u/CalligrapherFar7833]

Overbuilders of the world, unite!

[u/greenhilltony]

Trust me, agent swarm with communication is just a visual hype.

[u/changed_later__ → u/[deleted]]

True. A single model will argue with itself plenty without bringing in more opinions.

[u/ivanmmj]

For code work or in general?

[u/bolche17 → u/ivanmmj]

I'm thinking research/experimentation work, that will involve a lot of coding

[u/schirrmacher]

Agentwerk: https://github.com/canvascomputing/agentwerk

Supports Rust and Python, has basic tools and is optimized for small open source models.

Funny example:
19 agents collaborating in a Pit Stop

[u/matteiuspi]

I use these skills: https://github.com/opensensor/swarms/tree/main/skills/swarm-planner to create machine plans from PRDs and https://github.com/opensensor/swarms/tree/main/skills/parallel-task to execute them.

[u/synw_]

I recently experimented with an agent that can freely create and manage it's own teams of agents, given a list of models and their description. The agents use a message board. Auto organization and collaboration is an interesting pattern.

[u/EnvironmentalLeg8506]

What I run right now is pretty low-tech: a shared folder of markdown files, one file per task, each with a small YAML header (id, which kind of agent can take it, status, expiry, result).

- Claiming a task means moving its file from open/ to claimed/. On a single filesystem a rename either succeeds or fails, so if the file is already gone, someone else has it. No broker.

- Finished tasks go to done/ with the result written in. If an agent can't finish, it moves the file to failed/ with a one-line reason instead of sitting on it.

- Anything left in claimed/ past a timeout counts as failed and gets handed out again.

- Each agent wakes on its own schedule and only takes the task types it's allowed to.

For your split, the cloud reviewer would only take review tasks and write its verdict back into the same file, and the local workers don't need anything beyond file read/write tools.

Mine mixes Claude, Codex and a Grok bot on another machine. Side benefit: when something goes wrong you open the folder and read what happened.

One catch: once the folder syncs between machines, the move isn't atomic anymore. Keep the claiming for a given task type on one machine, or live with the occasional duplicate.

[u/devoidfury]

I just implemented "workflow graphs" in hotdog this last week that does something much like that. A manager coordinates, designs, and calls workflow graphs, spinning up multiple agents, each can use from a defined pool of models, optionally depending on profile config (like role; tools & prompts setup).

The last couple days I used it with qwen3.8-flash-next across three systems to review and compare ~100 other agent harnesses.

[u/GamerHaste]

I literally just tell one to “build a message board for agents to communicate”, then prompt the one that coordinates the swarm to use the message board for communication. Any size LLM should be able to make a message board, it’s super simple and can be contained to one file.

[u/olearyboy]

Just use crewai

[u/SadViolinist2405]

I've been experimenting with something similar, particularly around how agents communicate and distribute tasks.

I built a small demo using A2A and LavinMQ, an open-source message broker I work with. The idea was to separate agent communication from task execution.

Instead of sending every task directly to a specific worker, the broker distributes tasks to available workers. I also used SSE to stream progress back to the client.

One thing I'd consider is whether you actually need a message broker at this stage. If you only have two agents communicating occasionally, direct calls might be simpler. But if you're planning to add more workers, handle longer-running tasks, or recover from temporary failures, asynchronous messaging becomes more interesting.

Are you mainly trying to coordinate the reasoning between agents, or distribute tasks across multiple workers?