Multi-Agent Coordination: How Planners and Workers Avoid Fighting Each Other

Core question: Multi-agent is not "just run several AIs". Parallelism introduces three new problems: who does what, how they exchange information, and how dependent steps are ordered. Angle: a breakdown of coordination mechanisms, sampled from a public agentic system.

Three problems that parallelism creates

Problem one: duplicated work. Two agents do the same thing at once, wasting budget and possibly interfering.

Problem two: information silos. Agent A sees an important clue mid-execution but does not consider it a "formal conclusion", so it records nothing — and agent B rediscovers it from scratch.

Problem three: dependency mis-ordering. Some steps must be sequential (obtain credentials before moving laterally). Dispatching them in parallel leaves later steps spinning on missing preconditions.

Each problem maps to a design response.

Technique one: role red lines — write the boundary into the prompt

The system encodes role division as explicit prohibitions, not merely positive descriptions:

• Planner: "You are the planner, not the executor — never do the work inside the plan."
• Worker: "Do only the single intent you were given."

This looks trivial but matters enormously. The most common failure mode in multi-agent systems is role drift: the planner starts doing the work, the worker quietly takes on someone else's job, boundaries dissolve, and duplication plus conflict follow.

Takeaway: in prompts, "what not to do" is often more effective than "what to do", because the model's default tendency is to be helpful.

Technique two: process-level information exchange

Traditionally agents exchange conclusions (facts, findings). But much of the value hides in execution process: an error message, a response fragment, a parameter that looked unimportant.

This system gives workers the ability to search across other agents' process:

• Keyword search across other works' process within the same task (excluding one's own steps);
• List which works have run, then fetch the full content of specific steps from one of them.

Information therefore flows between agents at the granularity of "execution process" — even an observation not yet formalised as a conclusion can be reused.

Takeaway: our own habit of "subagents report a summary only" loses process detail. Treating process itself as first-class data is an upgrade worth considering.

Technique three: a shared todo list — solving "stateless session + multi-step dependency"

The planner is woken frequently (on every state change), and each wake-up is a brand-new conversation — it does not remember the previous round.

Without a remedy, multi-step tasks with dependencies descend into chaos. The fix is a per-task todo list that persists across wake-ups:

• Round one: record the whole dependency chain once (e.g. injection point → credentials → lateral movement → privilege escalation);
• Every later round: dispatch only the next step whose predecessors are complete and whose required facts exist, updating the list as progress happens.

Even though the session itself is stateless, the chain advances steadily, without duplication and without reordering.

Takeaway: our long tasks face the same problem — context compaction or session restarts lose progress. Externalising the todo list into a file (rather than leaving it in context) is high return for low cost.

Technique four: a single intent generator — no many-headed chariot

The system designates the planner as the sole intent generator; workers may only claim, never dispatch.

This severs the path where a worker expands scope the moment it spots something new: on finding a valuable clue, a worker may only write a note for the planner, which decides whether to open a new direction.

Takeaway: this is the agent version of the "single writer" principle — one decision entry point, hence auditable and explainable.

The four techniques side by side

Technique	Problem solved	Essence
Role red lines	Duplication, blurred ownership	Bound the edges with prohibitions
Process-level exchange	Information silos	Treat process as first-class data
Shared todo list	Dependency mis-ordering	Externalise state, share across rounds
Single intent generator	Many-headed chariot	One decision entry point

These techniques generalise

Any setting where "several AI agents work in parallel for a long time" can adopt them: automated research, multi-party document review, large-scale refactoring, support ticket triage.

The test for needing them is simple: is the task parallelisable, dependent, repetitive? If any is true, start with role red lines and a todo list.

Next steps

• To see the two state graphs that planners and workers share, read the double-graph architecture
• To enter from the case context, read the case study
• To see how defenders respond to such systems, read defense lessons from the red-team postmortem