Planning and Multi-Agent Systems

You ask an agent to compare how three open-source web frameworks handle security updates: how fast they ship fixes, how they announce them, and how long old versions get patches. It reads Framework A's documentation, then B's, then C's. By the time it writes the report, its history holds dozens of pages. The report says Framework A supports old versions for two years. That was Framework C.

Nothing was wrong with any single step. The history got too long for the model to keep three similar sets of facts apart, a problem Context Rot looks at closely. There are two tools for it: make the agent plan, and split the work across several agents that each see less.

#Plan first, then act

An agent running the agent loop picks one step at a time. On a long task that leads to drift: it follows an interesting lead, forgets a part of the request, and runs out of steps with one framework still unread.

The fix is cheap. Before any tool call, ask the model for a short plan. Keep that plan in the history as a checklist. Have the agent tick items off, and rewrite the plan when it learns something new.

The checklist makes it harder to forget part of the task. A person can read it and correct the approach before any work is done. And you can see progress: "step 4 of 6" means something.

The plan is a guess, not a contract. Step 4 exists because the agent expects some pages to be incomplete. If Framework B turns out to have no security page at all, the right move is to rewrite the remaining steps, not to follow the old ones.

#Several agents, each with a fresh context

Planning keeps the agent on track, but all three frameworks' pages still pile up in one context. The second tool is to split the work.

In a common design, an orchestrator agent breaks the task into parts and hands each part to a worker agent. Each worker starts with an empty history and only its own part. It does the reading, and sends back a short summary. The orchestrator never sees the raw pages, only the summaries.

The numbers are illustrative. The single-agent total assumes the task (100 tokens) plus 12,000 tokens of pages per framework, Both totals count what each agent holds, not what it re-reads on every call (The Agent Loop showed how fast that grows). Shorter histories re-read less, so splitting can sometimes save tokens. In practice, briefs, summaries and repeated searches often make it cost more. The shape is what matters: workers keep the orchestrator's context small and focused, and the work can run in parallel. Each worker is just the loop from the previous lesson, given its own goal.

// runWorker(brief) runs one agent loop and returns its final answer.
function orchestrate(goal, parts, runWorker) {
  const summaries = parts.map((part) =>
    runWorker(`Overall goal: ${goal}\nYour part: ${part}\n` +
      "Reply with at most 5 bullet points, each with a source link."));
  return summaries; // in a real app, run the workers in parallel
}
 
const fakeWorker = (brief) => `summary of: ${brief.split("\n")[1]}`;
console.log(orchestrate("Compare security updates",
  ["Framework A", "Framework B", "Framework C"], fakeWorker));
// [ 'summary of: Your part: Framework A', ... ]

# run_worker(brief) runs one agent loop and returns its final answer.
def orchestrate(goal, parts, run_worker):
    summaries = [
        run_worker(f"Overall goal: {goal}\nYour part: {part}\n"
                   "Reply with at most 5 bullet points, each with a source link.")
        for part in parts
    ]
    return summaries  # in a real app, run the workers in parallel
 
fake_worker = lambda brief: f"summary of: {brief.splitlines()[1]}"
print(orchestrate("Compare security updates",
                  ["Framework A", "Framework B", "Framework C"], fake_worker))
# ['summary of: Your part: Framework A', ...]

The worker knows only what is in that brief, so it must carry the goal, the boundaries of the part and the shape of the reply. "Research Framework B" gets back a vague essay.

#When one agent is better

Multi-agent systems are popular to draw and often no better in practice. They often cost more in total. Every handoff loses context the orchestrator had and did not write down. And when the final answer is wrong, there are more places to look.

Split work only when the parts are truly independent: researching separate topics, checking separate files, trying separate approaches and keeping the best. Keep one agent when the parts depend on each other. Two workers writing different halves of the same program will each make reasonable choices about names, data formats and error handling, and the choices will not match.

#Try it yourself

#Common mistakes

#Check yourself

#What to practise next

More agents and more steps mean more ways to go wrong quietly. Continue with Evals to measure whether an agent actually does its job, then Guardrails to limit what it can break.