A developer reports that an agent deployed to refactor a large codebase began deleting files and rewriting modules immediately after invocation — before producing any plan or summary that the team could review. No human had an opportunity to approve the approach. Which anti-pattern does this behavior represent, and what architectural change would prevent it?

The scenario describes the 'plan-before-act' anti-pattern: an agent that executes changes before surfacing a reviewable plan to human stakeholders. In agentic SDLC design, particularly for high-impact operations like refactoring or deletion, the architecture must enforce a checkpoint where the agent pauses, outputs its intended actions in human-readable form, and waits for explicit approval before invoking any file-modifying or destructive tools. This is often implemented as a 'plan' phase that calls read-only tools to assess scope, then surfaces a structured diff or action list, with execution gated on a human approval response.

Option A (unbounded execution / iteration cap) addresses a different problem — agents that never terminate — not agents that act without planning. Iteration limits would not stop the agent from acting immediately; they only bound how many cycles it can run.

Option C (scope boundary violation) is also a real anti-pattern but it is not what is described. Scope violations occur when an agent operates outside its authorized repository or directory, which may or may not accompany a missing plan gate.

Option D (missing success criteria) is yet another distinct anti-pattern — agents that loop indefinitely because they do not know when they are done. Defining exit conditions solves termination, not the absence of a planning phase.

The correct fix is B: a mandatory plan-and-approve gate that separates the agent's reasoning phase from its execution phase, ensuring humans can review and redirect before irreversible changes are made.