Designing a progress-aware execution controller for agentic systems.
Imagine asking an AI research agent to compare PostgreSQL and DynamoDB. It finds documentation, collects the important trade-offs, and has enough information to answer.
Then it searches again. And again. Same sources, slightly different queries, more tokens spent.
Now consider the opposite: an agent reaches its step limit one action before completing its work.
Both situations point to the same problem: executing more steps isn't always the same as making progress.
I've been thinking about how I'd design an execution controller that makes stopping a system-level decision, not simply another instruction in the prompt.
Why max_steps = 10 doesn't solve it
Hard limits are essential. They stop runaway loops and cap resource consumption. But a fixed number of turns doesn't tell us whether a task is complete.
A simple lookup might need two turns; a difficult research task might need twenty. A generous limit wastes resources on easy tasks. A tight limit can cut complex tasks short.
The limit should be the safety boundary, not the intelligence behind the stopping decision.
The architecture I'd try
I'd separate the agent from the component that controls its execution.
The agent runtime proposes actions. A policy and budget gate checks them before execution. After a tool returns, a progress evaluator measures what changed, and a decision controller decides what happens next.
The controller tracks three practical signals:
- Completion: Which task requirements have actually been satisfied, with evidence?
- Progress: Did the last action add useful information or just repeat earlier work?
- Budget: How much time, money, and tool usage is left?
For example, three searches returning the same sources with no newly satisfied requirements could be a sign of stagnation. But it shouldn't immediately kill the task; sometimes a different strategy is all that's needed.
Stop, continue, or change course?
I would start with a transparent, rule-based policy rather than making another LLM judge every step.
The outcomes are deliberately different:
- FINISH - all mandatory requirements are verified.
- CONTINUE - useful progress is still being made.
- REPLAN - the agent appears stuck, but another strategy is allowed.
- STOP INCOMPLETE - the budget is exhausted or continuing is unsafe.
I think that final distinction matters. An agent stopping because it ran out of budget should never be confused with an agent successfully finishing its job.
One detail that matters in production
The controller's state should be durable: completed requirements, evidence references, tool history, and consumed budget.
If a worker crashes after spending $0.30 of a $0.50 budget, restarting shouldn't silently reset that budget. And if the previous action changed external state, retries need idempotency or reconciliation-not merely a checkpoint.
For an MVP, I'd use a small agent runtime, PostgreSQL for execution records, and deterministic policy checks. No elaborate distributed architecture unless the workload actually needs it.
How I'd know if it works
I wouldn't assume a smarter-looking controller is better. I'd test three policies on the same set of tasks:
| Policy | Behavior |
|---|---|
| Fixed limit | Stop on completion or at a hard cap |
| Stagnation-aware | Replan after repeated non-progress |
| Progress-aware | Combine completion evidence, stagnation, and soft budgets |
I'd compare verified task success, cost per successful task, latency, and premature stops. The useful question isn't whether the controller reduces calls. It's whether it saves wasted work without making the agent less reliable.
A simple limit might even win on predictable tasks. That's a valid engineering result too.
Final thought
I think the next step for agentic systems isn't just making agents capable of doing more. It's giving the systems around them a better way to decide when more work is useful, when to change strategy, and when to stop.
This is a proposed architecture, not a benchmarked result. I'd like to turn it into a small experiment and see where the simple rules break.
Sometimes better agent behavior means doing less-but doing it deliberately.
Top comments (7)
I'd add a fifth outcome to your four: WAIT. When the policy gate sees an irreversible action, like a delete, a refund or a deploy, the right move is neither continue nor stop. It is to pause and ask a person. In an approval broker I'm building, that pause is bound to the exact request: one approval covers that one request, once, within 10 minutes, so a looping agent can't reuse it for the next call.
Your stagnation signal also has a cheap version at the tool boundary: the same exact request (method, path and body) repeated a few times in five minutes. That trips a breaker with no judge model at all. In your design, does a WAIT pause the budget clock or keep it running?
Great point.
I'd treat WAIT as a persisted state, pausing active execution time while keeping approval expiry and the overall deadline running.
On resume, the exact request and single-use approval must be revalidated.
Agreed. One detail on revalidation: compare the request byte for byte (method, path, query and body), and if anything differs, even one field in the body, the old approval is void and the agent has to ask again. Otherwise an agent can get a yes for one payload and resume with another.
Great, informative article on how to control AI Agent budget/resources while maintaining the quality.
Thanks
Your progress signal could be gamed by a run that never repeats itself. I had a Codex goal-mode run go 4.5 days on 40.8M tokens with no commit and no product code. The stop condition needed a step only I could do, and the rule between iterations was to turn an open requirement into evidence, so it kept writing schemas and histories. Each one was a new artifact, so I suspect a check for repeated work would have let it keep going. After I changed the goal to make working software the deliverable and added a three-strikes rule, the next session made 17 commits.
The line that got me: 'retries need idempotency or reconciliation — not merely a checkpoint.' I've built retry-heavy pipelines where the checkpoint said 'resumed' and the side effect had already fired twice. A progress evaluator tracking repeated-work vs new-work is a much sharper budget than max_steps, which just punishes the hard tasks for being hard. My question is how the controller tells 'stuck in a loop' from 'legitimately slow progress' — same API called with the same arguments is observable, but some loops look like that while making progress. Is the evidence purely behavioral, or does the agent have to self-report?