How a Tiny Team Ships Like a Big One · The Product Track
An agent that knows when to stop
Fixed iteration counts are the wrong loop condition for research agents. Ours stop when their evidence is sufficient - and their runtime dropped by half.
We used to watch our research agents finish the job and keep going. An agent assembling an account brief would land the key findings by tool call 12 or 15 - and then spend another 25 calls dutifully re-confirming what it already knew, because its loop condition was "run 40 iterations," and 40 is what it would run.
Nobody designed that on purpose. Fixed iteration counts are just the default shape of an agent loop: easy to write, easy to budget, easy to defend in a code review. They're also the wrong condition, in the same way "search for exactly two hours" would be the wrong instruction for a human researcher. The interesting question is never how long have I looked - it's do I have enough.
Stopping on evidence, not on a counter
The fix was to make the agent audit its own coverage. Our research agents track what they've established per dimension of the brief they're building - and the loop's exit condition is a claim about that evidence: stop when each dimension that matters has enough independent, sufficiently confident support. In practice, a coverage tracker the agent was already maintaining for output purposes became the live decision gate.
The effect was blunt: runtime on these agents dropped by roughly half. Easy accounts - where the signals are loud and the evidence converges early - finish in a third of the old budget. Genuinely thin accounts still run long, and now that length means something: a long run is a signal the evidence is scarce, not an artifact of a hardcoded 40.
A ceiling still exists, because everything here runs under budgets - an agent that can stop early can still be stopped. The cap just moved from being the design to being the backstop.
The loop that heals instead of failing
The second half of the same redesign was what happens inside each iteration when the world doesn't cooperate. The old pipeline had the classic brittle shape: if a search returned junk, the run either crashed or - worse - quietly ingested the junk.
The query loop is now a small state machine. It starts in SEEDING, casting broad queries to establish what exists. It moves to ENRICHING, targeting the gaps its coverage tracker exposes. It exits at SUFFICIENT - the evidence gate from above. And on failure it doesn't fail: bad results trigger reformulated queries; persistently thin results trigger a source-type switch - if press coverage has nothing, try job postings; if job postings are quiet, try filings. The agent behaves like a researcher who hits a dead end and tries a different door, instead of a script that hits a dead end and files an exception.
Real numbers
- ~50-60% runtime reduction from replacing fixed iteration counts with evidence-gated termination.
- 40 tool calls was the old fixed budget; well-covered accounts now finish in 12-15.
- Three loop states - SEEDING, ENRICHING, SUFFICIENT - with reformulation and source-switching on failure, so a bad source degrades the plan instead of the run.
- Hard caps remain as backstops: turn limits and dollar budgets, per run, always.
Where the humans sit
Humans define what "sufficient" means - the dimensions that matter and the evidence bar per dimension are product decisions written down by people, reviewed like code. The agent applies the definition; it doesn't get to invent its own standard of done. And when a run exhausts its backstop caps without reaching sufficiency, that's an escalation with a narrative, not a silently thinner brief.
Steal this
Look at whatever loop your agent runs today and ask what the exit condition actually is. If it's a number, you're paying for redundant work on easy inputs and truncating hard ones - the worst of both. The refactor is usually small: your agent almost certainly already tracks something that approximates coverage; promote it from logging to loop condition. Then make failure a state transition instead of an exception. Neither change touches your prompts. Both change your cost curve.
Next week in the build track: the trust stack - budgets, scope guards, and the right to say no. Then back here: which model each job deserves, and the 49-minute job we fixed in an afternoon.
This post is part of the product track of How a Tiny Team Ships Like a Big One, a series on how six builders run a production AI company. Building at Aithon - if this is how you want to work, talk to us.