When an AI agent keeps working but gets nowhere

The screen says the agent is still working. It has searched the same folder, rewritten its query and opened another document. The person waiting for the answer cannot tell whether it is making progress or going round again.

For an operator, this is unfinished work with a growing cost. Before giving an agent more tools, agree how much work it may do on one case and what happens when that allowance runs out.

Define finished before defining the budget

Consider a hypothetical maintenance business using an agent to prepare a job brief. The agent must find the correct site, identify the reported fault and attach the current equipment record. A dispatcher approves the brief before allocating a technician. This is a design example, not a reported client deployment.

A finished brief needs all three inputs, their source references and the dispatcher's acceptance. Producing a plausible paragraph is not the completion condition.

Now suppose the customer has two sites with similar names and the enquiry does not identify which one needs service. More searching may reveal more documents without resolving that ambiguity. The useful next step is a clarification request prepared for the dispatcher, with the two candidate sites shown.

Write down that distinction. A temporary failure to load a known record may justify a bounded retry. A missing customer answer requires information. Conflicting evidence requires a decision. None should become an open-ended instruction to keep trying.

Give the case a budget that survives a restart

Use one case identifier from intake through final resolution. Attach the allowance and accumulated usage to that case, not just to the latest agent run. Otherwise, a restarted job or a second agent can appear to begin with a fresh allowance while the business is still paying for the same unresolved task.

A practical control sheet should specify:

• Completion: the evidence required to accept the result.
• Spend: the allowance for model usage and any paid tools, including delegated work.
• Elapsed time: how long the case can remain with automation before someone must intervene.
• Attempts: which operations can retry, how often and under what conditions.
• Progress: what new evidence or completed step would justify continuing.
• Ownership: who receives a stopped case and how soon they must review it.

Enforce these controls in the workflow that schedules calls and records actions. A sentence in the agent's instructions asking it to be economical is not an enforceable spending limit.

Check the remaining allowance before starting another paid operation. If several workers share the case, reserve allowance before dispatching them so they cannot each spend the same remaining amount. Reconcile estimated usage with actual charges when available. Where a provider cannot give a firm maximum cost for an operation, leave headroom and describe the limit as approximate rather than promising an exact ceiling.

Stop on lack of progress as well as cost

A case can waste a dispatcher's afternoon without running up a large model bill. That is why spend alone is an incomplete control.

For the maintenance brief, useful progress could mean resolving the site identifier, locating the equipment record or obtaining the missing fault description. Rephrasing an answer without adding evidence does not count.

Agree a small set of stop reasons that the dispatcher can understand: missing input, conflicting records, unavailable system, allowance reached or approval required. Keep the original reason when the case is resumed. If a human supplies the missing site identifier, the resumed attempt should use it rather than replaying the entire search.

For genuine system failures, use a separate automation recovery process. Increasing a task budget will not repair a broken integration.

Make stopping leave the work in a usable state

A stopped task should arrive with a handoff, not just an error message. Include the original request, verified facts, unresolved question, sources consulted, usage so far and the next decision needed. Show any action already attempted and whether its result is confirmed.

That last field matters even when the agent mainly prepares information. If it also submitted a draft job to another system and the response timed out, stopping the agent does not prove that no draft was created. Check the destination before allowing a replay. The approval boundary for AI record changes still applies when an allowance is exhausted.

Allow an authorised owner to extend a budget when there is a reason to expect useful progress. Record the extra allowance and reason against the same case. “Try again” without new evidence should not quietly reset all counters.

Also decide what the waiting person sees. A clear status such as “Waiting for dispatcher to confirm site” is more useful than a permanent spinner or an unsupported promise that the job is nearly done.

Test limits with deliberately awkward cases

Before rollout, run a controlled set of cases through the whole workflow:

1. A complete request finishes within the allowance and passes the acceptance check.
2. A missing site identifier produces a specific clarification handoff.
3. The same unhelpful search result repeats and triggers the agreed progress stop.
4. Two workers request the remaining allowance at once; the shared budget is respected.
5. A restarted task retains its earlier usage and unresolved questions.
6. A timed-out write is reconciled before any repeat action.
7. The shared daily budget is reached; new work queues or routes to the agreed fallback without disappearing.

Inspect the task record and the recipient's queue for each case. A stop rule is incomplete if it halts computation but leaves nobody responsible for the customer's request.

Review the expensive tail, not just the average

A hypothetical batch has 90 accepted briefs costing ₹2 each in direct usage and ten unresolved briefs costing ₹25 each. Direct usage totals ₹430. Dividing that by the 90 accepted briefs gives about ₹4.78 of batch usage per accepted brief, before human review, infrastructure or recovery costs. Reporting only the ₹2 successful-case average hides the unsuccessful attempts.

These are illustrative numbers, not prices or a savings forecast. Keep unresolved cases visible, and add the dispatcher's review and recovery time to the operating-cost picture. Report completion rate, stopped-case age and the most expensive cases alongside the average. A lower bill achieved by abandoning useful work is not automatically an improvement.

Use those observations in the automation ROI review. Tighten the scope when a certain task repeatedly needs clarification. Adjust limits when valid cases are being cut off. Fix the underlying source or integration when extra attempts produce no new evidence.

For a workflow review with SolvTree, bring one accepted task and one task that kept running without a result, with sensitive details removed. The useful starting question is concrete: what should have told the workflow to stop, and who should have received the work next?