Run the agent in shadow mode before it changes anything

The agent’s diff is the most expensive way to learn what it was planning to do. By the time you see the changes, the agent has already written files, run commands, called tools, and possibly widened its scope along the way. You are reviewing the aftermath, not the intent.

There is a cheaper signal. Run the agent once in shadow mode, where it produces a complete plan but executes nothing. No writes. No commands. No side-effecting tool calls. Then read the plan before you let the agent touch anything.

This is where the two books I keep pairing meet again. Claude Code: Building Production Agents That Actually Scale is about the delivery side: task contracts, plan-first workflows, permission budgets, review packets, and rollback. Securing Enterprise AI Agents is about the authority side: delegated permissions, MCP and RAG boundaries, audit evidence, and policy gates. Shadow mode sits right at the join. If your team owns both sides, the Enterprise AI Agents in Production bundle is the cleaner starting point.

What shadow mode actually is

Shadow mode is a planning pass with the write permissions removed.

The agent runs its full reasoning loop. It reads the codebase, considers the task, and produces a complete plan: which files it would change, which commands it would run, which MCP tools it would call, in what order, and why. Then it stops. Nothing gets written. No state changes.

You read that plan the same way you read a pull request description before opening the diff. Does the scope match the task? Did it reach for files or tools outside the contract? Is the order of operations safe? Did it plan to retry after a denied call?

The plan is a review artifact you get for almost free. The cost is one extra planning pass. The alternative is finding out the agent’s intent from a diff you then have to roll back.

The plan reveals what the diff hides

A diff shows outcome. A plan shows intent, the path it took, and the things the agent wanted to do but could not.

A diff tells you the agent changed a config file. The plan tells you it intended to change three config files, was denied on one, and planned to retry with a different tool. That difference matters. The retry after a denial is scope drift wearing a reasonable excuse, and the diff will not show you the attempt that failed.

A diff tells you the agent called an MCP method. The plan tells you the agent considered calling a second MCP method that reaches production data, and ranked it as a fallback. You do not want to find that out from the logs after a bad run.

The order of operations also lives in the plan, not the diff. If the agent plans to edit a shared helper before running the test suite, that ordering can break other in-flight work. The diff shows two changed files. The plan shows a sequence that creates a problem.

Before the next serious Claude Code run, use the free production checklist to set the scope, the stop conditions, and the approval boundaries before the agent starts planning.

What to check in the plan

Does the file list match the approved scope?
Are there commands outside the allowed set?
Are there MCP tools or methods not in the original contract?
Does the plan retry after a denied action?
Does the plan touch auth, billing, migrations, or policy code?
Is the order of operations safe for concurrent work?
Are there fallback actions that reach wider scope?

That list is the same boundary you would enforce during execution. The advantage of shadow mode is that you check it before the agent crosses the line, not after.

Shadow mode is a trust instrument, not a speed bump

The objection I hear most often is that a planning pass slows the agent down. It does. That is the point, for tasks where the cost of a wrong action is higher than the cost of a second planning pass.

Think about which tasks that covers. A wrong import statement in a new file is easy to undo. A wrong migration run, a wrong deployment, a wrong edit to shared auth config, a wrong call to a billing API, those are expensive to undo and sometimes impossible. Shadow mode earns its keep on the second category. For the first category, direct execution is fine.

The teams that widen agent autonomy safely are not the ones that skip the planning pass. They are the ones that use it on the tasks where it pays for itself, and drop it on the tasks where it does not.

When shadow mode stops being enough

Shadow mode is a training wheel for trust. Over time, as plans consistently match the contract and execution consistently matches the plan, you graduate specific tasks to direct execution. The graduation criteria should be evidence-based: enough clean runs where the plan matched the outcome that you are willing to skip the planning pass on that class of task.

Some tasks should stay in shadow mode permanently. Anything touching auth, billing, migrations, customer data, or production deployments is cheap to plan and expensive to undo. For those, the planning pass is not a training wheel. It is a permanent control.

Scope drift lives in the plan first

Here is where delivery and security stop being separate conversations. The plan shows the agent’s full intent, including the reaches it backed away from. Those reaches are the same scope drift and authority problems I wrote about in the approval boundary post. The difference is timing. Shadow mode lets you see the drift before the agent acts on it. The approval boundary catches it after the agent tries. Both belong in the loop, but the earlier signal is the cheaper one.

Security teams already think this way. A change advisory board reviews a plan before it goes to production. A code review happens before the merge. Shadow mode applies the same principle to the agent: review the intent before the execution, because intent is reversible and execution sometimes is not.

Build plan-first into the loop

If your current problem is the gap between what the agent intended and what it did, start with Claude Code: Building Production Agents That Actually Scale. The landing page routes Kindle readers to the Amazon edition: get the Claude Code book on Amazon Kindle.

If your problem is the authority model around enterprise agents, read Securing Enterprise AI Agents or go straight to Leanpub. It covers delegated authority, MCP and RAG boundaries, audit evidence, policy gates, and incident-ready records.

If your team owns both the delivery loop and the authority model, get the Enterprise AI Agents in Production bundle. One book helps you build agent work people can review before it executes. The other helps you keep the authority behind it honest.