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 the failure engineers hit most often 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 reaches an ambiguous boundary. That policy has a name: the Fallback Cascade.
The reflex to add more context is understandable. If the agent went too far, tell it more precisely where to stop. But more context tells the model more about what you want. It does not constrain what the model is permitted to do when it reaches the edge of your specification.
The distinction is the whole game. Elaboration helps accuracy within the specified region. Only a boundary policy contains behaviour at the edge of that region.
Here is the mechanism. A language model generates by sampling from a probability distribution over possible next tokens. Your prompt narrows that distribution. Add a clear target and the distribution tightens around useful outputs. Add the relevant operating context and it tightens further. But if you never specify what the model must do when it encounters an ambiguous next step, that choice stays ungoverned.
In current AI training regimes, task completion is heavily rewarded and hesitation is underrepresented in training data. The model's default prior at an ambiguous boundary is to continue. It interprets "fix this function" as implying "and improve whatever you find while you are in here," because in the training distribution, an agent that keeps making forward progress receives more positive signal than an agent that stops.
You cannot fix this with more words about what to do. You fix it with an explicit policy for what to do at the boundary. That is the Fallback Cascade.
A Fallback Cascade is a tiered policy specifying what an agent does at each level of scope ambiguity: refuse, narrow, confirm, or execute. It replaces the agent's default binary choice between "proceed" and "stop" 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, then stops.
Tier 2: Narrow. The request is partially in scope. The agent completes the in-scope portion, flags the out-of-scope portion explicitly, and stops. It does not decide the out-of-scope work is close enough to include.
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 yes/no question. Not a list of options; the one question that resolves the boundary.
Tier 4: Execute. The request is unambiguously within scope. The agent executes without interruption.
Without this policy, an agent's behavior trends toward Tier 4 by default. The cascade makes the gradient explicit and puts the human in the loop at exactly the right moment: when a genuine decision is required, not before.
Here is a deployable Fallback Cascade block you can paste directly into any coding agent system prompt:
FALLBACK CASCADE
Tier 1 — Out of scope: if the request requires modifying files outside the
defined workspace, do not proceed. State which files are out of scope
and why, then stop.
Tier 2 — Partially in scope: if only part of the request falls within the
defined workspace, complete the in-scope portion only. Explicitly flag
what was not done and why.
Tier 3 — Ambiguous: if you cannot determine whether an action is in scope,
stop before taking it. Ask one specific yes/no question that resolves
the ambiguity. Do not guess. Do not proceed on a charitable
interpretation.
Tier 4 — In scope: execute without interruption.
Scope is defined as: files within [WORKSPACE_PATH]. No other files.The last line is load-bearing. A Fallback Cascade without a defined scope is a procedure without a subject. The four tiers are the policy; the scope definition is what the policy operates on. Both are required.
A concrete sequence from a common pattern, all three runs on the same codebase with the same agent.
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 path across five files it found through static analysis, and renames two error types for consistency with a naming convention from a different module. 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. The system prompt now 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. The scope definition contained the blast radius but did not control the depth of action within it. Still not what the engineer wanted.
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 affect additional files. 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 arrives at it.
This distinction applies at every scale. A fence tells the agent where the boundary is. The cascade tells it what to do when it gets there.
A common objection to adding tiers: "Won't the agent keep stopping to ask permission? I will spend more time confirming than coding."
Tier 3 fires on genuine ambiguity, not on every action. If the request is specific, the agent executes under Tier 4 without interruption. The Fallback Cascade earns its overhead on tasks that involve exploration, refactoring, or multi-file operations, where the agent will encounter decisions that were not anticipated in the original request. On atomic, clearly scoped tasks, the cascade is invisible.
A calibrated Fallback Cascade should generate Tier 3 confirmations on roughly 10 to 25% of requests in normal use. If it never fires, the scope definition is too permissive and the cascade is not engaged. If it fires on more than 40% of requests, the task descriptions are systematically under-specified and the fix is at the request level, not the policy level.
The cascade is not an interrogation. It is a structured handoff: at the exact moment when a human decision is required, the agent surfaces the decision cleanly and waits. Everywhere else, it executes without interruption.
The Fallback Cascade handles ambiguity at the boundary of scope. Its companion term handles a different failure: high-consequence irreversible actions.
A Circuit Breaker is a binary policy specifying that certain operations require an explicit unlock phrase before execution, regardless of how clearly they fall within the defined scope. Deleting files, pushing to production, dropping database tables, calling external APIs with write access: these are actions where the cost of a mistake is asymmetric, and where a clear, in-scope request is not sufficient authorization.
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, none of which individually triggers a hard stop.
A minimal Circuit Breaker block:
CIRCUIT BREAKER
The following operations are locked by default. They require the user to
include the exact phrase "confirmed: [operation]" in their request before
the agent may proceed:
- File deletion (any file): confirmed: delete
- Force push or history rewrite: confirmed: force push
- Database migration with destructive change: confirmed: drop
If the user's request implies one of these operations without the unlock
phrase, stop. State which operation is locked, state the required phrase,
and wait.Production-grade AI coding agent guardrails require both: the cascade for scope ambiguity, the breaker for high-consequence actions. Together, they transform the agent from a system that executes until stopped into a system that executes within bounds and escalates at boundaries.
The Fallback Cascade is one term in a larger vocabulary for containing AI agent behaviour. It sits at the level of scope policy: what does the agent do when it reaches the edge of what was specified?
The Three-Constraint Rule operates one level up: before a request is even sent, make Intent, Context, and Guardrails explicit. The Three-Constraint Rule prevents most failures at the prompt level. The Fallback Cascade handles the failures that reach the boundary anyway, because no prompt fully specifies every edge case.
Together, they cover the two most common causes of AI agent scope creep. Underspecified prompts: the Three-Constraint Rule closes this. Ungoverned boundary behaviour: the Fallback Cascade closes this.
A team that applies both will catch the failure at the right layer for each case: before the request for structural omissions, at the boundary for genuine ambiguity. That is the correct architecture, not a maximally restrictive system that halts on every uncertainty, but a graduated system that applies the right intervention at the right moment.
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 this constant from 30 to 60," there is no boundary ambiguity and no cascade needed. Reserve the cascade for tasks that involve exploration, refactoring, or multi-file operations, where the agent will encounter decisions that were not in the original request.
The full vocabulary for AI agent control, all 25 precision terms, is on the Method page, free and public.
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 an implicit scope, which means it is using its training prior as the boundary.
Add two things. First, one line defining the workspace: "Your workspace is [PATH]. Do not modify files outside it." Second, Tier 3 from the cascade above: "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 the most common source of AI agent scope creep without changing anything else about how you work. The agent continues to execute cleanly on clear requests. At the boundary, it stops and asks instead of deciding on your behalf.
For engineers who want the complete deployable version, 12 system prompts including the full Fallback Cascade and Circuit Breaker, three AGENTS.md templates, and five fully-worked diagnostic rebuilds, the Agent Control Architecture Pack is the architecture you can install today.
The Constraint newsletter ships weekly: one issue, one technique, one precise term. Subscribe free.
All 25 precision terms, the Prompt Maturity Model, and the vocabulary that makes AI agent failures diagnosable.
Read the Method → Subscribe to The Constraint