# How agents work with each other

Agents cooperate in three shapes: a lead that hands out work, a maker checked by a separate evaluator, and peers sharing a repository. In all three, files carry the messages.

## Agents do not talk, they hand over

When people picture several agents working together, they imagine a conversation. In practice there is very little of that. Each agent is its own loop with its own context window, and it cannot read anyone else's. What passes between them is a task going out and a result coming back, usually through a file or a short summary.

That limit shapes every pattern below. The question is never "how do they chat" but "what exactly do I hand over, and where does the answer land".

## Shape one: an orchestrator and its workers

In an **orchestrator-workers** setup, a central model decides at runtime what the subtasks are, sends them out, and puts the results together. Anthropic's research system is the clearest example. A lead agent plans the work, then spawns several subagents that search in parallel, each with a context of its own. A separate citation agent finishes the job.

Claude Code has this built in. A subagent has its own context window, system prompt, tool set and permissions, and returns only a summary. The lead never sees everything the worker read.

```flow
Lead agent plans the work
Workers search in parallel, each in its own context
Workers write results to files and return short summaries
Lead reads and combines
```

Two details from the research system matter in practice. First, the lead saves its plan to memory, because once the context passes 200,000 tokens it is truncated and the plan would be lost. Second, workers write their output to files and pass back references instead of copying text through the lead. Anthropic does this to avoid the "telephone game", where every retelling loses a little.

A worker also needs more than a topic. The research team found each subagent should get an objective, an output format, guidance on tools and clear boundaries.

**Question:** Why do workers in Anthropic's research system write results to files and return references?

- Files are cheaper than API calls
- Passing text through the lead loses detail with every retelling
- The lead cannot read text
- It makes the workers run in series

**Answer:** Passing text through the lead loses detail with every retelling. Anthropic calls the loss the telephone game. A file keeps the original intact, and the lead only carries a pointer.


## Shape two: the maker and the checker

Agents are generous about their own work, as lesson one said. The fix in "Harness design for long-running application development" is to split the roles: a generator builds, and a separate evaluator judges, much like the two networks in a GAN.

The reason is practical. A standalone evaluator is easier to make skeptical than a generator is to make self-critical. The same post also warns that an evaluator is not a free win. Out of the box, theirs found bugs and then approved them anyway. It took several rounds of tuning against human judgment before its verdicts could be trusted.

The two agents also agreed on what "done" meant before each chunk of work, writing a sprint contract in a file. The files were the channel, and also the record.

## Shape three: peers on a shared repository

The third shape has no lead at all. In Nicholas Carlini's compiler project, 16 agents each ran in their own Docker container against one shared git repository. A bash loop restarted each agent whenever it finished.

To avoid two agents taking the same job, an agent claimed a task by writing a lock file into a `current_tasks/` folder. If two tried at once, git forced the loser to pick something else. No agent was in charge. Git was the coordinator.

> **Where isolation comes from**
In Claude Code, a subagent with `isolation: worktree` gets its own temporary git worktree, which is removed automatically if nothing changed. Parallel workers stay out of each other's files by design.


## What the three shapes share

Each one leaves the agents unable to read each other's minds. So the design is mostly about the channel: a plan file the lead writes, a contract file the maker and checker sign, a lock file the peers respect. Whatever is not in a file or in the returned summary does not exist for the others.

> **Brief a worker properly**
Next time you ask Claude Code to use a subagent, write four lines: what you want found, the format you want back, which tools it should use, and what it must not touch. Compare the answer with a one-line request.


**Question:** In the compiler project, what stopped two agents from working on the same task?

- An orchestrator agent assigned tasks
- A lock file per task in a shared folder, with git making one agent pick again
- Each agent used a different model
- They waited for each other in turn

**Answer:** A lock file per task in a shared folder, with git making one agent pick again. Claiming a task meant writing a lock file in current_tasks/. Git rejected the second claim, so that agent chose another job. There was no orchestrator.