I let Claude run for 2 hours and 17 minutes yesterday.
Not one Claude. 65 of them. In parallel.
8 million tokens. 1,606 tool calls. 49 files reviewed.
Here’s what that actually looks like — and why the architecture matters more than the number.
The Problem
We had a backlog of 49 files flagged by our drive-recon scanner. Each one needed a human-level judgment call: safe to suppress, tombstone, or escalate?
The old way: one person, one file at a time, context switching constantly. You lose track. You make inconsistent calls. The backlog never clears.
The Architecture
Three phases. Fully DB-driven.
Phase 1: Configure + Assign (2 agents, ~2 minutes)
One agent loads config. One agent queries the database, selects every undispositioned file, assigns one agent per file. No guessing. No overlap. The DB is the lock.
Phase 2: Fan-Out (62 agents, parallel)
One agent per file. Each one does full multi-surface verification — read the file, check it against multiple reference surfaces, append a structured verdict to the database.
Append-only. These agents cannot delete. Cannot update. They can only add their finding.
Each one averaged 164K tokens. Escalation and distillation agents ran on top of that.
All 62 running at the same time.
Phase 3: Deterministic Merge (1 agent, serial)
One agent. Runs after everything else is done. Reads all verdicts. Executes tombstones and suppressions in order. Deterministically. No AI judgment at this stage — pure execution from a verified list.
AI does the judgment. The merge does the execution. They never mix.
The Real Numbers
- 65 total agents
- 8 million tokens
- 2 hours, 17 minutes wall-clock
- 1,606 tool calls
- ~164K tokens per file (consistent across batches — batch 1 was 167K/file)
- 49 files fully reviewed
What This Replaces
Manually: 3-5 minutes per file, 49 files = 2.5-4 hours of focused review. That assumes no meetings, no context switching, no interruptions.
I didn’t have any of those problems.
What We Learned (The Expensive Lesson)
The 8M token run hit the session context limit at 2h17m. The culprit was the merge step — one agent trying to hold 49 proposals in a single context window. Some data got dropped (FLAG-1).
The fix isn’t more context. It’s smaller batches.
Per-file cost was rock-solid: ~164-167K tokens per file regardless of batch size. That means a 49-file run was always going to land around 8M. The session limit was predictable.
The right batch size: 15-20 files.
At 164K/file, 15-20 files lands in the 2.5-3.5M token range — well inside a single session, with headroom for escalation, merge, and notify agents. Smaller batches also mean smaller merges, which directly solves the FLAG-1 data-drop problem.
This is the thing most agentic AI demos skip: knowing your cost model before you run the batch.
The Part Nobody Talks About
The bottleneck wasn’t AI capability. It wasn’t token cost.
It was trust architecture.
This works at scale because the agents can’t break anything. Append-only writes. Deterministic final merge. Even if one agent hallucinates, the merge agent sees a consensus — and if the consensus is wrong, you have a clean audit trail of what each agent said about that file.
You can argue with the decision. You can trace every vote.
That’s what makes this production-ready instead of a demo.
What’s Next
Batches of 15-20 files. Deterministic cost. No context limit surprises.
The remaining pipeline work fits cleanly inside a single session budget at that size. Smaller runs also mean faster feedback loops — a 2.5M run finishes in under an hour.
At this architecture, scaling isn’t “can the AI handle it.” It’s how many files fit in the budget window. Which is a very different problem.
Are you running AI agents in parallel yet? Have you hit a context limit mid-run and had to redesign the batch size? What did it cost you?