Migrating a workflow to Claude agents without breaking it (Non Technical PM Ships App)

Greenfield agent projects are exciting and rare. Most of the time the real task is harder and less glamorous: you have an existing workflow that already works — a manual process, a pile of scripts, a queue a human clears every morning — and you want to move it onto a Claude agent without breaking the thing your business depends on. When I migrated my app's intake process from a manual checklist to an agent, the temptation was to flip a switch and replace the old way overnight. Resisting that temptation is the single most important decision in any migration.

Why a big-bang cutover almost always fails

The instinct to rip out the old process and replace it wholesale comes from a good place — you believe in the new approach. But an existing workflow encodes years of accumulated edge cases, exceptions, and tribal knowledge that nobody wrote down. A big-bang cutover bets that your agent handles all of that correctly on day one, with no safety net, on live traffic. It almost never does, and when it fails it fails on real customers while the old process you could have fallen back to is already gone.

A safe agent migration is a staged process that runs the new agent alongside the existing workflow, compares their behavior, and shifts responsibility to the agent only as evidence accumulates that it performs at least as well. The whole philosophy is to make the migration reversible at every step and to let real data, not optimism, decide when to advance. You earn trust in the agent the same way you would earn trust in a new hire — by watching it work before you hand it the keys.

Step one: map the existing workflow honestly

Before any agent touches anything, you have to understand what you are replacing — really understand it, including the parts the official documentation omits. I sat with the person who ran the intake process and watched them do it, and the most valuable discoveries were the exceptions: the cases where they quietly broke the official rules because the rules were wrong. Those undocumented exceptions are exactly what a naive agent gets wrong, so capturing them is the difference between a migration that works and one that erodes quality in ways nobody notices until customers complain.

This mapping also tells you where to draw the agent's boundaries. Some steps are great candidates for automation — repetitive, rule-based, high-volume. Others involve judgment, sensitivity, or rare high-stakes decisions that should stay with a human at least initially. A good migration does not automate the whole workflow at once; it automates the parts that are ready and leaves a clean handoff for the parts that are not.

flowchart TD
  A["Map existing workflow & edge cases"] --> B["Build agent for a narrow slice"]
  B --> C["Shadow mode: agent runs, human decides"]
  C --> D{"Agent matches human on real traffic?"}
  D -->|No| E["Fix gaps, add cases, repeat"]
  E --> C
  D -->|Yes| F["Human-in-the-loop: agent acts, human approves"]
  F --> G{"Approval rate stays high?"}
  G -->|No| E
  G -->|Yes| H["Gradual rollout with fallback & monitoring"]

Shadow mode: let the agent watch before it acts

The first live stage is shadow mode, and it is the safest, most informative thing you can do. The agent runs on real, live inputs and produces its proposed output — but it takes no real action. The existing process still does the actual work; the agent's output sits beside it, recorded for comparison. This gives you something no test set can: the agent's behavior on genuine production traffic, including the weird inputs you would never have thought to put in a golden set, with zero risk because nothing the agent decides actually happens yet.

Shadow mode turned out to be where I learned the most. The disagreements between the agent and the human process were a precise map of what to fix — every divergence was either an agent error to correct or, occasionally, a place where the agent was actually right and the old process was sloppy. I stayed in shadow mode until the agreement rate was consistently high across a meaningful volume of real cases, not until I felt confident. Feelings lie; the comparison data does not.

Human-in-the-loop and gradual rollout

Once shadow mode showed strong agreement, I promoted the agent to human-in-the-loop: now it took real actions, but a person approved each one before it executed. This is the stage where the agent starts actually saving work while a human still owns the outcome. The approval rate became my key metric — as long as humans were approving the vast majority of the agent's proposals with no edits, trust was warranted. When approvals dropped, that was a signal to pause and fix before going further.

The final stage is gradual rollout, never a flip of a switch. I let the agent act autonomously on a small fraction of traffic first — the low-risk, well-understood cases — while keeping the old path available as an instant fallback and monitoring closely. As the agent proved itself on each slice, I widened its remit. Critically, I never removed the ability to fall back. A migration is not done when the agent handles everything; it is done when the agent handles everything and you can still revert in seconds if something goes wrong. That reversibility is what lets you move fast without betting the business.

Monitoring and the long tail after cutover

Reaching full autonomy is the beginning of a new phase, not the end of the project. Real workflows have a long tail of rare cases that simply do not show up in weeks of shadow and rollout, and they will surface in production over months. So I kept monitoring in place permanently: alerts on unusual patterns, periodic review of a sample of the agent's decisions, and the eval set continuously fed by any new failure. The agent that has run cleanly for a month can still meet a genuinely novel input, and you want to catch that the first time it happens, not the fiftieth.

The cultural piece matters as much as the technical one. The people whose workflow you migrated need to trust the agent and know how to intervene when it is wrong. I kept them in the loop on what the agent was handling and gave them an easy way to flag bad decisions back into the eval set. A migration succeeds when the agent is reliable and the team around it is confident — and that confidence is built the same way the technical trust was: gradually, on evidence, with a way back at every step.

Frequently asked questions

What is the safest way to start a migration?

Shadow mode on a narrow slice of the workflow. Let the agent process real, live inputs and record its proposed outputs without taking any action, then compare against the existing process. You get true production behavior with zero risk, and the disagreements tell you exactly what to fix before the agent acts.

How do I know when the agent is ready to act?

When it agrees with the existing process at a consistently high rate across a meaningful volume of real cases — not when you feel confident. Advance through human-in-the-loop, watching the approval rate, before granting any autonomy. Let measured agreement and approval rates, not optimism, decide each promotion.

Should I migrate the whole workflow at once?

No. Automate the repetitive, rule-based, well-understood parts first and leave judgment-heavy or high-stakes steps with a human initially. Roll out gradually, starting with low-risk cases and a small traffic fraction, widening as the agent proves itself. Keep a fast fallback to the old path the entire time.

What should I keep in place after full cutover?

Permanent monitoring, periodic sampling of the agent's decisions, an eval set fed by new failures, and the ability to revert quickly. Rare cases surface over months, and the team needs an easy way to flag bad decisions. A migration is complete only when the agent is reliable and reversal is still instant.

Bringing agentic AI to your phone lines

Moving a phone or chat workflow onto an agent deserves the same staged, reversible care — shadow first, approve next, then roll out. CallSphere brings these migration patterns to voice and chat, so teams can shift call handling onto AI agents safely, with humans in the loop until the evidence says otherwise. 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.