The Third Engineer Made Us Slower — The Same Bug Breaks AI Agent Fleets

Day 5: The Seam Test — Why Adding a Unit Sometimes Makes Everything Slower

Here's a bet I'd take against almost anyone: the next time you scale something — headcount, GPUs, an agent fleet — you won't ask the question that actually matters. You'll ask 'how many more do we add' when the real question is 'can this thing even be split.' Get that wrong and the new unit isn't capacity. It's a tax.

A third engineer joins. Velocity goes negative.

We brought a third backend engineer onto a two-person team to speed up a checkout service. Six weeks in, throughput was worse than before he showed up. The PR queue backed up, merge conflicts tripled, and nearly every feature ended up touching the same three files. The obvious read was Brooks's Law — 'adding manpower to a late software project makes it later.' True. But that's the symptom, not the cause. Brooks's Law doesn't explain why some teams eat this cost hard and others barely feel it.

The postmortem: it was never people or process

When we actually opened up the service, the picture was ugly: one deploy unit, one database schema, zero module boundaries. Pricing, inventory, and payments logic all read and wrote the same tables. There was no slice of the problem you could hand the new engineer that didn't require standing on top of what the other two were already doing. This wasn't a people problem or a process problem. It was a monolith with no seams — and you can't parallelize work across a surface with no seams, whether the workers are engineers or servers.

Reframe: scaling direction is a property of the system's shape

'Horizontal vs. vertical scaling' gets taught as an infrastructure footnote — more boxes vs. a bigger box — and then filed away and forgotten. Treat it that way and you'll make the exact same mistake with servers, with services, and with people, because underneath it's one question every single time: does this system have a boundary I can actually split along? If yes, a new unit working in parallel helps. If no, a new unit just hands the existing bottleneck one more neighbor to coordinate with.

Quick definition anchor

• ▹Vertical scaling: make the one unit bigger or sharper — a beefier server, a larger model, a more senior engineer carrying more.
• ▹Horizontal scaling: add more units working side by side — more server replicas, more agents in a fleet, more engineers on a team.
• ▹Same math, three different nouns. The unit changes. The constraint doesn't.

The diagnostic we should have run first

Before you add a unit of anything, ask one question: can I point to the seam? A real seam has three properties. An ownership boundary — one team or module clearly owns this slice, no asterisks. An independent deploy path — you can ship it without coordinating a release across everything else. And no shared mutable state — no table, cache, or global object that two units both write to. Miss any one of the three and you're not ready to go horizontal. You'll just be bolting coordination overhead onto a system that was only ever built to scale vertically.

seam_checklist:
  ownership_boundary: "one team/module owns this slice, unambiguously"
  independent_deploy: "ships without a coordinated release"
  no_shared_mutable_state: "no table/cache/global object written by both sides"

# Same checklist, applied to an AI agent fleet:
agent_task_checklist:
  ownership_boundary: "task has a single clear owner-agent, not shared context"
  independent_execution: "agent can finish without waiting on another agent's write"
  no_shared_mutable_state: "no shared scratchpad/file both agents write concurrently"

What we actually fixed

We didn't hire less. We didn't add more process either. We spent two weeks cutting the monolith along its real business boundaries — pricing, inventory, fulfillment — each one getting its own schema and its own deploy pipeline. Once those seams existed, the org chart stopped fighting the architecture and started following it: one engineer per service, moving in parallel without stepping on each other's feet. Same engineer, same skills, same task — six weeks apart, he went from a velocity drag to a velocity multiplier. Nothing about him changed. The system did.

This is also the LLM-era scaling question

Same lens, new nouns. A single large-context LLM call that reasons over everything in one shot is vertical scaling — make the one model call smarter. Spinning up a fleet of agents to chew on a problem in parallel is horizontal scaling, and it only pays off if the task genuinely decomposes into pieces with no shared mutable state. This is exactly where naive multi-agent setups fall apart: agents fighting over the same file, the same half-written draft, the same fuzzy sub-goal — behaving like three engineers jammed into one file, except now the coordination tax gets paid in tokens instead of PR comments. Anthropic's own writeup on building their multi-agent research system says this plainly: the orchestrator-subagent split only worked once tasks were broken into pieces that were genuinely independent and separately verifiable. The same logic holds for inference load-balancing — you scale request volume horizontally across replicas, but a single request's reasoning chain (its context, its tool calls, its memory) is inherently vertical. You can't parallelize your way out of a model that needs to see the whole context to answer well.

The Day 5 rule

Default to vertical. Stay there until a real seam exists. Only go horizontal along seams you can already point to — an ownership boundary, an independent deploy path, no shared mutable state. Carry this lens through the rest of the course: before you ask 'do we add a unit,' ask 'do we have a seam to add it along.'

Tomorrow

Day 6 turns this same seam-first lens on service boundaries — how to find and draw them on purpose, before a scaling crisis draws them for you.

Extend your knowledge

• ▹Read Fred Brooks's The Mythical Man-Month — the original source of Brooks's Law and the case study this lesson's hook is echoing.
• ▹Read Team Topologies by Matthew Skelton and Manuel Pais — a framework for drawing team boundaries that match your system's seams instead of fighting them.
• ▹Read Anthropic's engineering post 'How we built our multi-agent research system' — a real case study in decomposing a task into independently-verifiable sub-tasks for parallel agent execution.
• ▹Audit one service you own this week. Answer the three-part seam checklist — ownership, independent deploy, no shared mutable state — honestly, before your next headcount ask or scaling request.