Migrating a Finance Workflow onto Claude Agents Safely (Verifiable AI Financial Services)

The riskiest moment in any agentic project is not building the agent. It's the day you point it at a workflow that already works and let it take over. That existing reconciliation process or payment-approval queue has years of edge cases baked into it — the manual exception some analyst handles every quarter-end, the override that only happens for one counterparty, the validation step that exists because of an incident nobody documented. A Claude agent that's 95% as good as that process is not a 95%-ready replacement; the missing 5% is precisely the institutional knowledge that keeps money from going to the wrong place. Migration done safely is the discipline of finding that 5% before it finds you.

The way you do that is staged. You don't flip a switch from human to agent. You move through phases — shadow, assisted, canary, scaled — where the agent's authority increases only as the evidence justifies it, and at every phase you keep a fast path back. This post is the rollout plan: how to run each stage, what signal graduates you to the next, and the rollback you build before you need it.

Start by mapping what already exists

Before the agent touches anything, document the current workflow as it truly runs — not the flowchart in the wiki, but the real thing including the undocumented exceptions. Walk it with the people who operate it and ask specifically about the weird cases: when do they override the default, when do they escalate, what makes them stop and check. Those answers become two things at once: the system prompt and tool design for the agent, and the edge-case bucket of your eval set. A migration that skips this step is building an agent to replace a process it doesn't actually understand.

This is also where you decide the boundary of the agent's authority. The safest migrations don't hand the agent the whole workflow on day one — they carve out the read-and-propose part (classify the transaction, draft the reconciliation, propose the payment) and leave the commit part to a gated step. That split lets the agent demonstrate competence on the reasoning without yet owning the irreversible action, which is exactly the property you want during rollout.

Phase one: shadow mode

In shadow mode the agent runs on real production inputs and produces real outputs — which go nowhere. The existing process stays fully in control; the agent's results are logged and compared against what the humans actually did. This is the cheapest, safest way to discover the gap between "works in the demo" and "works on the live distribution," because it runs on the genuine input stream with zero blast radius. Nothing the agent decides takes effect.

What you're measuring is agreement and its absence. Where the agent matches the human outcome, you build confidence. Where it diverges, you have a goldmine: every disagreement is either a real agent error to fix or a case where the agent was right and the process has drift worth examining. Run shadow mode long enough to span the cycles that matter in finance — a full month-end, a quarter-end close — because the exceptions that break agents cluster exactly at those boundaries. The graduation signal is a divergence rate that's low and, more importantly, whose remaining divergences you've explained.

flowchart TD
  A["Map existing workflow + edge cases"] --> B["Shadow: agent runs, output discarded"]
  B --> C{"Divergences low & explained?"}
  C -->|No| B
  C -->|Yes| D["Assisted: agent proposes, human approves"]
  D --> E{"Approval rate high, few corrections?"}
  E -->|No| D
  E -->|Yes| F["Canary: agent acts on small % autonomously"]
  F --> G{"Metrics & safety hold vs baseline?"}
  G -->|No| H["Rollback to prior phase"]
  G -->|Yes| I["Scale share, keep rollback ready"]

Phase two: human-in-the-loop

Once shadow mode says the agent is competent, give it a voice but not a vote. In the assisted phase the agent proposes — drafts the reconciliation, recommends the categorization, prepares the payment instruction — and a human approves, edits, or rejects before anything commits. Technically this is the manual agentic loop with a hard gate on the money-moving tool: the agent emits the tool_use block, your harness routes it to a person, and only an explicit approval executes it.

This phase does double duty. It protects production, because every irreversible action still has a human check. And it generates labeled data: every approval, edit, and rejection is a graded judgment of the agent's work, which flows straight back into your eval set and tells you precisely where the agent still needs the prompt or tools tightened. The signal to advance is a high approval rate with corrections that are minor and shrinking — meaning the humans are mostly rubber-stamping good work, not constantly fixing it. If they're heavily editing, you're not ready to remove them; you're ready to go fix what they keep correcting.

Phase three: canary and scale

Now you let the agent act autonomously — on a sliver. A canary routes a small percentage of real volume fully through the agent while the rest stays on the prior phase, and you watch the canary's metrics against the established baseline: accuracy, the divergence rate from shadow mode, cost, latency, and above all the safety cases. The whole point of a small share is that if something regresses, the damage is bounded and you catch it on a fraction of volume rather than all of it.

The most important artifact of this phase isn't the canary — it's the rollback you built before turning it on. Cutting back to the previous phase has to be a single, fast, well-rehearsed action: a config flag that reverts authority, not a deploy. In finance you want the ability to pull the agent's autonomy in seconds when an anomaly fires, because the cost of letting a regressing agent run on real money for an hour is not symmetric with the cost of an unnecessary rollback. Build that lever, test it, and only then ramp the canary share upward as the metrics hold — and keep the lever live even at full scale, because the workflow you migrated will keep producing new edge cases for as long as it runs.

Frequently asked questions

How long should shadow mode run before I trust the agent?

Long enough to cover the cycles where the hard cases live — at minimum a full month-end close, ideally a quarter-end too, since that's when financial exceptions cluster. Don't gate on calendar time alone; gate on having seen and explained the divergences. If month-end produced a new class of disagreement you hadn't accounted for, the clock resets until you've handled it.

Can I skip straight to canary if my evals look great?

Strong evals earn you a faster shadow phase, not a skipped one. Evals run on the cases you thought to include; shadow mode runs on the genuine production distribution, which always contains surprises your case set missed. Shadow mode on real inputs with zero blast radius is too cheap and too informative to skip — let it confirm what the evals predicted before you grant any autonomy.

What exactly should the rollback revert?

Authority, not code. The rollback should be a configuration change that drops the agent back a phase — from autonomous to human-in-the-loop, or from assisted to shadow — instantly, without a deploy. It should be one action, tested in advance, and triggerable by whoever is on call. Treat it like a circuit breaker: cheap to flip, always within reach, and rehearsed before you ever need it.

Bring a safe rollout to your phone lines

Moving live calls onto an agent deserves the same shadow-to-canary caution. CallSphere rolls out voice and chat agents in stages — observing, assisting, then answering autonomously — so the migration is as safe as the agent is capable. See it live at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.