Skip to content
OperateAgentic

HomeGuidesBuild AI

Guide · Build AI

Shadow-mode pilots in one to two weeks

How to test AI on a real workflow safely. Keep the current process running, compare the AI’s drafts against it, and review anything before a customer sees it.

3 min read

Spectrum Warm guide frame with a butter underline and a four-step path.

A shadow pilot means doing the work twice on purpose. Your current process keeps handling the job while the new process produces a draft alongside it, and then you compare the two. There’s no need to shut off the old way to show you’re committed. The method is the same whether you’re testing a workflow for a whole team or for your own job.

Set the dates before you start

Pick a start date and a decision date and write them down. If the workflow happens every day, one week is usually enough. If it only comes up a few times a week, give it two. Much longer than that and the pilot tends to turn into standard practice without anyone deciding it should.

Next to the dates, write down three things:

  • What success looks like, in words a coworker would understand.
  • What would make you stop early, even if people are enjoying it.
  • The name of the person who’ll review the drafts.

These are also on the pilot checklist. If your decision date is “whenever we feel ready,” go back and pick a real date.

Run it next to the current process

Each time the job comes up, you’ll end up with two things: the finished work done the usual way, and the AI’s draft. Keep them somewhere you can open both. A shared folder with dates in the file names works fine, and you don’t need a new platform for this.

Recording the comparison shouldn’t turn into a research project for the person doing the job. If it takes longer than the task itself, record less. A quick note per instance is enough: usable as-is, usable after edits, or rejected.

During the shadow, the draft shouldn’t send itself, file itself into your system of record, or talk to a customer. Once it starts doing those things you’re in a rollout, and a rollout comes after the decision. The adoption guide covers that part.

Make the review step obvious

The review step needs a specific person and a specific moment, something like “Alex reads the draft before it goes out.” “The team will look at it when they get a chance” doesn’t count.

Tell Alex what to check for: facts that have to match the source, a tone you’d use with your own customers, and anything that should never be guessed at. Make it clear they can reject a draft without justifying it at length. A one-line reason like “wrong address” is far more useful than a paragraph of apology.

If reviews start turning into rubber stamps because the week got busy, pause the pilot. Otherwise the team starts treating the draft as the finished work, which is the opposite of what you’re trying to test.

Compare the results and decide

On the decision date, read the notes before you ask for anyone’s opinion. Count up, in the simplest terms, how many drafts were usable as-is, how many needed edits, and how many were rejected. You’re not writing a case study. You’re deciding whether this becomes part of next month.

Then keep it, revise it, or stop. Revising means changing one thing and running a shorter second round with the same tool. If you stop, write down why, so nobody buys the same product again next quarter after seeing the same demo.

Afterward, you can talk about what you saw: the drafts, the edits, and the misses. What you shouldn’t do is claim a savings figure you never measured. What to measure without fake ROI goes into this in more depth.

Once you have results and want a second opinion on whether the workflow should become a proper system, fill out the evaluation prep sheet and book a Free AI evaluation. Your comparison notes will be the most useful thing you bring.

Tried this, or doing it differently? Talk about this guide with other members.

Keep going