Any problem is N subagents

I keep hitting the same wall with agents: the instruction limit. Not the context window — that’s a different problem. I mean the ceiling on how much direction you can give a single agent before it starts ignoring half of what you told it.

You write a careful system prompt. Fifteen rules, three constraints, a handful of examples. The agent follows most of them. But the more you add, the more things slip. Rule 12 contradicts the spirit of rule 4. The examples bias the output in ways you didn’t intend. And you end up playing whack-a-mole — patching one failure mode just creates another.

The obvious fix

Make the agent smaller. Not smaller context, smaller scope. Instead of one agent that does everything, spin up a focused subagent that does one thing well. Give it five rules instead of fifty. Let it be an expert in a narrow slice of the problem.

This isn’t a novel idea. It’s just decomposition. But I think people underestimate how far it scales.

N scales with complexity

Here’s the conjecture I keep coming back to: any agentic problem can be solved by N subagents, where N is proportional to the complexity of the problem.

Simple task? N is 1. You don’t need orchestration for “summarize this file.”

Medium task — say, reviewing a pull request? Maybe N is 3-5. One agent checks code quality. One checks test coverage. One looks for security issues. Each one gets a tight prompt and a narrow job. An orchestrator collects the results.

Hard task — building a feature from spec? N might be 10+. Planner, implementer, tester, reviewer, each scoped to a phase. The orchestrator becomes the interesting part.

The point isn’t that more agents is always better. It’s that when a single agent starts failing, the answer is usually to split it, not to make its prompt longer.

Why this works (I think)

A focused agent with a short prompt follows its instructions more reliably than a general agent with a long one. That’s the whole insight. Everything else is plumbing.

When an agent has one job, you can evaluate whether it did that job. When it has fifteen jobs, failures get tangled — did the code review miss that bug because the review prompt was bad, or because the agent was also trying to check style, suggest refactors, and write a summary at the same time?

Small agents are debuggable. Big agents are mysterious.

The part I haven’t figured out

Orchestration overhead. Every time you split an agent, you add coordination cost. The subagents need to communicate. The orchestrator needs to know when to fan out and when to sequence. State gets passed around. Failures need to propagate.

Right now I mostly solve this by keeping the orchestrator dumb — fan out, collect results, merge. But I suspect there’s a more principled approach I haven’t found yet. Some kind of agent DAG that handles dependencies and error propagation without turning into a distributed systems problem.

Or maybe it is a distributed systems problem and I should just accept that.

The meta-observation

This is how software engineering already works. You don’t write one function that does everything. You decompose. You write small, focused functions with clear interfaces. The fact that the same principle applies to agents shouldn’t be surprising, but it keeps catching people off guard — myself included.

Maybe because we want agents to be magic. We want to hand over a vague task and get back a perfect result. And sometimes that works. But when it doesn’t, the fix is the same boring thing it’s always been: break it down.