Free checklist and playbook links at the end.
You Bought Copilots. You Sped Up the Person Who Was Already the Bottleneck.
A lot of companies bought AI copilots in the last two years. The pitch was simple. Your people get a helper that suggests code, drafts emails and summarizes documents. They save time on every task.
Here’s the catch. A copilot helps a person do a step faster. But the person still runs the process. They still read the suggestion, fix it, decide and click. If the person was the wait before, they’re still the wait.
That’s my thesis. Most teams bought a helper when the process needed a doer. A helper makes each step a little faster. A doer takes the person out of the steps that never needed them. Those lead to very different results, and most companies are measuring the wrong one, so they can’t see the difference.
Helper versus doer
There are two kinds of AI at work.
A copilot is a helper. It suggests, and then a person acts.
An agent workflow is a doer. It gets a goal and the tools, and it carries out the steps itself. A person checks the result and approves it, or steps in when something falls outside the rules.
Both are useful. I’m not here to tell you copilots are bad. I’m here to tell you they’re the wrong tool for most of the work they’ve been bought for.
A bug fix, done both ways
Here are two made-up examples to show the difference.
With a copilot, a developer gets a bug report. The copilot suggests a fix. The developer reads it, edits it, applies it and runs the tests. If the tests fail, they go around again.
With an agent, the agent gets the bug report. It writes a test that shows the bug, finds the cause, fixes it, runs every test and opens a request to merge the change. The developer looks it over and approves.
In the first case, the developer did every step with help. In the second, the developer made one decision.
A refund, done both ways
With a copilot, a support person opens a refund request. The copilot summarizes the case and drafts a reply. The person reads it, edits it, checks the rules, issues the refund and clicks send.
With an agent, the agent checks whether the customer qualifies, issues the refund, updates the records and emails the customer. A person only steps in when the refund is above a set dollar amount.
Same request. One version needs a person for every step. The other needs a person only for the exceptions.
Why the usual approach fails
Copilots are easy to buy. You hand them out, people try them and most people like them. Nobody’s job changes. Nobody’s process changes. That’s the appeal.
It’s also the problem. If the process doesn’t change, the person is still in every step. And if the person was the slowest part of the process, you’ve made the slowest part a little faster. You haven’t changed the shape of the work.
Think about where time goes in most office work. A lot of it isn’t judgment. It’s moving information from one screen to another. It’s checking a number against a written rule. It’s sending the same email with a different name in it. A copilot makes each of those faster. But a person still has to do each one, in order, one at a time.
That’s the same mistake I see with automation in general. Teams start with the tool, not the work. They ask how much faster the tool can make a step. They don’t ask whether a person needs to be in that step at all.
Change what you count
Copilot teams tend to measure time saved per task. That number can look great while the overall output barely moves, because the person is still doing every task.
Agent teams measure tasks finished per hour. My hunch is that the second number is the one that pulls ahead, because it doesn’t depend on how fast a person can read and click.
If you only track time saved, you’ll keep buying tools that make each step a little faster. You’ll never ask whether the person needs to be in that step at all.
So count both, and count errors too. Measure them before you change anything, so you have something to compare against.
A worked example
Here’s a made-up refund desk at an online store to show the whole method. The numbers are examples, not client data.
The store gets about 400 refund requests a week. One run is one request. The result is a correct refund, the records updated and the customer told.
Today, one person finishes about 6 refunds an hour. That’s about 67 person hours a week. About 2 in 100 refunds are issued wrong.
The team tried a copilot last year. It drafted the email and summarized each case. Time per refund dropped from 10 minutes to 7. That’s about 47 hours a week. Better, but a person still touched every request.
So the team logs the last 20 times a person touched the process. For each touch, they write what the person did. They looked up the order. They checked the return window. They checked that the warehouse scanned the item back. They issued the refund, updated the record and sent the template email. A few times, they decided a “damaged on arrival” dispute or reviewed a customer with many past refunds.
Then they sort each touch into one of two kinds. Judgment means the person chose between options using know-how no one has written down. Passing along means they moved information, copied it or checked it against a written rule.
Of the 20 touches, 14 were passing along. Six were judgment: damage disputes, customers with many past refunds and refunds over $500. Most of the process is a person moving information between screens.
An agent can only follow rules that are written down. So the team writes the rule behind the passing-along touches. A refund goes ahead on its own if it’s within 30 days of delivery, the warehouse has scanned the item back, it’s under $500 and the customer has had no more than 2 refunds in the last 90 days. Anything that misses a rule goes to a person. So does anything the agent can’t match to an order.
Then they test side by side for 2 weeks on 800 requests. People still do the real work. The agent makes its own decisions on the same requests, and the team compares. They set the rules first. It’s a go if the agent matches the person’s decision at least 95% of the time, gets no more than 2 in 100 wrong and sends no more than 25% to a person.
The agent matched the person 96% of the time. It sent 18% to a person. On the ones it handled, it got 1 in 100 wrong. That’s a go.
They switch over in stages, starting with refunds under $100 and raising the limit over a month. Once it’s fully on, the agent handles about 82% of requests, or 328 a week. People handle the other 72. Those are the harder cases, so they take about 15 minutes each. That’s about 18 person hours a week, plus spot checks of the agent’s work.
Here’s the comparison:
Today: about 67 person hours a week.
With a copilot: about 47.
With an agent: about 18.
And the copilot doesn’t go away. The team keeps it for the 72 exception cases. It summarizes the customer’s history and drafts the reply. The person makes the call. That’s a helper used where judgment lives.
How this ties to the gap
This connects to the core math in the Venture Proof method. For any result, I ask what it costs today and what it would cost if nothing were wasted. That’s the floor. Today’s cost divided by the floor is the Physics Gap.
For a refund, the floor holds the compute to check the rules and the person time the exceptions truly need. It doesn’t hold a person copying an order number between screens. A copilot lowers today’s cost a little, but it leaves the person in every step. So the gap stays wide. An agent goes after the steps that sit between today’s cost and the floor.
The counter-case
The strongest pushback is about risk. “Agents make mistakes. A person in every step is the safety net.”
I agree that mistakes matter. That’s why the method has a written exception line, a side-by-side test with rules set in advance and a switch in stages. You don’t hand anything over on faith. But look at today’s error rate too. People make mistakes when they’re moving information between screens all day. In the example, the agent got fewer refunds wrong than the people did. A person in every step isn’t automatically safer. It’s just familiar.
The second pushback is that copilots are cheaper and faster to roll out. They are. You can hand them out next week. An agent workflow needs you to write the rules, set the exception line and test it. That’s real work. But it’s work you do once per process. The copilot’s limit is built in. It can never take the person out of a step.
The third pushback is that some work is all judgment. Creative work needs a person in charge. So do high-stakes expert calls, like a medical decision or a big legal judgment. In those cases, a helper that makes the expert faster is exactly right. My point isn’t that every process needs an agent. It’s that most processes have plenty of steps where a person isn’t using judgment at all. They’re just moving information from one place to another.
What to do Monday
Pick one process your team runs every week.
Define one run of it, and name the result it produces.
List the last 20 times a person touched it. Use the system’s history if you can, or sit with the person and watch.
Mark each touch as judgment or passing along.
If most were passing along, that process needs a doer, not a helper.
Try to write the rule behind each passing-along touch. If you can’t write the rule, that touch is really judgment. Keep a person on it.
Set the exception line. Make it plain enough that anyone could check it. Start strict.
Measure tasks finished per hour and the error rate today, before you change anything.
Write your go and no-go rules, then run the agent side by side with your people for two weeks.
Switch over in stages, starting with the lowest-risk cases. Loosen the line only when the numbers hold.
Keep a copilot on the judgment touches. That’s where a helper earns its place.
Where this breaks
First, the rules have to be real. If the team writes rules that don’t match how decisions get made, the agent will be confidently wrong. The side-by-side test is there to catch that.
Second, the exception line drifts. As the agent handles more, people may loosen the line too fast. Check the error rate every week.
Third, some processes don’t have enough volume. If a process runs five times a week, writing rules and testing an agent may cost more than it saves. A copilot may be the right call.
Fourth, watch what the person does with the time. If the hours freed up go into more passing along somewhere else, nothing changed.
The close
A copilot makes a person faster at every step. An agent asks whether the person needs to be in the step at all. Most companies bought the first and expected the second.
Count your touches. Sort them. Put a doer on the passing along and keep a helper where judgment lives.
Get the free download
Grab the free checklist, with the playbook included. The checklist gets you started this week. The playbook walks you through the full refund desk example, step by step.
We map processes like this in the Innovation Unpacked Mastermind.
If you want to look at one of yours, book a call.
Book an appointment: Click here
Email me: mike@pjtbd.com
Call me: +1 678-824-2789
Follow me on 𝕏: https://x.com/mikeboysen
Articles - jtbd.one - De-Risk Your Next Big Idea
Website - pjtbd.com
Slaying the Sacred Cows of Innovation
