An agent hits its step or time budget: how do you distinguish partial work from success?

Define task success separately from loop termination

This applies when an interface says “finished” without a report or tools continue writing after the agent stops. Preserve one run and locate termination during planning, execution or result assembly. Define a real completion condition, such as an existing file with correct fields, rather than equating loop exit with success.

Check step counting and cancellation semantics

Check whether a limit counts model turns, tool calls or all messages; the same number means different things across frameworks. Establish whether a time limit cancels an active action or only prevents the next turn. Mark missing tool results as unknown rather than unexecuted, and do not retry them indefinitely.

Stop scheduling while preserving recoverable results

Check budgets before starting each action. Stop scheduling at the limit and retain completed results. Give individual tools separate timeouts and cancellation mechanisms; if cancellation is unavailable, record and query their state. Report partial completion or pending confirmation explicitly and resume from verified state instead of executing everything again.

Verify that a budget stop does not repeat actions

Test normal completion, a budget stop and a tool that never returns, comparing reports with actual artifacts. No new tool should start after the limit, and recovery should not unintentionally repeat executed actions. Mark success only after checking the target result rather than accepting the model's final claim of completion.

Orchestration libraries differ in termination and cancellation behavior, so iteration counts are not portable product settings. This page runs no real agent or external-write test. Stateful tools still require server-side idempotency and status queries during recovery; more budget cannot repair invalid arguments or missing tool feedback.