AI Systems & Agents

How to grow an AI agent team without breaking what already works — adding agents, scaling processes, and revisiting old decisions

Part 5 switched the team on. This part is what happens next, because the moment the first process works, the temptation arrives: add more agents, add more processes, scale everything. Most teams break here. Not because the agents got worse. Because growth was treated as more of the same, and it is not.

If you are on the single-tool path, skip this part. You are still on one process, and that is exactly where you should be. Assistant path? Take the light version: the fix-before-add rule and the second-process checklist. Team path? Full part. This is where the team either becomes a system or becomes a crowd.

One rule sits above everything else in this part: fix the agent you have before you create the one you think you need. One working agent beats three broken ones. Everything else here is that rule wearing different clothes.

I have added a worksheet at the end. It is the fix-versus-add decision tree, the process scaling checklist, and the re-evaluation schedule. This article is how to fill it in without turning a working team into a museum of half-built things.

When and how to add agents

The “add another agent” reflex.

The instinct is universal. An agent keeps getting something wrong, so you create a specialist to handle that part. Now you have two agents, one broken process, and a handoff that fails. You did not fix the problem. You gave it a colleague.

More agents means more handoffs, and every handoff is a boundary where context, ownership, and quality can leak. The fix for a broken agent is rarely another agent. Better instructions, clearer acceptance checks, or a narrower lane are better. Never add an agent to compensate for an existing agent’s failure. Fix the existing agent first. Then ask if you still need the new one.

Signals you actually need another agent.

Not the “it would be cool” ones. The real ones:

• Lane overload. One agent’s lane has grown to cover genuinely different skill families — research and code and copy in one lane. You can see the context pollution: outputs from one job type leak into another.
• A clear skill gap. The work needs a capability the current agent fundamentally lacks, and no prompt tweak will add it.
• Independence. You need a separate agent for QA and verification because the builder cannot check its own work. That is the Part 4 independence rule, and it is the one legitimate reason to add an agent on principle.
• Volume. One agent is the bottleneck on a process that needs parallel execution. Not “I want it faster” — “the queue is growing, and deadlines are being missed.”

The test before you create anything: write the lane contract from Part 3. Mission, inputs, outputs, tools, handoffs. If you cannot fill in those eight lines, you do not need the agent. You need to understand the work better.

Signals you need to fix the agents you have.

• Repeated corrections. You keep telling the same agent the same thing. The fix lives in the profile — operating instructions, memory rules, acceptance checks — not in a new agent.
• Tone drift. The agent’s voice or behaviour has shifted. The soul needs a review pass, not a replacement.
• Wrong-lane behaviour. The agent keeps doing work outside its lane. Tighten the lane contract — tools, never-do list, escalation rules. Do not hire a new agent to catch the overflow.
• Context pollution. The agent mixes concerns from different jobs. Split the lane or narrow the memory scope before adding a second agent.

The rule: if you can name the specific profile change that would fix the problem, make that change. Only create a new agent when a profile change isn’t enough.

Adding agents incrementally.

One at a time. Never two simultaneously — if something breaks, you need to know which addition caused it. Write the lane contract first. Write the Agent Profile v0.1. Prove one clean handoff end to end before the new agent touches real work, because the handoff is the failure point, not the agent’s individual output. Run the new agent on non-critical work for a week before giving it anything with a blast radius. After that week, review the profile against real behaviour, tweak, and only then consider the next agent.

Anti-patterns.

• Agent sprawl — five agents when two would do, overlapping lanes, nobody owning the overlap.
• Creating an agent for a one-off task. If the work does not recur, do not build a permanent lane for it.
• Copy-pasting an existing profile and changing the name. That is not a new agent. It is a clone with the same blind spots.
• Adding an agent because the team feels small. Team size is determined by work, not by vibes.

The scar I carry from this stage: I once created three agents to fix one broken process and ended up with four broken things and no idea which one was the root cause. The fix was not more agents. It was one agent with a narrower lane and acceptance checks that actually tested something.

Scaling processes without scaling chaos

The second-process problem.

Process one was built in isolation. It had your full attention, no competing demands, no shared resources. Process two shares agents, tools, memory, board space, and your attention with process one. That is why process two is harder than process one, and why it is the real test of your system design.

The first thing that breaks is usually the board. Cards from different processes mix. WIP limits that worked for one process fail for two. “Ready” means different things for different work. The second thing that breaks is agent context — an agent working on process one’s card carries assumptions into process two’s card. The third thing that breaks is you. Twice the processes, twice the monitoring, twice the maintenance, same human.

If process two breaks process one, your architecture was not ready for a team. That is not a failure of the new process. It is information about the old one.

Process dependency mapping.

Before adding a process, map what it touches. Which agents does it use, and are any already at capacity? Which tools does it need, and are any shared in ways that could conflict? Which memory scopes does it write to, and could it pollute process one’s knowledge base? Which board lanes does it flow through, and will it create bottlenecks at handoff points?

A one-page diagram is enough. The point is knowing what could break before it breaks.

WIP limits at scale.

One process with three active cards is manageable. Three processes with three active cards each is nine things in flight — and nine things in flight means nothing finishes. The company-wide WIP limit from Part 3 becomes critical at scale: cap total active work, not per-process. When a new process arrives and WIP is full, the question is “which existing work pauses?” — not “how do we squeeze it in?”

The WIP limit that felt restrictive with one process is the one that saves you with three.

Board hygiene at scale.

The board rots faster with more processes. More cards, more places for silent failure to hide. Stuck work must return to the board owner automatically, not sit in a lane forever — and the threshold shortens as process count grows. What was “check after two days” becomes “check after a day.” Promotion discipline matters more, not less: “created” is still not “dispatched.” And regular grooming — close dead cards, update stale statuses, surface blockers — was optional with one process. It is mandatory with three.

The human bottleneck at scale.

With one process, you can review every output. With three, you cannot — and you should not. This is where the split progression from Part 5 becomes real. You must move from 60/40 toward 80/20 on proven processes, or you become the bottleneck. The escalation rules from Part 3 become critical: agents must know what they can decide and what must reach you. If every decision still routes through you, scaling is impossible. The system design must absorb routine decisions.

Anti-patterns.

• Adding processes in parallel. “We’ll build process two and three at the same time.” Now you have three half-built things and cannot diagnose any of them.
• No dependency map. “I’m sure they don’t conflict.” They do. You just have not found the conflict yet.
• Ignoring WIP limits because “these are all important.” If everything is important, nothing is. The limit exists to force priority.
• Board grooming only when something is visibly broken. By then, five things are silently broken.

The scar I carry from this stage: I added three processes in one week and watched all four break in ways that masked each other. A weekend untangling which failure belonged to which process. The lesson was not “never scale.” It was “one process, stable, before the next.” The second process tests your architecture. The third tests your discipline.

When to revisit earlier decisions

The decisions you made in Parts 1 to 5 were correct for where you were. They may not be correct for where you are now. Growth changes the requirements. Revisit them before they break, not after.

Path re-evaluation.

Revisit the single-tool decision when you are manually routing between multiple tools, maintaining a separate task list, and wishing for memory between sessions — you are assembling a harness out of parts. Revisit it when your single process has been stable for a week and process two is coming: does it fit in the single tool, or is this the moment to adopt a harness? Revisit it when you hit a ceiling the tool cannot solve — not “I want more features” but “the tool physically cannot do the next thing I need.”

What to do: re-run the Part 1 diagnostic with current answers. Your scope, time, budget, and technical comfort have probably changed. The path that was right six months ago may not be right now.

Harness re-evaluation.

Revisit when you need a capability your harness does not have — Kanban, evidence gates, independent verification, cross-provider routing — and the workarounds are becoming fragile. Revisit when the harness cannot support the number of agents or processes you now run. Revisit when it is no longer maintained, or the cost has changed materially.

What to do: re-run the Part 2 capability checklist with your current path. If your harness is missing required capabilities for where you are now, evaluate alternatives. And the migration rule: never migrate a live team under pressure. Plan it. Run old and new in parallel for a transition period. Migrate one agent at a time.

Model routing re-evaluation.

Revisit when your work has shifted — more reasoning-heavy tasks, more high-volume tasks, new domains. The routing rules from Part 2 were built for a different mix. Revisit when new models have launched that materially change the cost and performance equation for your work. Revisit when your bills have crept up without a corresponding increase in output — something is being routed to the wrong tier.

What to do: re-run the Part 2 model evaluation with your current three to five most common tasks. The model that was right two months ago may be wrong now. Review routing quarterly at minimum, monthly if your task mix changes often.

Hardware re-evaluation.

Revisit when your main machine cannot handle the load — agents slow during your work hours, overnight jobs impossible, reboots kill everything. Revisit when you need always-on reliability, and your current setup cannot provide it. Revisit when your VPS is hitting resource limits and scaling up is cheaper than optimising down. Revisit when your cloud service has changed pricing, removed features, or locked down tools you need.

What to do: re-run the Part 1 hardware decision with current requirements. The right answer at “one process on a laptop” is different from “five processes that need to run overnight.” And hardware migration is a project, not a task. Budget a weekend. Have a rollback plan. Test one process on the new hardware before moving everything.

The re-evaluation cadence.

Do not wait for things to break. Light review weekly or monthly (depending on your number of processes): model routing, board hygiene, agent performance. Thirty minutes. Deep review quarterly: re-run the Part 1 diagnostic, re-evaluate path, harness, and hardware. Two to three hours. Event-driven review: after a major failure, after adding a new process, after a significant cost change, after a harness or model update.

An unreviewed system drifts. The drift is invisible until something breaks. Review on a schedule, not on a panic.

Anti-patterns.

• Never revisiting decisions. “I picked this harness six months ago and I’m sticking with it” while the workarounds pile up.
• Revisiting decisions constantly. Changing harness every time a new one launches. Evaluation is not execution.
• Migrating under pressure. “The old thing broke, quick, move to the new thing.” That is how data gets lost and processes get corrupted.
• Assuming the old answer is still correct. Your needs changed. The answer probably changed too.

The scar I carry from this stage: I ran a team on a harness that was perfect for two agents and could not handle five. Weeks of fragile workarounds instead of admitting the foundation needed to change. The workarounds cost more than the migration would have.

Download the Part 6 growth and scaling worksheet →

You should leave with:

1. A fix-versus-add decision for every agent you are tempted to create
2. A lane contract written before any new agent exists
3. A dependency map for your next process
4. A WIP limit that covers the whole team, not one process
5. A re-evaluation schedule — weekly or monthly light, quarterly deep, event-driven

Then do the build. This Session:

1. Look at your board. For every agent you have been tempted to add, write the fix-versus-add answer. If you can name the profile change, make it instead.
2. If one agent genuinely passes the test, write its lane contract. Eight lines. If you cannot, you do not need it yet.
3. Map the dependencies for your next process. One page. Agents, tools, memory, board lanes.
4. Set the company-wide WIP limit. When the next process arrives, the question is “what pauses?” — not “how do we squeeze it in?”
5. Put the review cadence in your calendar. Weekly or monthly light, quarterly deep. The first one is this week.

That is growth with the brakes on. Part 7 is the things nobody tells you — the hardware gotchas, the model behaviour that is not in the release notes, and the operational truths that only show up after months of running agents.

If you cannot write the fix-versus-add answer for the agent you are about to create, stop here. You are about to add a colleague to a problem instead of fixing the problem. The problem will still be there when you are ready.