Why your agent edits files you never asked it to touch.

You asked the agent to update one function. It updated the function, refactored a utility file two directories away, renamed a constant that four other modules import, and left your test suite broken.

Nothing in your request mentioned those files. The agent did not misread your intent. It read it correctly, then went further, because nothing told it where to stop.

This is a recurring failure mode engineers hit in production agentic AI: scope creep. Not the project-management kind. The kind where your coding agent treats "fix this" as permission to improve everything adjacent to it, and you spend the next two hours untangling changes you never asked for.

The instinct is to add more detail to the prompt. That does not fix it. The problem is not missing information about what to do; it is a missing policy for what to do when the task is ambiguous at the boundary. That policy has a name: the Fallback Cascade.

A Fallback Cascade is a tiered policy that specifies what the agent does at each level of scope ambiguity. It replaces the agent's default binary choice, execute or refuse, with four graduated responses:

Tier 1: Refuse. The request is clearly outside the defined scope. The agent does not attempt it. It states what is out of scope and why.

Tier 2: Narrow. The request is partially in scope. The agent completes the in-scope portion, flags the out-of-scope portion, and stops. It does not decide the out-of-scope work is close enough to proceed.

Tier 3: Confirm. The request is ambiguous at the boundary. The agent does not guess. It stops, describes the ambiguity, and asks a single, specific question. It does not list options; it surfaces the decision.

Tier 4: Execute. The request is unambiguously within scope. The agent executes without interruption.

Without this policy, an agent's default behavior trends toward Tier 4. In current training regimes, task completion is heavily rewarded; hesitation is underrepresented. The model's prior is to execute. The Fallback Cascade overrides that prior with an explicit, inspectable policy.

A deployable Fallback Cascade block for a coding agent system prompt:

The last line is the load-bearing piece. A Fallback Cascade without a defined scope is a procedure without a subject. The cascade tiers are the policy; the scope definition is what the policy operates on. Both are required.

A concrete sequence from a common pattern.

Run 1: no cascade, no scope definition. The engineer asks the agent to "clean up the error handling in the payments module." The agent rewrites the error handler, extracts a shared utility, updates the utility's import across five files it located through static analysis, and renames two error types for consistency. The intent was one module. The agent scope crept across six files. Rework: most of an afternoon.

Run 2: scope definition added, no cascade. Same request, same agent. This time the system prompt defines scope as src/payments/. The agent stays in the directory but interprets "clean up" as license to refactor the entire module: new abstractions, renamed functions, restructured imports. Still not what the engineer wanted. The scope definition contained the blast radius but did not control the depth of action within it.

Run 3: scope definition plus Fallback Cascade. Same request, same agent, Tier 2 and Tier 3 active. The agent cleans the error handler as requested, then stops. It flags that it identified a shared utility pattern that could be extracted but that this action would modify files outside the immediate request. It asks: "Should I extract the shared utility as a separate task?" The engineer says no. Two minutes of review. Done.

The difference between Run 2 and Run 3 is not more constraint on what the agent can touch. It is a policy for what the agent does when it reaches the edge of the specified task. Run 2 has a fence. Run 3 has a fence and a procedure for what happens when the agent reaches it.

The Fallback Cascade is a tiered policy specifying what an agent does at each level of scope ambiguity: refuse, narrow, confirm, execute. It is the architectural answer to the failure mode "agent edited files I did not ask about."

In use: "The scope creep incident happened because we had a workspace boundary but no Fallback Cascade. The agent reached the edge of the task and defaulted to its own judgment."

Where it does not apply: tasks with unambiguous, atomic scope. If the request is "change the value of this constant from 30 to 60," there is no boundary ambiguity and no cascade needed. The Fallback Cascade earns its overhead on tasks that involve exploration, refactoring, or multi-file operations, where the agent will inevitably encounter decisions that were not anticipated in the original request.

The Fallback Cascade handles ambiguity. Its companion term handles risk.

A Circuit Breaker is a binary policy specifying that certain operations require explicit unlock phrases before execution. Where the Fallback Cascade governs the agent's response to uncertain scope, the Circuit Breaker governs the agent's response to high-consequence actions: deleting files, pushing to production, dropping database tables, calling external APIs with write access.

The two policies are complementary, not redundant. A Fallback Cascade without a Circuit Breaker allows the agent to reach Tier 4 on a destructive action if the request is unambiguous. A Circuit Breaker without a Fallback Cascade stops destructive actions but leaves the agent free to accumulate low-consequence scope creep across dozens of files.

Production-grade AI coding agent guardrails require all three: the cascade for ambiguous scope, the breaker for high-consequence actions, and a defined workspace that both policies operate against. Together, they transform the agent from a system that executes until stopped into a system that executes within bounds and escalates at boundaries.

One thing to try this week. Open the system prompt for the AI coding agent you use most. Search for the word "scope" or "workspace." If neither appears, your agent is operating on implicit scope, which means it is using its training prior as the boundary. Add one line — substituting your actual directory for [PATH]: "Your workspace is [PATH]. Do not modify files outside it." Then add Tier 3 from the cascade above (the Ambiguous tier: if you cannot determine whether an action is in scope, stop before taking it and ask one specific yes/no question). Those two additions address a common source of AI agent scope creep without changing anything else.

Next week: the prompt that looks complete but fails silently. You have written its guarantees, confirmed its output format, and added a schema. It still produces wrong answers, and the wrong answers are confident. The failure has a name; its diagnosis requires one specific term from the vocabulary. Take a guess at what breaks a prompt that appears structurally sound.

- The Constraint

Read the Method · Get the Agent Control Architecture Pack