Diagnose an agent loop that repeats tools and exhausts its budget

Steps 4-11: identical state_version=7, search_ticket(args=A), get_customer(args=B), identical observation hashes
Step 12: update_ticket idempotency_key missing -> timeout
Step 13: planner sees no recorded success and emits update_ticket again with different request ID.

• Stop harmful or wasteful execution before attempting prompt-only improvements.
• Separate repeated read-only planning from ambiguous repeated side effects.
• Use state and observation evidence rather than assuming the model is confused.
• Add deterministic progress and repetition guards outside the model.
• Preserve failed traces for replay without retaining unnecessary customer content.

1. Disable or reduce autonomous execution for the affected workflow and block duplicate side effects.
2. Group traces by workflow version, repeated tool/argument sequence, state version, and observation hash.
3. Identify whether the workflow state changes, observations are stale, or the planner lacks a terminal condition.
4. For side effects, inspect idempotency identity and reconciliation behavior after ambiguous timeouts.
5. Add repeated-state detection, monotonic progress invariants, explicit completion rules, and safe retry policy.
6. Replay representative and adversarial traces, then canary the fix with loop-rate and duplicate-action gates.

def guard_next_step(history: list[Step], proposal: Proposal, budget: Budget) -> GuardDecision:
    budget.require_remaining_step()
    signature = (
        history[-1].state_version if history else 0,
        proposal.tool_name,
        stable_hash(proposal.arguments),
    )
    repetitions = sum(step.signature == signature for step in history[-8:])
    if repetitions >= 2:
        return GuardDecision.stop("repeated_action_without_state_progress")

    if proposal.has_side_effect:
        if not proposal.action_id or not proposal.idempotency_key:
            return GuardDecision.stop("unsafe_side_effect_identity")
        if history_has_ambiguous_outcome(history, proposal.action_id):
            return GuardDecision.reconcile(proposal.action_id)

    if workflow_complete(history):
        return GuardDecision.stop("goal_already_satisfied")
    return GuardDecision.allow()

Online guarding scans only a bounded recent history, so each decision is O(1) with respect to total workflow length. Offline grouping is linear in retained steps plus aggregation cost.

• The same read-only tool call is legitimate after the state or external version changes.
• Different arguments still produce the same observation and no progress.
• A provider timeout is ambiguous even though the local trace records an exception.
• The goal is complete, but the planner has not emitted an explicit finish action.
• A loop signature includes high-cardinality or unstable serialized arguments.

• Repeat an identical read sequence without state progress and require a deterministic stop.
• Repeat the same call after an authorized state version change and allow it.
• Timeout a side effect and require reconciliation before another execution attempt.
• Mark the goal complete without a model finish message and stop anyway.
• Compare the fix on saved traces and enforce a zero duplicate-side-effect gate.

• Raising the step limit makes the incident more expensive without creating progress.
• Changing only the system prompt leaves no deterministic protection against recurrence.
• Treating every repeated call as a loop breaks valid polling or post-change verification.
• Retrying a timed-out side effect as if it definitely failed risks duplicate external actions.
• A loop metric without workflow, state, and tool versions cannot locate the regression.