Daniel's been building out a home inventory system for years now — barcodes, storage assignments, the whole thing — and the recent move to industrial storage meant every single asset lost its location in the database. Going box by box with a scanner was a multi-day job he didn't have time for. So he tried something clever: he photographed the contents of each box using an app called Timemark, zipped the images, and handed them to Claude with a skill that parses QR codes and asset numbers and updates the inventory. It worked.
The bottleneck was that each zip needed its own Claude instance, and running them in parallel triggered API throttling that ground things to a halt. That got him thinking about sub-agents — one orchestrator dispatching work to ten sub-agents, each handling a zip, the whole inventory done in one pass. But then he hit the deeper question: how does the orchestrator maintain its own coherence when it's drowning in update messages from all those sub-agents? He suspects there's a mathematical limit here — some approximate formula for when the context load of sub-agent updates overwhelms the orchestrator and the whole thing collapses. So today we're asking: when does the orchestrator become the bottleneck?
And it's a great question, because the orchestrator pattern is exactly what the field has been pushing toward. There's a piece on DEV Community from earlier this year — "The Orchestrator Pattern for Claude Agents: Delegating Everything, Owning Nothing" — and it lays out the architecture cleanly. You've got one central agent whose job is to understand the overall task, break it into pieces, hand those pieces to sub-agents, and then synthesize the results. The orchestrator doesn't do the work. It manages the work.
Which sounds like the dream, until you realize the orchestrator is also the one holding the context window.
Right. And that's the tension the article doesn't fully resolve. It describes the pattern — delegate, coordinate, synthesize — but it doesn't give you the rule for when the coordination itself eats you alive.
So let's start with what the orchestrator pattern actually is, and why Daniel's instinct to use it was right.
The pattern matters because it solves a real problem. If you're running ten independent Claude instances, each one is a silo. Instance three doesn't know what instance seven found. You get duplicate work, conflicting updates, and no unified view of progress. The orchestrator fixes that — it's the single brain that knows everything.
But here's the thing. The orchestrator doesn't magically know everything. It knows only what the sub-agents tell it. And every time a sub-agent reports back — "Box four processed, forty-three items identified, two QR codes unreadable" — that message gets appended to the orchestrator's context. The orchestrator has to hold all of those messages, plus the original task description, plus its own reasoning, in a single context window.
And context windows are big but they're not infinite.
Two hundred thousand tokens for the current Claude models, give or take. Which sounds enormous until you do the arithmetic. Daniel's got ten zip files, maybe fifty photos per box. If each sub-agent sends a modest update per item — let's say five hundred tokens — and there are fifty items per box, that's twenty-five thousand tokens per sub-agent. Ten sub-agents? Two hundred and fifty thousand tokens of pure update noise.
Before the orchestrator has even thought about what to do with any of it.
Before the orchestrator has said a single word of its own. The context window is already overflowing. And that's the generous case — five hundred tokens is a pretty terse update. If the sub-agent is verbose, or if it's reporting errors with stack traces, or if it's including sample data for verification, you can double or triple that easily.
So the math is almost insultingly simple at first glance. Sub-agents times updates times tokens per update. If that number exceeds your context window, you're dead before you start.
But the plan said the mechanism is more subtle than that, and it is. The failure mode isn't just running out of space. It's what happens on the way there.
This is the part where the orchestrator doesn't crash — it just gets stupid.
Anthropic published guidance on building effective agents, and one of the core recommendations is that orchestrators need to be lean. They should receive high-level summaries from sub-agents, not raw data. The reasoning is that even if everything fits in the context window, the model's attention is a finite resource. It's not a filing cabinet — it's more like a spotlight.
And the more updates you throw at it, the dimmer the spotlight gets on any one of them.
That's the attention dilution problem. The model is trying to maintain a coherent picture of ten parallel tasks, each generating a stream of updates. At some point, it starts losing track. It confuses which sub-agent is handling which box. It gives contradictory instructions — tells sub-agent four to update shelf B2 and sub-agent seven to update shelf B2 with a different item. It re-asks questions that were already answered three updates ago.
Which is exactly what Daniel described as grinding to a halt. The system doesn't throw an error. It just... wanders off.
And here's where the math gets interesting. The context load grows roughly linearly with the number of sub-agents and the frequency of updates. Double the sub-agents, double the update volume. But the orchestrator's ability to use that context degrades non-linearly. There's a tipping point.
Say more about the non-linear part.
Think of it like... no, think of it like a juggler. A juggler with three balls is fine. Five balls, still manageable with practice. Seven balls, and suddenly the error rate doesn't just go up — it explodes. The cognitive load crosses a threshold where the whole system destabilizes. The orchestrator is the same. At four sub-agents it's crisp. At six it's a little sloppy. At eight it starts dropping balls. At ten it's standing in a pile of dropped balls insisting everything is fine.
Which is a very specific kind of broken, because the orchestrator doesn't know it's broken. It's still generating confident-sounding output.
That's the scary part. The model doesn't have a built-in "I'm overwhelmed" sensor. It just keeps going, with progressively worse reasoning, and the degradation is often invisible until you audit the results and find that box nine's entire inventory got written to the wrong storage unit.
So Daniel's instinct about a mathematical limit is right, but it's not one number. It's two numbers interacting — the linear growth of context consumption and the non-linear decline of attention quality. The question is where those curves cross.
And that crossing point depends on the task. For Daniel's inventory system, where each update is a structured list of items and locations, the attention demand per update is relatively low. The orchestrator is mostly doing bookkeeping. For a task where sub-agents are writing code or making judgment calls, the attention demand per update is much higher, and the tipping point comes sooner.
So the same ten sub-agents that work fine for inventory might collapse at four if they're debugging Python.
Probably. The signal-to-noise ratio matters enormously. An update that says "Box three done, forty-five items, two errors" is high signal. An update that says "Item one two three four found, updated to shelf B two, item one two three five found, updated to shelf B two..." — that's noise. It's technically information, but it's drowning out the pattern the orchestrator needs to see.
This is where Daniel's original approach — independent parallel instances — starts looking smarter than it first appeared.
It's a real trade-off, and the misconception I want to bust is that sub-agents are always better. They're not. For small numbers of tasks, independent instances avoid orchestrator overhead entirely. Each instance has its own clean context window. No coordination, no update noise, no attention dilution.
The downside being they can't coordinate even when they should.
Right. If two independent instances both try to assign items to the same shelf location, they'll happily create a conflict and never know it. And Daniel hit the other limit — API throttling. Run too many parallel instances and the provider rate-limits you.
So you're choosing between two failure pattern. Parallel instances: throttling and no coordination. Sub-agents: context saturation and attention collapse.
And the art is picking the right one for the job, or — and this is where the design gets interesting — building a hybrid that avoids both.
But the hybrid is what Daniel was actually asking about. If the mechanism is clear, the real question is: how do you know when you're about to hit the wall? That's where the math comes in.
So let's build the heuristic. It's not a formula you'd publish in a paper, but it's a rule of thumb that'll keep you out of trouble. Step one: calculate your total update token volume. That's sub-agents times updates per task times tokens per update.
In Daniel's case, ten sub-agents times fifty updates times five hundred tokens. Two hundred and fifty thousand tokens.
Step two: compare that to your model's context window, and leave headroom. The orchestrator needs space for its own reasoning, the original task description, the skill definition, and the final synthesis. If your context window is two hundred thousand tokens, you probably want your update volume under a hundred thousand — half the window, roughly.
So Daniel's two hundred and fifty thousand is already more than double the safe budget.
And that's before we account for the attention dilution. Even if the context window could hold it all, the orchestrator's effective reasoning quality would degrade well before the window was full. The Anthropic guidance is essentially saying: don't fill the window. Keep it sparse. The orchestrator should see summaries, not raw logs.
Which brings us to update granularity. This is the knob you can actually turn.
The single biggest lever. The orchestrator doesn't need to know that item one two three four was found and updated. It needs to know that box three is done, forty-five of forty-seven items processed, two QR codes unreadable and flagged for manual review. That's a fifty-token update instead of a five-hundred-token update. You've just bought yourself a factor of ten.
And you've also increased the signal-to-noise ratio. The orchestrator can actually see the shape of the project instead of squinting through a blizzard of line items.
The trade-off is that you lose granular control. If something goes wrong in box three, the orchestrator knows there were two errors but doesn't know which items. It has to either re-dispatch a sub-agent to investigate or flag the whole box for human review.
Which in Daniel's inventory system is probably fine. He's going to spot-check anyway.
The right granularity depends on the cost of errors. For inventory, coarse is fine. For a system that's trading financial instruments, you might need finer granularity and you'll just have to accept fewer parallel sub-agents as the price of that precision.
So the rule of thumb is taking shape. Estimate your update volume, compare to half the context window, and if you're over budget, either reduce sub-agents or coarsen the updates.
There's one more tool, though, and it's the one the Anthropic research emphasizes most: summarization and checkpointing. The orchestrator periodically summarizes the entire state — "As of checkpoint three, boxes one through seven are complete, forty-two items flagged, storage assignments updated for three hundred and twelve items" — and then discards the raw sub-agent updates.
It hits the reset button on its own context.
It's exactly the same principle as conversation compaction in long-running agent sessions. You compress the history into a dense summary and continue from there. The raw details are lost, but the essential state is preserved.
And you can do this at regular intervals. Every five boxes, checkpoint. Every ten sub-agent completions, checkpoint. The orchestrator's context never grows beyond the most recent checkpoint plus the updates since.
The VentureBeat piece on Claude Code's Tasks update touched on this. The update lets agents work longer and coordinate across tasks, but the article implies pretty clearly that coordination itself is a resource. The more tasks you coordinate, the more overhead you pay. Checkpointing is how you pay that overhead in installments rather than all at once.
So the full design principle is: estimate your update budget, coarsen your granularity, and checkpoint aggressively. That's how you keep an orchestrator coherent.
And if you do all three, ten sub-agents in one pass might actually be possible, even for Daniel's inventory. Let's re-run the numbers. Coarse updates: fifty tokens per box instead of five hundred. Ten sub-agents times fifty updates times fifty tokens — that's twenty-five thousand tokens. Checkpoint every five boxes and discard the raw updates. The orchestrator's active context never exceeds maybe thirty thousand tokens. That's well within budget.
The dream is alive, it just needs discipline.
The dream is alive if you design for minimal context consumption, not maximal parallelization. That's the core insight. Most people reach for sub-agents because they want to go faster, and they crank up the parallelism without thinking about what it costs the orchestrator. The right instinct is the opposite: ask how little the orchestrator needs to know, and build outward from there.
There's a knock-on effect here that I think is worth naming. The orchestrator's coherence isn't just about context size or even attention dilution. It's about something more fundamental, which is that the orchestrator is trying to hold a mental model of a system that's changing underneath it.
Say more.
When a sub-agent sends an update, that update describes the state of one box at one moment. By the time the orchestrator reads it, three other sub-agents have sent updates about three other boxes, and the orchestrator's mental model is now a patchwork of slightly stale snapshots. The more sub-agents, the staler each snapshot is relative to the others.
At some point, the orchestrator is reasoning about a system state that never actually existed at any single moment. It's synthesizing a fiction.
That's... yeah. That's a sharper way to put it than I've seen anywhere. The orchestrator isn't just overwhelmed — it's operating on a temporal collage. Box one's update is from ten minutes ago, box nine's is from thirty seconds ago, and the orchestrator is trying to make a coherent decision that applies to all of them simultaneously.
The decision might be perfectly logical given the information it has, and completely wrong for the actual state of the system.
Which is why checkpointing helps in two ways. It compresses the context, sure, but it also forces a synchronization point. The checkpoint says: "As of this moment, here is the true state." Everything before it is frozen and discarded. The temporal drift resets to zero.
The checkpoint is doing double duty. It's a context garbage collector and a state synchronizer.
Now I'm thinking about the Digg article that mentioned dynamic workflows with parallel sub-agent fleets. The article suggested these fleets are only viable with careful context management, and I think what "careful context management" really means is exactly this — you need synchronization points. You can't just fire off sub-agents and hope the orchestrator keeps up.
The fleet metaphor is actually useful here. A fleet doesn't work if every ship is sending position updates every thirty seconds and the admiral is trying to track them all in real time on a paper chart. The admiral needs periodic summaries — squadrons reporting in, not individual ships.
If one ship goes silent, the admiral knows something's wrong and can investigate. But if all ten ships are chattering constantly, the admiral can't hear the one that's actually in trouble.
That's the attention starvation problem in a nutshell. Too many updates drown out the critical ones.
Let's put a bow on the practical answer for Daniel. The limit isn't a fixed number of sub-agents. It's a function of three things: the model's context window, the update granularity you choose, and the complexity of the coordination the task requires.
You can estimate it by calculating your update volume — sub-agents times updates times tokens per update — and keeping it under roughly half the context window. You checkpoint to prevent accumulation. You coarsen updates to the minimum the orchestrator actually needs. And you accept that beyond some point, more parallelism doesn't mean more speed — it means more overhead.
If you're still over budget after all that, you don't add sub-agents. You add hierarchy. Sub-agents report to intermediate managers, who summarize and report to the orchestrator. Each level compresses the information.
Which is, not coincidentally, how human organizations solve the same problem. A CEO doesn't manage fifty direct reports. She manages five VPs, each of whom manages five directors. The hierarchy is a context-compression structure.
Daniel's inventory system is small enough that one level of hierarchy is probably fine. Ten sub-agents, coarse updates, periodic checkpointing. But the principle scales.
Before we wrap, Hilbert's been scribbling on his whiteboard back there — I think he has something to say.
Hilbert: Late nineties, I was a warehouse coordinator for a mail-order catalog company. Burlington, Vermont. Flannel shirts, mostly.
Hilbert: We had a team of twelve pickers, each with a radio. They'd call in when they pulled an item. I tracked it all on a whiteboard — order number, picker, bin location, done or not done.
Hilbert: The whiteboard held about forty lines before it filled up. When it filled up, I'd erase the oldest rows to make space. The problem was, sometimes I'd erase a row for an order that wasn't actually shipped yet. The picker had called it in, but it was still sitting on a cart somewhere.
You'd ship it twice.
Hilbert: Or not at all. I lost an entire pallet of wool sweaters in November of ninety-eight because I erased the row too early. Forty-seven sweaters. The customer called in December asking where his order was and I had no record of it ever existing.
What happened to the sweaters?
Hilbert: Found them in March. They'd been pushed behind a rack in the loading bay. The picker — guy named Frank — never radioed in that he'd staged them. Just left them there and went to lunch.
Frank was your sub-agent that went silent.
Hilbert: Frank was a sub-agent who sent one update and then assumed the job was done. The AI equivalent is a sub-agent that reports "task complete" and the orchestrator erases it from context, but the task wasn't actually complete — it just looked complete from the sub-agent's point of view.
Did Frank still work there in March?
Hilbert: Frank retired in January. Never knew. I still have a grudge.
Hilbert: The point is, we fixed it by changing the reporting rule. Pickers stopped calling in every item. They called in when a bin was full, or when an order was fully staged and verified. Coarser updates. The whiteboard never filled up after that.
Hilbert: You don't need ten sub-agents. You need ten sub-agents that know when to shut up.
Hilbert just summarized the entire episode in one sentence.
He really did. The whiteboard is the context window, the pickers are the sub-agents, and the fix was exactly what we've been describing — coarser granularity, fewer updates, only the information the coordinator actually needs.
Did you ever get in trouble for the sweaters?
Hilbert: I had to write a letter to the customer. Handwritten. The company didn't have email yet. I still remember the address — forty-two Maple Street, Montpelier.
Hilbert: He wrote back saying he'd found a different sweater and wasn't mad. I kept the letter.
That's unexpectedly wholesome.
Hilbert: It was a good sweater. Wool blend. Forty-two dollars.
I have so many follow-up questions and I'm going to ask none of them.
Hilbert: Probably for the best.
That's a perfect note to end on. Let's pull back and think about what this means for the future.
If you take one thing from this, it's that the orchestrator's coherence isn't a storage problem — it's an attention problem. You can fit all the updates in the context window and still lose the plot. The limit isn't how much you can cram in; it's how much the model can actually think about at once.
The open question that leaves us with — as context windows grow to a million tokens and beyond, does the orchestrator's coherence limit scale proportionally? Or does attention dilution become the binding constraint regardless of window size? My suspicion is the latter. A bigger whiteboard doesn't help if you can only look at one corner of it at a time.
The next wave of agentic frameworks may need built-in context budgeting — not just tracking token counts, but tracking the orchestrator's effective decision quality. A dashboard that says: you're at sixty percent context utilization but your attention score is dropping. Time to checkpoint.
Daniel's inventory system is a microcosm of a much larger challenge. How do you coordinate many minds — human or artificial — without losing your own? The answer, it turns out, looks a lot like how you'd run a warehouse in the nineties. Keep the updates sparse, checkpoint often, and never trust a picker named Frank.
Thanks to Hilbert Flumingtop for producing, and for the sweater story we're all going to be thinking about for the rest of the day.
This has been My Weird Prompts. If you want to send us your own questions — about agentic AI, inventory systems, or the mysterious fate of forty-seven wool sweaters — email the show at show at my weird prompts dot com.
We'll be back soon. Try not to fill your context window in the meantime.
