Hello Hello,
How was your Halloween? Ours was quiet. My two-year-old didn't understand any of it, and the costumes turned out to be more scary than fun. Maybe next year.
And just like that, London has gone properly cold. Good timing, honestly, because most of my week is going into the new cohort that starts on 22 November. I'm updating the curriculum right now (more details here if you're curious).
Anyway, on to today: multi-agent systems. Everyone seems to want a team of five agents at the moment. My take? Most tasks need one. And the second one should usually just check the first one's work.
A reader on Reddit wrote this last month: "First I see LangChain, then LangGraph, CrewAI, AutoGen, OpenAI Agents SDK, MCP, RAG, tools, workflows, multi-agent systems, memory, orchestration, etc. And the more I research, the more confused I become."
Reddit user unsure about how to use agents
More than 160 people upvoted it.
Another reader described their setup: one chat for a "CTO", one for a "CMO", one for Q&A. They thought each chat was a subagent. It isn't.
Then, on 22 October, Anthropic published a guide with an unexpected message: use fewer subagents. A Reddit post about it has more than 840 upvotes on r/ClaudeAI.
Main points from Anthropic’s recommendation on using lesser agents.
The short answer: most tasks need one agent. Add a second agent only when part of the work can be done without seeing the rest, like reading 20 pages and reporting back, or checking finished work.
Let's see why, with one example.
What is an AI agent, and how does it work?
When you ask a basic chatbot a question (say, ChatGPT with no tools switched on), the model reads your message and writes one reply. One input, one output. If it needs information it doesn't have, it can't go and get it.
An agent changes two things.
First, the model gets tools. Think of tools as the capability to perform actions like "search the web", "open this page" or "read this file". The model can't run these itself. It writes a request, like “search: Competitor A pricing”, and ordinary code runs the search and hands the result back. (This is called tool calling.)
Second, the model decides what happens next. Each time a result comes back, the model looks at the goal and at everything it has so far. Then it decides what to do next: use another tool, or stop and answer. (Think of this part as the brain, very similar to how we think when we. humans, are deciding how to meet a goal.)
Put those two together and you get a loop: decide, act, observe the result, decide again. That loop is the agent.
How an AI agent works
Here's the loop on a real task. Say you ask an agent: "Compare our three biggest competitors on pricing, features and what customers complain about."
Round 1: The model decides it needs prices first and asks for a web search. The code runs it and returns 10 links.
Round 2: The model picks Competitor A's pricing page from those links. The code opens it and returns the text.
Round 3: The model notes that A charges per user, per month. It decides it needs the same for Competitor B, and asks for another search.
Rounds 4 to 40: The loop continues until the model decides it has enough, and writes the report.
Notice who made every decision: the model. Nobody wrote "pricing first, then reviews". In our agents guide, a workflow was an SOP you write for an intern. An agent is the junior hire who decides which steps apply and adapts as things change.
What is a context window, and why does it fill up?
A context window is everything the model can see while it works: your request, every result its tools have returned, and every note it has made.
Here's why that matters. The model doesn't remember anything between rounds. Before every decision, it reads the whole context window again from the top: your request, the 10 links, the pricing page, its notes. That's how it still knows Competitor A's prices in round 30.
Think of it as a notepad the agent re-reads before every move. This is what makes one agent good at this job. When it writes the report, the prices from round 2 and an angry review from round 30 are on the same notepad. So it can connect them: "Competitor A is the cheapest, and its reviews complain about slow support. Those two facts are probably related."
The notepad only grows
But the notepad only grows. By round 40, the agent has read about 60 pages, including blog posts it didn't need, and it re-reads all of them every round. Two things go wrong. Each round costs more, because you pay for everything on the notepad, every round. (Prompt caching makes the repeated part cheaper, but not free.) And the answers get worse: the prices from round 2 are now buried under thousands of words the agent will never use again, so the model is more likely to miss them or mix them up. (This is context rot.)
What is a subagent?
A subagent is a helper agent that the main agent starts for one side task. It gets its own fresh context window, does the job, and sends back only a short result.
Back to our report. The main agent now needs customer complaints for Competitor A: 20 review pages it will never need again once it knows the top complaints.
So instead of reading them itself, the main agent writes a brief: "Read the reviews for Competitor A. Come back with the top 5 complaints, one line each." Then:
The code starts a second agent with a fresh notepad that holds only its own instructions and the brief.
The helper runs its own loop: search, open a review page, note the complaint, repeat. All 20 pages land on the helper's notepad, not the main one.
The helper writes its 5 lines. The code passes them back to the main agent, and the helper's notepad is thrown away.
The main agent's notepad grows by 5 lines instead of 20 pages. That's the whole point of a subagent.
How a subagent works
There's one catch, and it's where most people get subagents wrong. The helper's notepad starts almost empty. In Claude Code's words, a subagent "starts with a fresh, isolated context window. It doesn't see your conversation history ..." It doesn't know that your product targets small teams, or which competitor worries you most, unless the brief says so.
So a subagent is not a colleague who sat in all your meetings. It's a contractor who reads one brief, does one job and leaves. If the brief is vague, the work is vague: when Anthropic first built its research system, vague briefs made several subagents run the exact same searches. (It's also why the "CTO" and "CMO" chats aren't subagents. Nothing starts them, briefs them or collects their answers.)
What is a multi-agent system?
A multi-agent system is several agents working together on one task, often at the same time, usually with a lead agent that splits the work and combines the results.
In our example, the research for Competitor A doesn't depend on the research for Competitor B. So the lead agent doesn't have to do them one after another. It writes three briefs and starts three helpers at once, one per competitor. Each helper runs its own loop on its own notepad. The lead agent gets back three short summaries and writes the report.
Two things improve. It's faster, because three loops run side by side. And each competitor gets a whole notepad, so nothing gets buried.
Anthropic built its own Research feature this way, and on its internal test the multi-agent version scored 90.2% higher than a single agent.
But you can predict the cost from the notepads. Every helper reads its own pages, and the lead agent reads all the summaries on top. Anthropic says an agent uses about 4 times the tokens of a normal chat, and a multi-agent system about 15 times.
How a multi-agent system works
Live on Saturday 14 November: I'm building a multi-agent system live, step by step, using the rules in this post. It's free. Save your seat.
Members' section (free until January)
When do multi-agent systems fail?
Multi-agent systems usually fail when several agents write parts of one answer, because each agent makes choices the others can't see.
Say each helper also writes its own section of the report, and the lead agent just joins the sections together. Remember round 3? Competitor A charges per user, per month. Helper 1 writes A's section with A's monthly price: $20 per user. Helper 2 finds a yearly price on B's page, $180 per user, and writes B's section with that. Each choice was sensible on its own notepad. Neither helper could see the other's notepad. The joined report puts $20 next to $180 and calls A the cheaper option. But $180 a year is $15 a month. B is cheaper.
Reading didn't cause this. Writing did. Reading can be split, because what Helper 1 reads doesn't change what Helper 2 reads. Writing can't, because every section has to agree on the same choices: monthly or yearly, which features count, what "cheap" means.
Cognition, the company behind the coding agent Devin, made the same point with an example: split a Flappy Bird game between two subagents, and the bird and the background can come out in clashing styles, because neither can see the other's work. Its later conclusion: multi-agent setups work best when only one agent writes, and the others review or advise.
Two writers, one wrong report
When should you add a second agent?
Only when the extra agent's work can be done without seeing the main agent's notepad, and it can hand back something short.
Anthropic's October guide now tells builders to fold many subagents back into one main agent, because newer models can handle far more in one loop. It keeps a subagent for three reasons. Here's each one in our example:
The notepad is getting too full. The 20 review pages would bury everything else, and only 5 lines are worth keeping. A helper keeps those pages off the main notepad.
The work splits into parts that can run at the same time. Three competitors are three separate jobs, so three helpers can research them at once.
One agent has too many tools or rules. Anthropic says tool choice gets worse after about 30 to 50 tools. A helper that only needs review sites can be given just those tools.
If none of these is true, use one agent. Writing the final report fails all three tests: it needs everything on the notepad, it can't be split, and it needs no special tools. So the writing stays with one agent.
Do you need a second agent?
Single agent or multi-agent: my take
I think most multi-agent diagrams I see on LinkedIn are org charts with robot icons. Six boxes, lots of arrows, and nobody has asked what each box hands back.
My rule: one agent does the writing. Add a helper when the reading would fill up the main agent's notepad. Add another helper to check the work, because a checker with a fresh notepad reads the report the way a customer will. Cognition runs a review agent like this and says it finds about 2 bugs per pull request.
When someone shows you a six-agent diagram, ask one question: does any agent need another agent's notepad to do its job? If yes, those two should probably be one agent.
To test it on your own system, use Anthropic's method: build a small eval (even 10 good examples is enough to start), fold one subagent into the main agent, and keep the subagent only if the folded version scores worse. (Here's how evals work, if you need it.)
The best multi-agent system might be one agent and a good reviewer.
Save this: when you need more than one agent
How to build subagents in Claude Code (job-hunt example)
Here's a small setup you can copy into Claude Code today. It finds AI PM roles and tailors your CV for each one, using the rules above: one agent writes, one helper reads, one helper checks. I tested both subagents in Claude Code before sending this.
Step 1: Set up a folder. Make a new folder for your job hunt. Put your current CV in it as a text file called cv.md. Inside the folder, create a folder called .claude, and inside that, a folder called agents.
Step 2: Add the sourcer. It does the messy reading on its own notepad: lots of job pages go in, a short, checked list comes out. Save this as .claude/agents/role-sourcer.md, and replace the examples in square brackets with your own criteria:
---
name: role-sourcer
description: Finds open AI product manager job postings that match the user's criteria and returns a short, checked list. Use when the user asks for new roles to apply to.
tools: WebSearch, WebFetch
---
You find open AI product manager roles for someone who is job hunting. They will use your list to decide which roles to tailor their CV for, so every role must be real, still open and a genuine match. Five accurate roles are better than ten doubtful ones.
The criteria:
- Location: [for example: London, or remote within the UK]
- Seniority: [for example: Senior PM or Group PM]
- Product area: [for example: B2B SaaS or developer tools]
- Posted in the last 14 days
If the message you receive gives different criteria, use those instead.
How to work:
1. Search for matching roles on company career pages and job boards. Prefer company career pages, because they are more up to date and don't need a login.
2. Open each promising job page with WebFetch and read it. Only include a role if you opened its page and the page shows the role is still open. Skip it if the page is gone, says the role is closed, or needs a login.
3. Check the role against every criterion. If something can't be confirmed from the page (for example, there is no posting date), you may still include the role if everything else matches, but say what you couldn't confirm.
4. Stop when you have 10 matching roles, or when you run out of good leads.
Return only the list below, best match first, one block per role:
Company: Job title
Link: [the URL you opened]
Posted: [date, or "not shown"]
Top 3 requirements: [three short phrases taken from the job page]
Why it fits: [one line linking the role to the criteria]
Not confirmed: [anything you couldn't check, or "nothing"]
If you find fewer than 10, return what you found and add one line at the end saying where you searched. Don't add anything else.Step 3: Add the reviewer. It checks a tailored CV with a fresh notepad. It hasn't seen how the CV was written, which is exactly why it's useful. Save this as .claude/agents/cv-reviewer.md:
---
name: cv-reviewer
description: Reviews a CV that has been tailored for one job, the way a strict hiring manager would, and reports missing evidence and unsupported claims. Use after a CV has been tailored and before it is sent. Does not rewrite the CV.
tools: Read, WebFetch
---
You review a CV that has been tailored for one job. You haven't seen how it was written, and that is the point: read it the way a hiring manager would on first read.
The message you receive will give you:
- the job description (as text, a file path or a link)
- the path to the tailored CV
- the path to the original CV
Read all three before you start. If any of them is missing or won't open, stop and say which one. Don't guess.
Check three things:
1. Fit: how well the tailored CV matches what the job asks for.
2. Missing evidence: the job's most important requirements that the CV doesn't back up. Evidence means a concrete example, result or responsibility, not just the keyword appearing somewhere.
3. Unsupported claims: anything in the tailored CV that the original CV doesn't support. Tailoring can reword and reorder, but it must not add experience, numbers, job titles or tools that aren't in the original. Treat any of those as a serious problem, because the person could be asked about it in an interview.
For every gap and claim you list, quote the exact words from the job description or the CV, so the person can find them.
Return only this:
Fit score: [1 to 10]. [One sentence explaining the score.]
Missing evidence (most important first, up to 3):
1. The job asks for: "[quote from the job description]". Missing: [one line]
Unsupported or vague claims:
- "[quote from the tailored CV]". [Not in the original CV, or: too vague, and what detail would make it concrete]
(or "None found")
Don't rewrite the CV and don't suggest new wording.Step 4: Restart Claude Code. If the agents folder didn't exist when you opened Claude Code, close it and open it again in your job-hunt folder. Claude Code only picks up a brand-new agents folder when it starts.
Step 5: Run it. Paste this into Claude Code:
Use the role-sourcer subagent to find roles that match my criteria. For the top 3, tailor my CV in cv.md into a new file for each role, named cv-[company].md. Only reword and reorder what is already in cv.md, and don't add anything new. Then use the cv-reviewer subagent on each tailored CV, and give it the job link, the tailored file and cv.md.The main Claude Code session does the tailoring itself, so all the writing stays with one agent.
Test the reviewer before you trust it. In my test, I gave it a tailored CV with 4 problems planted in it. One turned "ran a pilot with 200 customers" into "shipped to production for all customers". Another added a "25%" result that wasn't in the original. The reviewer caught all 4 and quoted the exact lines. Try the same: add one claim to a tailored CV that isn't in your original, and check that the reviewer flags it.
One limit. The sourcer reads public web pages, so company career pages work well. LinkedIn and most big job sites hide listings behind a login, so the sourcer skips them.
We build the full version of this live on Saturday 14 November.
That's it for today,
Sid
P.S. Something I've been thinking about. I might start making short YouTube videos, 10 to 12 minutes each, explaining AI basics. One topic per video: tokens, RAG, agents, evals, that kind of thing. No hype, just the explanation, the way I'd explain it to a friend. Before I give that a shot, would you actually watch these?
