Most conversations about AI in onboarding start the same way. We have an onboarding process, AI can now take actions, so let’s put an agent in it.
I get the appeal. Kickoff prep, task reminders, risk detection, status updates, chasing missing customer inputs: there is plenty of onboarding work that looks automatable, and it’s easy to picture an agent handling all of it.
The catch is that most onboarding processes are only as clear as the person running them. In every org I’ve joined, two implementation managers could look at the same customer and make different calls. One sees a customer ready to launch, the other sees three unresolved risks. One follows up the day a task hits five days overdue, the other holds off because they know the customer’s IT team is tied up with something bigger. I’d argue both are right. But those are decisions, not process steps, and when they only live in someone’s head, handing the work to an agent doesn’t remove the ambiguity.
It just moves it.
A process can look standardized without being standardized
On paper, every onboarding team has a process: stages, templates, project plans, milestones, and checklists. So many checklists, because somehow they multiply faster than the team does.
Then real customers show up and the judgment calls creep in. The kickoff is marked complete, but the executive sponsor never attended. An integration task says “in progress,” which could mean engineering started yesterday or that nobody has touched it in three weeks. Training is scheduled, but half the content owners haven’t been named. The launch date stays green because nobody wants to be the first to turn it red. The fields are populated; the meaning isn’t.
That is where agents get interesting, and where they get risky. An agent needs more than access to the project plan. It needs to know what each field means and what it is allowed to do about it. What counts as risk? How long can something sit before the agent acts? Can it change anything, or only flag it? Who does it contact, and when does it stop and hand off to a person?
The better question isn’t “Can AI do this task?” It’s “Have we made the task clear enough that we’d trust something else to do it?”
The research points the same way
Research on agentic AI keeps landing on an unexciting conclusion: the teams getting value have clear use cases, usable data, and boundaries around what the agent is expected to do. The fanciest model matters less. Expectations are running ahead of that reality. One 2026 onboarding survey found that 70% of onboarding and Customer Success leaders expect AI to handle half of onboarding tasks by 2027. It’s a vendor survey, so treat the number as directional, but it could happen.
There is still a big gap between asking an agent to summarize a project and asking it to decide the project is at risk and contact the customer. The second one needs an operating decision, not a clever prompt.
Pick a workflow, not “onboarding”
“Automate onboarding” is too broad to be a use case. Kickoff prep is a workflow. Customer task follow-up is a workflow. So are launch readiness and stalled-project detection. Don’t hand an agent the whole customer journey. Give it one job.
For example: find projects where a customer-owned task is more than five business days overdue and no follow-up has been logged in the last three days.
That works because the trigger is clear, the data is identifiable, and the action can be bounded. From there, decide what the agent does with a hit. It could draft the follow-up without sending it, move the account into a review queue, or alert specific people. You can go further and vary the action by account: maybe it acts on its own for smaller customers and routes anything tied to a large enterprise to a person.
The first version doesn’t need to be impressive. It needs to be clearly useful.
Keep a person in the loop long enough to learn something
The temptation is to jump straight to autonomy, because an agent that only recommends can feel pointless. I’d resist that. Recommendation mode is where you build trust and find out how accurate the thing actually is.
Pay the most attention to the disagreements. When the agent flags an account the implementation manager thought was fine, ask why. Was the data wrong? Was the rule wrong? Did the manager know something the system couldn’t? Every answer tests the AI, but it also pressure tests your process, because a disagreement is usually where an unwritten judgment call is hiding.
It’s the same reason I like ugly first versions of internal tools. The first version is a learning artifact, not a deliverable. Your agent doesn’t need to run onboarding. It needs to show you where onboarding depends on judgment you’ve never made explicit.
Five questions to answer before you give an agent a job
Pick one workflow and get the team to answer these:
- What starts the workflow?
- What information does the agent need?
- What is it allowed to do?
- When does a person take over?
- What does “done” mean?
If the answers are fuzzy, skip the prompt for now. The goal is one workflow that’s clear enough to evaluate, with real data, clear boundaries, and a human escalation path. Then see what breaks, fix it, and give the agent a little more responsibility.
That’s less exciting than “fully autonomous onboarding,” but it’s a heck of a lot more useful!
Try it with your team
Have two people on your team answer the five questions for the same workflow, independently, before comparing notes. If their answers differ in a material way, AI isn’t the first problem to solve. The work isn’t clear enough yet.
If you run this and get two very different answers, that’s the kind of problem I help onboarding and implementation teams untangle.
Book a 30-minute working session and we’ll walk through what you found and figure out where the ambiguity is coming from.