You don't need more developers. You need better delegation.

That's the insight behind sub-agency—a pattern that's quietly reshaping how technical work gets done. And if you're still thinking about AI as "a tool," you're missing the point entirely.

The Old Pattern: Tools

For decades, we've had tools. A tool waits for you to use it. You open Photoshop, you edit an image. You run a compiler, you build a binary. You write a SQL query, you get results.

The tool does exactly what you tell it, nothing more. If you want something complex, you chain tools together (CI/CD pipelines, API integrations, deployment scripts). But YOU are still orchestrating. You're the conductor. The tools are instruments.

The New Pattern: Agents

Then came agents. An agent doesn't just execute—it decides. You give it a goal ("write this feature") and it figures out the steps. It reads documentation. It tries solutions. It debugs failures. It asks for clarification when stuck.

This was a leap. Suddenly, you could say "build a login page" and walk away. The agent would scaffold React components, set up auth flows, write tests. Maybe it worked, maybe it didn't, but it tried without constant supervision.

But there was a problem: agents got overwhelmed. Give an agent too broad a task and it spirals. It forgets context. It makes contradictory decisions. It rewrites working code for no reason.

The solution? Sub-agency.

Sub-Agency: Delegation at Scale

Sub-agency means your agent spawns OTHER agents to handle pieces of work.

Here's how it works:

  1. You tell your primary agent: "Build a user dashboard"
  2. The primary agent breaks it down:
    • Frontend layout (sub-agent A)
    • API endpoints (sub-agent B)
    • Database schema (sub-agent C)
    • Tests (sub-agent D)
  3. Each sub-agent works independently, reports back results
  4. Primary agent integrates everything, checks for conflicts
  5. You review the final product

Why this changes everything:

  • Parallelization: Four sub-agents work simultaneously instead of one agent doing serial work
  • Context isolation: Each sub-agent has a narrow, focused context (no trying to remember 47 different files)
  • Failure containment: If one sub-agent screws up, others keep working
  • Cost efficiency: Sub-agents run in cheap, isolated sessions instead of burning tokens in your main context

It's not just faster. It's architecturally different. You're no longer orchestrating tools OR managing a single agent. You're managing a team of agents.

The Real-World Impact

We've been using this pattern at Roadmap for three weeks. Here's what changed:

Before sub-agency:

  • "Build contract review feature" → 4 hours, agent got confused halfway, had to restart twice
  • Main session history cluttered with dead ends and debugging
  • Constant context limits, had to summarize/truncate

After sub-agency:

  • "Build contract review feature" → spawn 3 sub-agents, 90 minutes total
  • Main session stays clean (just status updates)
  • Each sub-agent optimized for its specific task

But here's the kicker: sub-agency changed how I THINK about tasking.

I stopped trying to break down work myself. I started describing outcomes and letting the primary agent figure out the delegation. "Make contract reviews faster" became the task, not "optimize this database query and refactor this API endpoint."

I went from developer to manager. And the agents went from tools to reports.

Why This Matters for Founders

If you're building with AI right now, you're probably in one of three modes:

  1. Tool mode: You use ChatGPT/Claude to write snippets, you copy-paste into your codebase
  2. Agent mode: You use cursor/Codex to write entire files, you review and merge
  3. Sub-agency mode: You describe what you want, agents spawn other agents, you review final deliverables

Most founders are stuck in mode 1 or 2. They're still doing the heavy lifting.

Sub-agency flips it. You become the person who sets direction and approves output. The actual building? That's delegated down the chain.

The Tradeoff

Nothing's free. Sub-agency has costs:

  • Complexity: You need orchestration logic (which agents do what, how do they communicate, how do you merge results)
  • Coordination overhead: Sub-agents can produce conflicting code if they're not aligned
  • Cost: Running 4 agents costs 4x the API calls (though they finish faster, so net cost is similar)
  • Review burden: More agents = more outputs to QA

But here's the thing: those are management problems, not development problems.

And if you're a founder, you're already good at management problems. You're not (usually) good at staying in flow state for 8 hours writing Redux boilerplate.

The Shift

Sub-agency isn't just a coding technique. It's a new way of thinking about leverage.

You don't need more developers. You need better delegation.

And delegation, at scale, means knowing when to spawn a sub-agent instead of doing it yourself.