What Goes to the Agent, and What Stays With Your Team
Here is how most AI pilots go.
They start with whatever tool got purchased, whatever demoed well, or the one somebody in the senior leadership asked about last quarter. Then without enough planning or thought, the team takes a piece of priority work, hands the whole thing to an agent, and waits to see what comes back.
Then they hit the part the agent cannot carry. There is always a part. And because the whole workflow went over at once, there is no clean way to keep the 80% that was working. So all of it comes back out and it gets written up as an AI initiative that did not deliver.
Two decisions were flawed, and they look like different mistakes:
Choosing where to start carelessly
Handing over the whole thing at once
In reality, this is the same mistake made twice. The mistake was making a decision at the wrong altitude.
Your candidate list is built out of complaints
Ask any team where AI should help and you will get a list of the things people are complaining about and hoping AI can solve. Those complaints are real and worth taking seriously. But a list built entirely from them will miss things, because the highest-value problems are sometimes the ones nobody has reported.
In one engagement, we ran AI analysis across a client's call recordings, looking for patterns. What came back was that conversations consistently went sideways at the same moment: when the rep pulled up the pricing calculator.
Nobody had raised it and it had never come up in a QBR. No rep had flagged it, no manager had noticed it, and because it was silently lurking underneath the surface, it was not on anybody's list of things to fix. The evidence had been sitting in the call recordings the entire time, but no human had the hours to go find it.
Once we could see it, the calculator got redesigned and we built targeted enablement around using it. Because we walked in with evidence instead of an opinion, this change happened faster and with a lot less argument than it otherwise would have. GTM teams are understandably emotional, and they live or die by their number. Data is how you sort through emotion and discern between a real problem and the loudest voice in the room.
So before you build your list of problems for potential AI workflow, go look at the data you already have within call recordings, support tickets, notes, and your CRM. Don’t search to confirm what people are telling you, search for the things that nobody is talking about.
Then deliberately widen the list, because it will not widen itself.
Here are four key places to check:
Creative work. Blank page problems. First drafts, personalization, prep materials.
Analytical work. Information that exists but nobody has time to use.
Operational work. High frequency, repetitive, consistent steps. The tax on everybody's job.
Strategic work. Where decisions get delayed because insight surfaces too slowly.
Then put a score against what you have. How much pain? Look at it in terms of frequency and cost rather than annoyance. How much impact does it have if it improves the numbers you get measured on? How feasible right now, given dependencies and how much change it demands?
Not all scores are equal. Impact always carries the heaviest weight, and the logic is worth knowing even if you never formally score anything. This often plays out in the case of serious-pain-with-modest-impact. This is a seductive trap precisely because fixing it makes people happy, but changes nothing.
These foundational steps will help you prioritize what to focus on, but they do not get you a workflow design.
The decision that actually determines whether this works
You do not just hand an entire workflow to an agent. You break it into tasks and then decide how each one is handled separately.
That sounds like more work and it is. But it is the crucial difference between something that survives contact with reality and something that fails and comes back out next quarter.
Think about how you would onboard a new person. You would not just say "you own account planning now" and walk away. You would work out which parts they take, which parts you keep for the moment, what they bring you to check, and when they should come get you. Designing an AI workflow is the same exercise, but it feels unfamiliar because people are treating an agent as software rather than as something that is joining the work.
For each task, the question is not whether AI can do it. It can do more than most people assume, and using the test of capability will talk you into handing over things you should not.
The real question is whether AI should be given the task.
Some things push toward a person to handle. Judgment and ambiguity, where the task needs interpretation or reading between the lines. Relationship and trust, where it depends on a human connection. Emotional intelligence, where it needs empathy, persuasion, or navigating conflict.
Some things are great for an agent to do the work, but a person has to review it. Risk, where a mistake is expensive or hard to reverse. Compliance, where the territory is regulated or legally exposed.
And some things pull toward an agent. Repeatability, where the steps are consistent. Data availability, where the inputs are digitized and reachable. Volume, where it happens constantly.
The ordering matters more than the list. If a task needs judgment, relationship, or emotional intelligence, it stays with a person even when it is also repeatable and high volume. Risk and compliance on their own indicate an agent can do it as long as someone is checking. But if a human-leaning factor is present too, it is human-led, not just overseen.
The mixed version is usually right, and it is not a straight line
Work through them task by task, and most workflows will come out mixed. Some pieces to the agent, some to the person, and the interesting ones are split between them.
But most teams never get here because they treat it as binary. Agent or human, pick one. That is what produces the all-or-nothing rollback.
Here is a mixed one that works. On account planning, the agent does the research and builds a personalized first-call deck off the corporate template. The rep takes it, adds their own read of the account, and presents it. Then, after the call, the rep asks the agent to build a demo based on what actually came up in the conversation.
Watch what happened in the middle.
The agent's second task is far better than its first, and the reason is that a person went and had a real conversation in between. The rep came back with what the buyer actually said, what landed, who else was in the room, where it got tense. None of that existed anywhere before that call. No amount of research would have produced it.
So the rep is not there to check the agent's homework. The rep is there because they are the only one who can go out and get the thing the next step depends on. Judgment matters. But mostly this is about input.
That is a loop, not a line, and each pass is better than the last because a person went out into the world in between. Design for the loop and the agent compounds. Design for the line and you get one draft, a human editing it, and nothing accumulating.
Name every handoff
Whatever split you land on, the points where work passes between the agent and the person are where it will break. Vague handoffs are how work gets done twice, or not at all, and how a buyer ends up repeating themselves to somebody who should already know. Solve for this by writing them down. What passes, in which direction, and who is responsible for moving it forward.
Then enable for the relationship, which is two jobs
You can pick the right area, split it correctly, design a genuine loop, and still watch it fail because nobody taught anyone how to work this way.
There are two layers and they are not interchangeable.
The first layer is specific to this workflow. You must provide clarity and define what the agent does at this step, what the human does, where it passes to them, and what they should have in hand when it does. It also defines what good output looks like and how to tell when it is not. All of this gets built fresh for every workflow you design.
The second layer is the general skill of working alongside an agent at all. How to direct it. How to judge whether what came back is any good. How to correct it instead of quietly redoing it. Knowing when to escalate and when to just take the thing over yourself. That is a capability, and once your team has it, it carries into every workflow you build after this one.
Most teams don’t build either one of these layers. The ones that build something almost always build the first, which means they start from zero every time.
So, concretely
Go look at your own data before you build a workflow candidate list. The best candidates are sometimes ones nobody has reported. Widen the list past the operational complaints.
Score on pain, impact, and feasibility, and let impact carry the most weight.
Then break each one into tasks and decide each one, rather than handing over the whole workflow. Expect the answer to be mixed.
Design the loop rather than the line. Write down every handoff.
Then enable people for the specific workflow and for the general skill, because those are different jobs.
This is most of what we do inside Beyond the Threshold, and it is the part clients are least prepared for. They arrive expecting a conversation about tools. We spend the early part of it on what the work actually is and who should be doing each piece of it. The tool conversation gets a lot shorter after that.
I wrote in the first part of this series about why most teams cannot say what they want AI to do in the first place, which is the question underneath all of this. If you are still at that stage, start there. If you have your answer, start here: pick the area deliberately, then take it apart before you hand any of it over.
Roz Greenfield is co-founder of Level213 and co-author of Accelerating Revenue: Your Definitive Guide to the Theory and Practice of Go-to-Market Enablement