🍕 Why split the work among multiple agents
New here? Run multiple agents in parallel means running more than one Claude Code session at the same time, each working on a different part of the task. Instead of asking it to “scrape the 3 sites, one at a time” and waiting for each one to finish, you ask it to do all three at once, in three windows — the total time drops to roughly the time taken by the slowest one, rather than the sum of all three.
Let’s distinguish two ways of working that have already come up in previous modules. Sequential It’s one request after another in the same session: the agent finishes task A, then starts task B. Parallel it’s opening separate sessions that work at the same time, each on its own task. Neither approach is “better” in general—the right question is whether the tasks depend on each other. If task B needs the result of task A, they have to run sequentially by definition—you can’t parallelize something that depends on something that doesn’t exist yet.
💡 Main Concept
It's the same idea as splitting a big cleanup among three people instead of one—each takes care of a room, and the house gets done faster. But if one room depends on another being clean first (for example, dusting before mopping), you can't parallelize that part—someone has to wait.
✓ Good time to run in parallel
- ✓Extract data from 3 different, unrelated websites
- ✓Each agent writes to its own output file
- ✓Independent tasks with a tight deadline
✗ Bad time to parallelize
- ✗Task 2 needs the result of task 1 before it can start
- ✗The tasks would have modified the same file
- ✗A single, simple task that already runs quickly on its own
🗂️ One folder (or tab) per agent
Caption: a large request can become three independent tasks running at the same time, each in its own folder or terminal tab—the results come together when they’re all done, instead of waiting for one at a time.
New here? One session is a conversation open with Claude Code—each time you type claude in a terminal, a new session starts, with its own memory of what was requested inside it. Each Claude Code session runs in isolation within a project folder or terminal tab. To run in parallel without one agent interfering with another, open separate terminal tabs (or separate folders, if each task modifies different files) and start a claude in each one.
This matters because separate sessions don't "talk" to each other—the Agent 1 discovered doesn't automatically appear to Agent 2. If a step depends on information another agent generated, that information needs to become a file (the CSV, a text file) that the other agent can read later. That's why, when building module 2.5, each tab saves its own output file instead of trying to "notify" the other session.
💡 Practical tip
Name your terminal tabs after the site or task (most terminals let you rename a tab by double-clicking its title). With three tabs open at once, it’s easy to forget which one is doing what — a clear name saves you from clicking around to find out.
Objective: three independent sessions actually running at the same time. How to verify: open your terminal’s tab manager and confirm that there are 3 active tabs, each with a different conversation in progress.
⚠️ The risk: two agents writing to the same file
The biggest concern with parallelism is avoiding two agents editing the same file at the same time — one can overwrite the other's work without warning. Divide the task so each agent has its own output file (e.g., produtos-site-a.csv, produtos-site-b.csv) and only then combine the results.
See inside: there is no automatic mechanism to prevent two agents from writing to the same file — each session simply rewrites the entire file when it finishes, as if it were the only one in the world. If both sessions write produtos.csv overlapping one another, whoever saves last "wins," and the other session's work disappears without any error notice. This isn't a Claude Code bug — that's how any program that rewrites a file behaves. The protection is always up to you: use different file names for each agent.
Caption: when two agents write to the same file, there is no automatic merge—the last one to save overwrites what came before, with no error warning. That’s why each agent needs its own output file.
✓ Do
- ✓Each agent writes to its own output file
- ✓Combine the files only after they have all finished
✗ Avoid
- ✗Two agents editing produtos.csv at the same time
- ✗Sharing the same CLAUDE.md as two agents rewrite it together
🧩 Splitting the scraping build into three parts
Looking at the build for module 2.5: if you need prices from three different websites, that’s the perfect split for parallel work—each site is completely independent of the others.
Objective: three CSVs ready at the same time, instead of one after another. How to verify: all three files exist and each has real data rows — then just combine them (or ask the agent to combine them) into a final CSV.
Running three scrapes at the same time doesn’t change each one’s responsibilities: continue respecting the site’s terms of use, avoid overloading the server with too many requests, and avoid collecting personal data unnecessarily — the same rules as module 2.5, now applying to all three tabs at once. Running in parallel increases the chance that a site will notice unusual traffic and block you, so it’s even more important not to overdo it.
🛠️ Common errors when running in parallel
- One of the three tabs freezes or shows a site that blocks scraping: don't wait — let the other two continue and resolve just that tab (change strategy or skip the problematic site). One isolated failure shouldn't bring down the others.
- Empty result in one of the CSVs: usually, the site changed its structure or blocked that specific session. Run just that tab again, by itself, before suspecting an issue with the request.
- Invalid key if the site requires an API: if any of the three sites has an official API with a key, check that the key was pasted correctly before opening all three tabs—finding that out at just one of the three sites, halfway through the run, costs twice as much time.
💰 The cost of running in parallel
New here? Token it’s the unit that measures how much the agent “read and wrote” in a conversation—each word or part of a word processed counts as tokens, and that’s what creates the cost. Each parallel session uses tokens independently—three agents running at the same time cost roughly the sum of what each would cost on its own (it isn’t “free” just because it runs in parallel). The benefit is time, at an added cost. It’s worth it when the urgency justifies it, not all the time.
Caption: running 3 tasks in sequence or in parallel uses the same total number of tokens—the only difference is how long you wait on the clock. Parallel isn’t cheaper; it’s faster.
⚠️ Attention
Don’t open 10 agents “just because you can” — each one uses real tokens. Save parallel work for tasks that actually benefit from running at the same time.
💡 Practical tip
If your plan has some kind of usage limit (for example, a daily or monthly message cap), opening several sessions at once uses that limit faster. Before splitting a large task across sessions, check how much of your limit you’ve already used that day—it helps you avoid running out of agent time in the middle of important work.
🔗 Bringing the results together at the end
After the three agents finish, one final request—in a single session—combines the separate files into a final result. It's the same principle of “fetching” separately from “writing” that Track 4 (Deployment) will explore in more depth: each part runs in isolation, and everything is combined in a single step that's easy to repeat if something fails along the way.
Timeline of a parallel build
one Claude Code session per site, each with its own request.
none waits for another; each one writes its own CSV as it progresses.
quickly check whether any of the three ended with an empty result or a block before continuing.
one final request, in a new session, combines the three files into a consolidated result.
Objective: a single consolidated final CSV. How to verify: the number of lines of produtos-final.csv matches the sum of the lines in the three original files.
This wraps up Track 2. You’ve gone from “what is an MCP server” (2.1) to running multiple agents that search real data in parallel and combine everything into a final CSV (2.6)—including installing and authenticating real servers (2.3), saving commands in a cheat sheet so you don’t have to relearn them from scratch (2.4), and building a working scraper (2.5). The thread connecting all six modules is always the same: give the agent an external tool—whether an MCP server or the browser itself—and treat errors, keys, and usage limits as a normal part of the work, not an exception. In Track 3, the next step is to teach the agent to repeat an entire process, from beginning to end, without you having to explain each step again: this is a skill.