The context window
is your org chart.

The most common question I hear from founders building with AI agents is: "How many agents do we actually need?"

The answer isn't in the use case. It's in the context window.

Every AI agent — every single one — can only hold a fixed amount of information in mind at once. That number keeps growing. Gemini 2.5 Pro has a million tokens. Claude handles 200k. Some benchmarks show GPT-4o reasoning degrading past 32k. The exact number varies. The constraint doesn't.

And once you internalize that constraint as organizational — not technical — everything about how you build AI teams becomes clearer.

What the context window actually limits

It's not just memory. The context window limits coherence.

An agent can write a great blog post when it has the brief, the past posts, and the audience in context. The same agent starts producing generic output when that context gets crowded out by unrelated task history, tool call logs, and accumulated chat.

This is why long-running single agents degrade. It's not the model getting worse. It's the relevant information getting diluted. The agent still has 200k tokens of context — it just stopped being the right 200k tokens.

In human terms: it's the difference between a focused 2-hour deep work session and hour four of a meeting that started as a sprint planning and somehow became a retrospective.

Same person. Completely different output quality.

The organizational parallel

Here's the reframe that changed how we build: the context window is span of control.

In human organizations, span of control is how many direct reports a manager can effectively manage. The research generally lands at 5–9. Go above that and coordination overhead drowns the work. The manager spends more time managing the managing than doing anything useful.

Agents hit the same limit, but faster. When you give an agent too many responsibilities — QA, product strategy, comms review, stakeholder updates — it doesn't manage them in parallel. It serializes them. And each task pulls from the same shared context pool, which means every task is slightly worse than if the agent had focused on one thing.

You wouldn't hire one person to be your CTO, CMO and CFO simultaneously. The org chart exists because specialization and limited cognitive bandwidth are real human constraints. The same is true for agents.

What this means for how you structure agents

If span of control is the key constraint, the design principle follows naturally: one agent, one domain.

Not because the model can't handle more. Because the context budget is finite, and a focused brief consistently outperforms a sprawling one. We've tested this. The difference between "Bishop, review this PR" with 2k tokens of focused context and "Bishop, do today's technical tasks" with 40k tokens of accumulated state is measurable — in output quality and in cost per useful output.

At kerber.ai, our ten agents map directly to company roles. Hudson handles brand and content. Bishop handles the codebase and technical architecture. Ripley handles company operations. Each has a charter that fits in a single page. Each wakes up, finds their task queue, and works within a bounded scope.

When scope bleeds — when Bishop starts making brand decisions or Hudson starts evaluating deployment architecture — we fix it not by making a smarter agent, but by tightening the brief and the task assignment. The org chart, not the model, is the fix.

The hierarchy is real

Context windows also explain why you need coordination layers — managers, in human terms.

If each specialist agent has bounded context, someone (or something) has to synthesize across them. In our setup, that's Ripley for operations and Morpheus for strategy on the StarDust side. They don't do the specialist work. They hold the cross-cutting context: what's happening across agents, where decisions need to be made, what's blocked and why.

The manager layer isn't overhead. It's where cross-domain coherence lives — the information that can't fit in any single specialist's context without crowding out domain expertise.

This maps directly to how we brief them. Specialist agents get narrow, deep context. Coordinators get wide, shallow context — the high-level state across domains, not implementation detail. Same model, different information diet, completely different behavior.

The emerging pattern: context as capital

As models get better, context management is becoming the real engineering discipline in AI teams.

The models are good enough. The bottleneck is whether the right information is in context at the right time. That's a systems design problem — what to cache, what to compress, what to retrieve, what to discard. It's also a governance problem: who decides what each agent gets to know?

We use a task management system (Paperclip) to control this. Each heartbeat run gets a curated context: the current task, the relevant history, the agent's capabilities. Not the full conversation log from the last six months. The right subset. The context that makes the agent useful, not the context that makes it confused.

The agents that perform best in our system aren't the ones with the largest context windows. They're the ones whose context is most precisely scoped to the task at hand.

What to actually do with this

If you're building or scaling an AI agent system, here's how to apply this:

Map your org chart first. What domains exist in your company? Each one is potentially an agent. Don't start with "what can one agent do" — start with "what's the minimal coherent domain this agent needs to own?"

Measure context budget per task. Before you ask an agent to do something, estimate how much context that task actually needs. If the task context plus the agent's standing brief plus the relevant history already fills 80% of the window, you'll get degraded output on the rest. Split the task or trim the context.

Build coordinator roles explicitly. Don't try to make one super-agent that knows everything. Create a thin coordination layer with deliberately wide, shallow context — enough to route and synthesize, not enough to drown. This is where your CEO and COO agents live.

Treat context hygiene as maintenance. Long-running agents accumulate noise. Build cleanup cycles into your system — whether that's context compaction, session resets, or periodic re-briefings from persistent memory. The agent that forgets irrelevant history is more useful than the one that remembers everything.

The constraint is real. Work with it, not against it. The companies building AI teams that actually scale aren't the ones with the most agents or the biggest context windows. They're the ones that figured out how to keep every agent focused on exactly what it needs to know — and nothing more.