What Causes an AI Agent Planner to Repeat Steps It Already Completed?

An agent planner repeats completed steps when execution evidence is missing, ambiguous, forgotten, or excluded from the state used for replanning.

A home AI agent may create a folder, verify it, and then create it again several turns later. The tool can return partial success, the checkpoint may omit completion, or context compression may remove the observation while preserving the original plan. After a timeout or restart, the planner sees an unmet goal and rationally schedules the same step from incomplete state.

Completion Exists in the World but Not in Durable State

An action can succeed while the process crashes before recording its result. In-memory checklists disappear on restart, and separate planner and executor stores may update non-atomically, leaving the plan marked pending. This distinction remains visible during later household testing.

An overview of durable agent state explains why external durable state is required for resume, audit, and long-running work. The signature is a completed tool side effect paired with an absent or older checkpoint. The intermediate result must remain inspectable before automation follows.

Persisting prose memory is weaker than recording a stable step ID, action digest, result, and committed status. The planner needs machine-checkable completion, not merely a prior sentence saying done. That boundary should be measured separately under realistic operating conditions.

Ambiguous Tool Results and Context Loss Hide Progress

Tools may return partial success, asynchronous job IDs, empty output, or a timeout after committing. The harness can truncate, summarize, mislabel, or fail to attach that observation, so the next model call receives the plan without decisive evidence.

A guide to repeating agent actions identifies repeated action as a core failure when the agent loop stops making progress. The useful diagnostic is whether the latest planning context contains normalized success evidence and changed world state.

If the model receives clear completion state and still repeats, planner reasoning or task decomposition is responsible. If the evidence never reaches it, changing prompts cannot repair the data path. The practical consequence appears when several sources compete for limited context.

Retries and Replanning Can Duplicate Non-Idempotent Work

A generic retry policy may repeat the whole step after a transport failure, while replanning generates a semantically identical action under a new step ID. Weak stop conditions allow the loop to continue after the goal is already true.

The reasoning and action feedback pattern alternates reasoning, action, and environment observation so later decisions can use tool evidence. Repetition appears when that feedback or termination test is incomplete. This dependency should remain explicit in the final interface.

The failure boundary is an intentional verification step or idempotent reconciliation. Re-reading state is not duplicate work; repeating a charge, deletion, message, or irreversible mutation without new evidence is. The result must therefore be checked against the original evidence.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Audit Step Identity, Evidence, and Stop Conditions

Trace plan version, stable step ID, action digest, precondition, tool-call ID, idempotency key, start and commit times, raw result, normalized status, checkpoint version, context inclusion, retry reason, replan mapping, world-state verification, and termination decision. This distinction remains visible during later household testing.

Compare the pattern with agent loop diagnosis. Simulate success followed by lost response, partial success, restart before checkpoint, context compaction, and a completed goal with one stale pending step. The intermediate result must remain inspectable before automation follows.

Pass when recovered agents reconcile world state before mutation, reuse idempotency keys, map replanned actions to prior steps, and stop when goal predicates are satisfied. Limit retries and require approval before repeating non-repeatable actions. That boundary should be measured separately under realistic operating conditions.