How agents work with each other

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.

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.

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.

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.