Part of an ongoing series on ordinary workspace friction, and what happens when you point an agent at it.
A new engineer starts on Monday. By Wednesday she still doesn't have production database access, because the request went to a Slack channel where the person who grants it was out sick. Her laptop arrived, but the MDM enrollment never finished, so IT will circle back. Her manager thinks HR handled the payroll paperwork. HR thinks the manager did.
Nobody dropped the ball on purpose. There is a checklist. It's just that the checklist lives in a Notion doc that IT doesn't read, half its steps happen in Jira tickets nobody links back, and two of them are messages someone is supposed to remember to send.
By Friday it's mostly sorted. She lost three days of ramp time, and nobody will ever count that as a cost.
The list exists. The ownership doesn't
Onboarding fails in a specific way, and it's worth naming precisely: no single step is hard, and no single person is responsible for the whole sequence.
HR owns paperwork. IT owns hardware and accounts. The hiring manager owns team introductions and the first project. Security owns access reviews. Each of them does their part competently. What nobody owns is the seam between the parts, which is exactly where things fall through.
Ask any of them "is the new hire fully onboarded?" and the honest answer is "the part I handle is done." That's not evasion. It's an accurate description of what they can see. The full picture is spread across an HRIS, a ticketing system, an identity provider, a Slack workspace, and a doc, and nobody has all five open at once.
So the failure mode isn't a missed step. It's a missed step that nobody notices for three days, because noticing would require someone to reconcile five systems that don't talk to each other.
The kind of system we'd build
This is the shape of problem we look for: the steps are known, the data is already in tools you own, and the only missing piece is something to hold the whole sequence in view. It's the same test we apply to any AI agent development engagement, and onboarding passes it cleanly.
Here's what an agent for this looks like. It knows the checklist for the role, because you gave it the checklist. It watches the systems where each step actually completes: the account created in Okta, the ticket closed in Jira, the device enrolled in MDM, the form signed in the HRIS. It doesn't ask anyone to update a status field, because it can see the status directly.
When a step is done, it marks it done. When a step is late relative to the start date, it says so, in the channel where the owner of that step already works, with the specific thing that's missing and who needs to do it. On day one it posts a single view: here's where this hire stands, here's what's blocking, here's who owns it.
The three lost days don't happen, because on Tuesday morning somebody got a message that said "production DB access is still pending, and here's the ticket."
The agent tracks. A person still handles the exceptions
The agent can tell you a step is incomplete. It can't tell you that this particular hire is a contractor who genuinely doesn't need production access, or that legal is holding a signature for a reason that has nothing to do with anyone forgetting.
It also can't do the part of onboarding that actually matters: the manager sitting down to explain how the team works, the teammate who walks her through the codebase, the first small project chosen carefully. Those are the things a good onboarding is really made of, and no agent should be anywhere near them.
What the agent removes is the administrative overhead that competes with those things for a manager's attention in week one. The tracking, the chasing, the reconciling of five systems. That's assembly work, and it's the part currently getting done badly because it belongs to nobody.
What it takes to build
The interesting engineering here isn't the model. It's the integrations and the state.
You need read access to the systems where completion actually happens, which usually means a handful of APIs and a couple of webhook listeners. You need somewhere to hold the checklist state per hire, because "what's done" is a fact you have to persist and keep current. You need the notification layer to be smart about timing, because an agent that posts every incomplete step every hour gets muted in a day. Most of that is ordinary backend development with an agent making the judgment calls at the edges.
The model's job is narrow: interpret ambiguous states ("the ticket is closed but the resolution says 'duplicate'"), write the nudge in language a human wants to read, and decide when something is worth escalating versus worth waiting on. That's a small slice of the system, and it should be.
A question worth sitting with
Ask your last three hires how long it took before they had everything they needed to do their job. Not what the checklist says. What actually happened.
If the honest answer is measured in days rather than hours, the gap isn't a people problem. Everyone involved did their part. The gap is that no one was holding the whole sequence, and holding a sequence across five systems is precisely the kind of work worth handing to something that never loses track of it.
More in this series: the Friday status update problem and the churn signals nobody is watching. If you have a workflow shaped like this one, our AI development page covers how we scope and price this kind of build.