Why Agents Should Shadow First: Phased Deployment for Core Business

Shadow First to See Real Differences

A procurement assistant may perform well on test materials — identifying missing items, explaining rules, and generating plausible applications — but real tasks involve budget changes, incomplete materials, permission differences, and exception approvals. Instead of granting submit permission immediately, let the agent shadow real business: observe its judgments on controlled real inputs without affecting business operations. The original process continues while the system records how the agent would handle each case for later comparison.

For example, the agent can judge whether materials are complete and which items need clarification. Its suggestions stay in test records; they are not auto-approved or sent to suppliers. The shadow account must not have formal submit permissions, and emails or notifications must not be sent accidentally. Relying only on a prompt instruction like "do not submit" is insufficient.

Shadow running incurs costs: data reads, model calls, and added query pressure. Scope and sampling should be limited, respecting existing data permissions rather than copying all production data into an unmanaged test environment.

Don't Treat Human Answers as Ground Truth

When the agent's conclusion differs from a human's, it does not necessarily mean the agent is wrong. Humans may miss materials or rely on project context not recorded in the system. Comparison must revisit the original evidence: what information each party saw at what time, which rule version applied, and what the final business outcome was. If a human later supplemented materials while the agent only received the initial input, direct comparison is invalid.

Disputed cases should be reviewed by the responsible business person; unclear cases are retained. Deleting disputed samples to improve apparent accuracy discards the very scenarios that need study. After a period of comparison, you can state more concretely: which routine applications can be handled, what exception tasks lack, and which errors would impact business if missed.

Authorization Can Be Phased or Stop at Any Step

Not every task must progress to full automation. Material organization may suit automation, while exception approval may long require human accountability. The following phases define a gradual handoff:

Offline Replay : Process historical or synthetic tasks in an isolated environment. Expand when key paths and known failure scenarios are explainable. Exception handler: development and test leads.

Shadow Running : Observe controlled real inputs; outputs do not participate in execution. Expand after differences are reviewed and samples cover the target business scope. Exception handler: designated business reviewer.

Assisted Processing : Provide suggestions or drafts for human confirmation before execution. Expand when humans can understand and effectively check suggestions, and rework is not pushed downstream. Exception handler: current business operator.

Controlled Execution : Automatically complete clearly authorized low-risk actions. Expand after permissions, result verification, stop and takeover mechanisms are validated. Exception handler: on-duty responder with response arrangements.

Each step forward requires the business owner to confirm risk acceptance and the technical lead to present verification results. In small teams the same person may fill both roles, but accountability must be clear. In the assisted phase, verify that humans actually check suggestions — habitual "confirm" clicks do not count as effective gating. Scope is not just traffic percentage; it includes customer segments, business types, amount ranges, callable tools, and modifiable objects. A few high-risk operations are not necessarily safer than many read-only tasks.

Define Rollback Conditions Before Launch

Expansion conditions are easy to write; exit conditions are often forgotten. For example: unauthorized access, key state unreconciled, or unhandled exceptions — should automatic execution stop immediately? Who decides recovery? Thresholds must be based on business consequences, not a uniform error rate. For unacceptable actions, a single occurrence may trigger pause; for recoverable low-risk deviations, observe trends.

After pausing, in-flight tasks must be handled: stopping new tasks does not mean in-flight tasks have stopped; revoking tool permissions does not undo previous business writes. Define which work waits, which is cancelled, and which needs reconciliation.

Google SRE's canary releases — routing a small fraction of requests to a new version, observing, then deciding whether to expand — offer a useful analogy. However, a submitted purchase order cannot be undone by rolling back the model; business remediation must be arranged separately.

One Pass Doesn't Guarantee Future Validity

Model updates, rule adjustments, tool interface changes, and memory content changes can all alter behavior. Task records must link to these versions to know which combination was validated. After important changes, re-run key regressions, then resume shadow observation or reduce authorization scope as impact warrants. Not every copy change requires starting from zero, but model replacement is not an ordinary config change; old conclusions cannot be blindly reused.

If a task upgrades mid-run, decide: continue with the original model and tool versions, or re-validate and switch. Do not let two segments silently use different rules. However, if permissions are revoked or rules expire, continuing with the old version is not allowed; re-check is mandatory.

Sample size has boundaries. Dozens of error-free runs only prove performance on those tasks; they do not prove rare high-loss risks are absent. For those risks, rely on targeted fault and privilege-escalation tests, plus system-level hard constraints.

Finding that the assistant suits material organization but not yet auto-submission is a useful result — no need to push for full automation. After confirming what it can handle, look back: what business value does taking over these tasks actually deliver?

References

Google SRE Workbook, Canarying Releases:

https://sre.google/workbook/canarying-releases/