I Ran 830 Agents in One Long Horizon Session.

One working session on Orbyt spawned 830 AI agents across seven days.

At its busiest instant, nine of them were running.

Both numbers are real, and the gap between them is the interesting part.

Agents are cheap in sequence. Attention is not. That gap is the whole shape of long horizon AI-native work now.

What 830 agents actually looks like

Here is the count, taken from the session transcripts on my machine, covering June 26 to July 27, 2026. Not an estimate. A file count, where one agent means one agent that actually started, so the handful that queued and never ran are not in it.

One month: 2,800 agent runs. 2,589 of them ran inside 95 orchestrated workflows, and I spawned the other 211 directly from the main thread of a session.

Five separate working sessions each commanded more than 250 agents. The largest was 830. Then 579, then 556, then 375, then 274. A session here is one continuous working session, which in this kind of work runs across days rather than hours: the 830 spans seven of them, July 19 to July 25. The sharper number is the daily one. My heaviest single day was 316 agents, on July 19, and 311 of those ran inside that one session.

The largest single workflow, one command, one run, spawned 298 agents by itself.

None of that is a benchmark or a stunt. It is what a month of building a production product looks like when the unit of work stops being a message and starts being a fleet.

The number that matters is nine, not 830

Totals are the easy number. Concurrency is the honest one, so I measured that too, by taking every agent's start time and duration out of the transcripts and counting how many overlapped.

The 830-agent session never had more than nine agents running at the same instant. It was almost entirely workflow-driven, and a single orchestrated workflow run holds its fan-out to eight at a time. It hits exactly eight, every run, which is why the largest workflow I have ever run spawned 298 agents while never exceeding eight in parallel.

Fan-out straight from the main thread is not bound by that. My highest measured concurrency in any session is 20, on July 3, on a ten-core M1 Max with 64GB: twenty agents launched back to back over about three minutes and all still in flight at once. Other days topped out at 17 and 16.

So there are two ceilings, and neither of them is the total. Orchestrated fan-out goes deep. Direct fan-out goes wide. Either way the 830 did not happen at once. It accumulated across seven days as work fanned out, finished, and fanned out again.

That gap, between 830 over a week and nine in any given second, is the entire lesson.

If you assume agents are scarce, you write one careful prompt and iterate on it. If you know agents are cheap in sequence, you stop optimizing the prompt and start designing the fleet. You spend a hundred agents to answer a question three ways, because a hundred agents cost less than one wrong decision, and the sequence is free even when the parallelism is not.

The old instinct was to make one conversation smarter. The new instinct is to make one question survive many independent attempts to answer it.

The agents are not copies of each other

This is where most people picture a swarm of clones doing the same task faster. That is not it, and a fleet built that way is just an expensive way to get the same answer repeatedly.

The agents specialize, and the structure is adversarial on purpose.

Finders sweep one surface, and one surface only, looking for problems. One agent per page, per subsystem, per dimension. Each one is blind to what the others are turning up, which is the point, because a single reviewer has a single set of blind spots.

Refuters attack. On Orbyt's showcase review, three refuters hit every finding a finder produced, and their default stance is that the finding is wrong. A finding survives only if at most one of the three kills it, and only on cited evidence. Most findings do not survive. That is a feature.

Graders score what is left against a rubric written down in advance, so the bar is a document rather than a mood.

Verifiers reproduce a claim independently before it is trusted.

The redundancy is the product. One agent gives you a plausible answer. A panel gives you a tested one. And plausible is the specific failure mode of every model on the market, which is why verification is the literacy that matters now.

So what is the actual constraint

Not compute. Not context. Not the model.

Me.

I can start unlimited agents. I can judge only so much of what comes back. So the binding constraint in this kind of work moved from doing the work to trusting the work, and once it moves there, no amount of additional fan-out helps. Adding a two hundredth agent to a session where I am already behind on reading the first hundred does not produce more throughput. It produces more unread output, which is worse than none, because unread output that looks authoritative is how a wrong thing ships with confidence.

Reading 250 reports is not the job. Reading 250 reports is the failure state.

Fan-out is a long horizon problem in disguise

Seven days and 830 agents is not a big task. It is a long horizon task, which is a different thing: work whose correctness cannot be judged at the end of any single run, because every step inherits the last one's output.

That is what makes the sequence dangerous rather than merely long. Agent 400 builds on what agent 12 concluded. A wrong answer that nobody reads stops being an error and becomes a foundation, and everything after it is built true to a false premise.

Long horizon work also does not fail loudly. It fails green. So the real question for a fleet is never how many agents I can run. It is how long a wrong answer can survive inside the fleet before something that is not an agent catches it.

Concurrency is a throughput number. Time to detection is the one that decides whether the throughput was worth anything.

The fix is mechanical, not heroic

The only way out is to stop being the thing that reads everything, and the only way to do that safely is to make the machine fail closed.

That means a harness where every change runs the full build, the whole test suite, and a stack of deterministic guards before it can land, and where one failing guard stops everything. It means adversarial review stages that kill weak findings before they reach me, so what surfaces is what survived attack. It means an evidence standard the agents cannot argue around: cite a file and a line, a live URL and what it returned, or a recomputed number, or it did not happen.

Then I review proof and exceptions instead of reading diffs. The harness reads everything. I read what the harness could not settle.

That is the actual reason to build the test harness first, and it is why this work looks less like prompting and more like engineering the loop. The skill is not the prompt anymore. The skill is writing the rubric, the refutation rule, the evidence standard, and the conditions under which the whole thing stops. Then you let it run.

Where this breaks

Parallel agents multiply plausible output exactly as fast as they multiply correct output. A fan-out with no adversarial stage is a faster way to be confidently wrong, and it will feel more rigorous while being less so, because volume reads as diligence.

Orchestration only pays when the work genuinely decomposes. Three hundred agents on a question that was always one judgment call is theater. The signal that you decomposed it correctly is that the agents disagree with each other, and you learn something from where they split.

And unanimity is a warning. If every lens returns the same answer, the honest read is often that you are paying many times for one opinion, not that you found the truth.

The part worth taking away

The floor on what one person can direct has already moved past what one person can read. That is not a future problem. It is sitting in last month's transcripts.

So the leverage is no longer in commanding more agents. It is in building the system that lets you trust what several hundred of them did without reading it, and then spending your whole attention on the calls that system cannot make.

The bottleneck is the human. That is exactly where it should be.

Related reading

• Long Horizon Agents Don't Fail. They Pass.
• My C-Suite of Agents Named Themselves.
• Verification Is the New Literacy
• Why Build an AI Test Harness