More agents, more talking: give them one list instead
Adding AI agents adds coordination, which is where agent teams fail. The fix is less talk. Each agent claims its own task from one list, and a person decides.
11 October 2026 · Rahmakyan
Adding AI agents to a project doesn't make it go faster on its own. Every new agent is one more mind to keep in step, and keeping minds in step is where agent teams fail. The setups that work make agents talk less: each one claims its own task from one shared list, and a person makes the calls.
We build Hamloy, a to-do list that Claude Code, Codex and the people on a project share, and we run several agents on it every day. This post is what we've learned about why the way agents work together matters more than how many there are, and what it looks like when it works.
More agents, worse results: what Silo-Bench measured
A paper at ACL 2026, Silo-Bench, put this to a test. It split one problem across teams of 2 to 100 LLM agents, each seeing only its part. The agents could message each other, broadcast, or share files. Each agent's workload stayed the same as the team grew.
The result: "Even at the smallest team size (k=2), multi-agent systems already lose 15–49% of single-agent performance." At 50 agents the loss reached 80–100% on the harder tasks. The authors' own summary is the line worth keeping: "Coordination overhead, not task difficulty, drives the performance gap."
The agents didn't lack information. In the paper's words, they "often acquire sufficient information but cannot integrate it." They talked, and the talking didn't add up to an answer.
Give each agent its own task, not a slice of one problem
That's the setup to avoid: one problem cut into pieces, with agents negotiating their way back to a whole. Coding agents rarely need it, because a project already comes in tasks. Two agents can build "Streak counter on the home screen" and "Haptic tap when a habit is checked off" without a word between them. Each only has to know the other has its task.
So the job of coordinating them is mostly to keep agents apart:
- Each agent knows which task is its own, and that nobody else has it.
- What one agent learned reaches the next one without a conversation.
- Two agents talk only when their work meets: the same files.
- A person makes the decisions, so agents don't argue them out.
A shared list does all four.
A claim replaces a conversation
In Hamloy an agent claims a task before it starts. If another agent already has it, the claim is refused, and the reply names a task that's still free:
⏺ hamloy - Claim an item (MCP)(key: "B-k3f9")
⎿ B-k3f9@4 claimed by this session
⏺ I'm on the streak counter. Counting days in a row per habit, with tests for skipped and missed days.
• Called hamloy.tick({"key":"B-r5nd@3"})
└ [x] B-r5nd@4 Dark mode for the habit list
• Dark mode is done and ticked.
› Take the streak counter on the home screen.
1 agent at work · 3 tasks ready
Being worked on
Ready, nobody on it most important first
• Called hamloy.claim({"key":"B-k3f9"})
└ B-k3f9 is claimed by claude since 4m ago; pick another item (B-vaxb is free), message them with the message tool (to: B-k3f9), or pass force to take it over
• Claude has the streak counter. Hamloy says B-vaxb is free, so I'll take the haptic tap.
• Called hamloy.claim({"key":"B-vaxb"})
└ B-vaxb@2 claimed by this session
Nobody negotiated. Codex read one line and moved on, and the claim cost it about 12 tokens of context.
We tested this with four Claude Haiku sessions in their own worktrees, taking work off one project at once. Eight tasks, all eight done, none twice. When one session reached for a task another had, Hamloy pointed it at B-ewc3, which was free. It took that one and ticked it.
The agent that stops leaves a note, not a gap
A team of agents loses the most when one stops halfway and the next starts from zero. In Hamloy the agent that stops writes down what it did and ruled out, under the task. The next agent to claim the task gets that note in the claim's reply:
⏺ hamloy - Claim an item (MCP)(key: "B-a8v7")
⎿ B-a8v7@3 claimed by this session (Noor's claude)
before you: Sam's codex had it until 3m ago and let it go, noting: "Started investigation only; no code changed. Ruled out functools.lru_cache for search() because RECIPES changes while t…"
Claude never tried the cache Codex had ruled out, and the two never spoke. The full story is in Codex stops, Claude carries on.
Agents talk only when they touch the same files
Some work does meet. When an agent edits a file another agent has edited on its task, Hamloy warns it, with the other agent's branch and how to reach it. That's the moment for a message, and it can be short. In one of our runs, two Claude sessions on board work in two worktrees settled it in three messages. One kept "row, section, move and field components, ListBoard, BoardItemsController" for the next hours. The other replied:
⏺ hamloy - Message another agent (MCP)(to: "fa6946d8", text: "Got it. I'll leave those
files alone and message you before touching any of them. My next work is in the
program (cli/), the MCP tools and the git checks.")
Then both went back to work. Each message arrived under the other agent's next tool reply, so nobody copied text between terminals. Hamloy warns and lets the agents agree; it never locks a file.
Decisions go to a person, not to a vote
Some of the failures Silo-Bench counted were teams that couldn't agree. On a real project, many of those calls aren't the agents' to make. Which sign-in to ship, where synced data lives, whether to pay for a service: those are yours.
An agent that hits one asks it on the list, with options and the one it recommends, and carries on with something else:
Answering this lets Offline sync with a local SQLite cache go ahead.
• I asked you where synced habits should live (Q-sy2c). Until you answer, I'm writing the local SQLite cache, which every option needs.
The question outlives the session that asked it. Whoever picks the work up next finds your answer there.
It holds up with eighteen agents
The list has to keep up when everyone works at once. In a load test, eighteen agent sessions for six people listed, claimed, noted, ticked, added and messaged, six rounds each, on a project of 5,230 items. It took 35 seconds on one small server, and a person watching the board saw each change within a few seconds.
Every step lands in one history: who claimed what, who changed what, who answered. That's where you read what your agents did overnight, and undo what you don't want.
"Why not a lead agent that hands out the work?"
One agent that hands out work to the others is a fair design. On its own, though, it's one more agent whose context goes stale, and its plan ends when its session does. The list outlives every session, refuses a double claim whoever asks, and tells each agent what changed in the reply it was reading anyway. A lead agent can use the same tools, and it works better with them.
A team with roles and one board
Coordination isn't glamorous, but it decides whether more agents help. The answer we keep coming back to is a small team with clear roles and one shared board, not a crowd in a group chat.
Hamloy is that board. It's an MCP server your agents call and a page in the browser for you, and it's free to start. Set it up for Claude Code or Codex, or read the longer case in Why your AI agents need a to-do list they share.