AI-agent failures persist as state across long workflows

AgentBench evaluated twenty-nine API-type and open models across eight environments including OS, database, web, shopping, knowledge graph, home environment, games, and reasoning, reporting that long-horizon reasoning, decision-making, and instruction following are major failure factors, in addition to the gap between top commercial and open models. [1]

In text generation, incorrect answers can be rejected and the task ended, but agents leave incorrect search queries, reservations, sends, and updates as the next state; even if each intermediate response is natural, it is a failure if the final database state differs from the objective, so the evaluation unit must be expanded from a single conversation turn to initial state, operation sequence, final state, and reversibility.

Define state conditions that must hold before and after each process; for example, if the target record, permissions, amount, or destination do not match the planned difference, do not proceed to the next operation; treating it as a failure if state conditions are violated despite correct linguistic explanation, and separately recording insufficient observation, planning errors, tool arguments, and tool-side failures allows verifying alternative explanations beyond model capability. [1]

WebArena evaluated long-horizon tasks in functional web environments such as e-commerce, message boards, collaborative software development, and content management; the terminal success rate of the best GPT-4-based agent in the original paper was 14.41%, significantly lower than the human rate of 78.24%. [2]

This gap is not a ranking of current model capabilities. The important distinction is that success was judged by whether the site state and responses met the intended conditions, rather than by the plausibility of the text. [2] For your own acceptance tests, we propose checking whether orders, permissions, amounts, and records reach the intended final state, alongside click counts and successful tool calls.

Before implementation, conduct shadow operations using the same screens and APIs as production without confirming changes, comparing planned operations with human actual operations; distinguish cases where tool calls succeeded but the terminal state differed, and cases where the correct terminal state was reached by chance but included unnecessary operations; until representative processes pass the same verification rules as human procedures, do not shift to autonomous execution even if the environment is similar. [2]

τ-bench evaluated dialogue with simulated users, business policies, and API operations simultaneously in two domains, retail and aviation; even function-calling agents including GPT-4o at the time had less than 50% success, and pass^8 (success in all eight attempts) in retail was less than 25%. [3]

If the same request yields different results in production solely due to differences in expression or conversation order, operations will not be stable even with high average success rates; iterate by varying paraphrasing, information presentation order, and intermediate confirmation questions for representative cases, not just running them once; in addition to success rate, use metrics for full success across all trials, zero critical failures, unnecessary operations, and rule violations.

The pass condition for reproducibility is not just average success, but that critical failures do not recur with paraphrasing or changes in information order for the same objective; if failures concentrate on specific expressions, suspect input understanding; if they increase with longer conversations, suspect state retention; if they increase at the same stage, suspect tool boundaries; for cases where results fluctuate during iteration, revert to approved paths or manual processing until stable. [3]

WebArena's judgment of success by terminal state and τ-bench's handling of iterative success provide grounds for including the possibility that processing remains partial in the real environment even if the conversation is complete. [2] [3] In business, reconcile executed, unexecuted, duplicated, and pending cancellation items by process, not just overall success or failure of the request, and record confirmation timestamps.

The reconciliation record documents, under one execution ID, the planned operations, actual tool responses, external state confirmation, handover to subsequent processes, and remaining side effects; do not confirm if the external state cannot be verified even if the tool returns success, and do not proceed to re-execution if the response is interrupted but the state is already updated; cases where response and state contradict are routed to humans, and the procedures used for state verification are version-controlled.

As a virtual example, if only the notification fails after reservation creation, re-executing the entire request from the beginning may cause duplicate reservations; separate the reservation as confirmed and the notification as incomplete, and choose from the reconciliation record whether to resume only the notification or cancel the reservation and revert the entire request; do not use natural completion statements as proof of success, and also record the reason for the choice.

Define for each process from where re-execution is possible: before processing starts, after external updates, or after handover to subsequent processes; for each re-execution point, link already confirmed operations, operations allowed for re-execution, identifiers for detecting duplicates, and cancellation methods; if the state is unknown, stop automatic re-execution, specify the state to hand over to humans and the responsible confirmer, and define the approver who must cross the point.

If non-cancellable operations are included, do not assume only reversal, but determine compensatory actions accepted as business, such as correction notifications, counter-operations, or adding separate records; test whether the post-compensation state meets the objective and who approves the remaining detriment, do not consider technical error resolution as completion, and set a compensation deadline.

Completion proof includes the final state, unprocessed items, executed compensations, manual handover destination, and restart-prohibited intervals; separately from paraphrase tests for the same request, test conditions where responses are cut off, state confirmation is delayed, or manual intervention occurs, adding only processes that can correctly resume from partial success to the autonomous scope; attach an expiration date to proof of remaining unprocessed items and retain the issued execution ID.

• SETTLE: Reconcile planned, executed, unexecuted, duplicated, and pending cancellation items.
• CHECKPOINT: Fix re-execution points and confirmed external states.
• COMPENSATE: Determine compensatory actions and remaining detriment when cancellation is impossible.
• CERTIFY: Retain unprocessed items, handover destinations, and restart-prohibited intervals in the completion proof.

Divide implementation candidates into read-only, draft, reversible updates, and updates involving money, permissions, or external sends; limit the initial stage to reading and drafting, and display the current state and planned difference before operations; set limits on permitted tools and arguments for high-impact operations, and require human approval immediately before execution and state verification after execution.

Logs retain the user's objective, referenced rules, inputs and outputs of each tool, state differences, and reasons for suspension; in case of failure, classify where the breakdown occurred—insufficient observation, planning, rule search, argument generation, tool, or confirmation—rather than blaming the model alone; before increasing the automation rate, passing stop, cancellation, and manual handover tests is the condition for safely handling long processes; furthermore, leave the grounds required for the approver's judgment on the screen and evaluate without counting perfunctory approvals as success.

Place the owner of the autonomous scope for each business process, preventing technical teams from expanding it alone; the business owner defines the acceptable final state and impact, the system owner guarantees permissions and cancellation methods, and the quality manager maintains failure samples; operations that cannot be cancelled, results that cannot be verified, and operations where approval grounds cannot be displayed are returned outside the automation scope regardless of the automation rate.

• Start condition: Mechanically verify initial state, objective, permitted tools, and prohibited operations.
• Continuation condition: Proceed to the next process only if the state after each operation matches the planned difference.
• Approval condition: Present the target, difference, and grounds to humans for external sends, money, and permission changes.
• Stop condition: Hand over to manual if there is a state mismatch, rule conflict, inability to cancel, or inability to verify.