When should an agent stop?

Agents and limits — 09

When an agent cannot finish a task, the first thought may be to give it a little more time. One more tool call, another attempt, a stronger model…

Sometimes continuing helps. Sometimes we surround the same uncertainty with more processing. The system keeps moving, but we cannot tell whether it is getting closer to solving the task.

Working on a2, stopping therefore becomes a design question in its own right:

What grounds should we have for taking the next step?

The answer varies with task completion, available resources, the evidence at hand and the agent’s authority.

Does producing an answer finish the job?

Consider a hypothetical data-matching task. Records in two files must be combined, unmatched records separated and conflicts preserved.

When the agent produces output, a readable file passes an initial check. Having the expected fields in the expected format is another check. But if the wrong records have been joined, the task has still not been done correctly.

This is why a2 separates output validation from comparison against an independent expected result. If a reference answer is supplied, the result can be tested against it. A format-only check does not establish that the task was solved correctly in meaning.

The stopping decision needs to carry this distinction too. A final answer from the model may mark the end of execution. Accepting the work requires us to know which checks it passed.

Keeping invalid outputs out of successful-result memory is one of a2’s mechanisms for maintaining that boundary.

When does repeating an action make sense?

The agent called a matching skill and received an error. It proposed calling the same skill again with the same inputs.

What will change on the second attempt?

A temporary connection failure may justify a retry. But repeating the same transformation on the same data will not supply a missing matching rule by itself.

In a2’s data run path, a skill invocation with identical arguments is limited to one by default. An attempted repetition stops the run before another model request. Failed invocations count towards this limit too.

The same skill can be used with different inputs. The repeat limit can be explicitly increased. This is not a general rule applied across every a2 workflow; it belongs to a particular execution path.

What I find valuable here is that repetition is not an automatic entitlement. The grounds for another attempt need to be visible.

Even so, this mechanism does not measure the agent’s entire progress. Returning to the same point through different wording or different tools is a broader problem. The repeat limit catches only one particular form of it.

When the resource limit arrives

Resources allocated to a run can run out while the task remains unsolved.

In a2, the step limit bounds the loop. When a token budget is configured, the parent agent and its child agents share one usage ledger. Delegating work does not restart the budget. Previous usage is also preserved when resuming from a checkpoint.

The token limit is soft: a single response can exceed the remaining budget. The mechanism blocks subsequent requests after usage is recorded. It should therefore not be presented as an exact spending ceiling.

There is also the case of unknown usage. When the provider omits usage information or supplies invalid information, further requests stop under a configured budget.

The reasoning is simple: if I do not know how much has been spent, I cannot reliably calculate what remains.

A run stopped by its budget should not count as completed. The reason for stopping should remain alongside any partial result.

When we do not know whether an action happened

Sometimes stopping concerns uncertainty about what happened outside the agent more than resources.

Suppose a tool call that modifies a file has started. The process is then interrupted. We have no record confirming that the action completed.

Running the same call again may look straightforward. But the action may have happened the first time. A retry could produce a second modification.

a2’s checkpoint mechanism leaves a pending-action marker before tool operations. Resuming from such a checkpoint does not automatically replay the uncertain action; the run stops for review.

This does not guarantee that every action happens exactly once. It limits automatic continuation when the state is uncertain.

A similar distinction applies to authorization. Gate can block an action that requires approval when that approval is absent. Blocking an action and stopping the whole task are different things. The agent may proceed through another permitted route, but it should not use a different tool to circumvent missing approval.

When we cannot find a supported path

A request for a task does not mean the available skills can fulfil it.

In a2’s planning path, the model can return an empty plan when the listed contracts cannot meet the goal or the request is ambiguous. No executable plan file is saved; the run stops with a report that no supported plan was found. The model call and tokens already consumed are still counted.

The limitation matters here too: this is not a mechanism that deterministically recognizes every unsupported task. The model may propose a wrong plan; even a plan satisfying structural constraints may misinterpret the goal.

Producing a plan and finding a path suited to the goal therefore require separate checks.

“I cannot proceed with the current tools” becomes useful when it also shows what is missing: a matching rule, required data, an appropriate skill, or authority?

What should remain after stopping?

a2’s current mechanisms break this question into parts: step limits, a shared budget, blocking certain repetitions, review of uncertain actions and output validation.

They do not show that the agent stops at the right time in every situation. a2 remains in development alpha; this essay presents no new performance evaluation.

The question still open for me is what these parts leave the user with.

Where did the run stop? Which action happened? Which action remains uncertain? What checks did the remaining output pass? What needs to change before continuing?

If those questions can be answered, the stopped work can be taken up again. Missing data can be supplied, authority granted, a rule corrected, or another method chosen.

Where an agent stops, I want it to leave a trace clear enough for a person to continue.

---

Source note — 15 October 2026: This essay draws on a2’s existing code, README, architecture and technical specification. The data-matching and interrupted file-operation examples are hypothetical. No new model call or evaluation run was conducted for this essay.

a2 project page · An idea becomes a working tool

Previous essay in the series: Building a photographic series.