Skip to content
Data McFly.
Back to writing

writing

Your First AI Agent Is a New Hire. Onboard It Like One.

Jun 17, 2026 · 5 min read · Roger Stringer

You bolted an agent onto your workflow, gave it a prompt, and watched it do something dumb. Maybe it hallucinated a customer's order history. Maybe it sent a confident, wrong answer to a real person. So you concluded what most people conclude: the AI isn't ready yet.

It probably is. What wasn't ready was your onboarding.

Here's the reframe that fixes more failed AI projects than any model upgrade: you didn't deploy a piece of software. You hired someone and skipped their first week. Take a sharp, capable new hire, drop them at a desk with no job description, no logins, no context on how you do things, and no one to check their work. They'll fail too. Not because they're incapable. Because you set them up to.

Treat the agent like an employee instead of a tool, and the management instincts you already have start doing the work for you.

Every new hire gets four things. Your agent got one.

When a person joins your team, they get a job description, access to the tools and systems they need, context on how the company actually operates, and a manager who reviews their work. Your agent got a prompt. That's the gap.

A new hire gets… Your agent needs…
A job description: scope and what "good" looks like A defined task and explicit success criteria, not "do some stuff"
A laptop, logins, permissions The right tools and integrations: enough access to work, not enough to cause an incident
Onboarding docs, the wiki, Slack history Context and memory: your data, examples, and how things actually get done
A manager and regular reviews Evals and a feedback loop: a way to catch it being wrong

Walk through each one and the flaky results start making sense.

A job description, not a vibe

"Help me with support tickets" is not a job description. It's a vibe. No human succeeds against a brief that vague, and neither does an agent.

Say you're putting an agent on a support inbox that takes a few hundred tickets a week. Give it the same thing you'd give a new rep on day one: the specific scope of what it owns, the boundaries of what it doesn't, and a concrete definition of success. Read every inbound ticket, sort it into these five categories, draft a reply for the routine three, and escalate anything mentioning billing, cancellation, or legal to a human. That's a job. It can be done well or badly, which means it can be measured. And that's the whole point.

Access: enough to work, not enough to do damage

A new hire with no logins is blocked. A new hire with admin keys to production on day one is a liability. You scope access deliberately for people, and you should scope it just as deliberately for agents.

This is where "give the AI access to everything and let it figure it out" goes wrong. An agent wired into your production database with no guardrails isn't a feature. It's an incident waiting for a date. Give it the specific tools the job requires and nothing more. Back to the support agent: read access to the ticket queue and the help docs, write access only to a draft field, no permission to actually send. The constraint isn't a limitation. It's what makes the thing safe to trust.

Context is the onboarding nobody skips for humans

The reason a good hire is useless in week one and great in month three isn't that they got smarter. They got context: the wiki, the back-channel, the thousand small "oh, we don't do it that way here" corrections.

Agents need the same thing, and this is the part teams consistently underinvest in. The model is the easy part. The work is getting the right data, in the right shape, in front of it at the right moment. Your actual policies, real examples of good output, the edge cases that matter to your business. Most "the AI isn't good enough" problems are really "the AI has no idea how we operate" problems. Fix the context and the same model gets dramatically better overnight.

A manager and a feedback loop

No one ships a new hire's work for six months without ever reviewing it. Yet teams routinely deploy agents with no way to tell whether the output is any good. No evals, no spot checks, no loop.

You don't need anything exotic. You need the management ritual you already run: a way to look at the work, catch where it drifts, and correct it. Call them evals, call them performance reviews. Same function. If you can't tell me how you'd catch your agent being wrong, it isn't ready to be in front of customers, the same way you wouldn't put an unreviewed new hire on your biggest account.

What stays yours

Onboard an agent this well and it will reliably handle the bulk of a workflow: the reading, drafting, classifying, routing, the high-volume work that used to eat your team's day. That's most of the labor. It's also not the part you can't afford to get wrong.

This is the 70/30 Method in practice. Roughly 70% of the work goes to well-onboarded agents. The other 30% stays with you: what the agent can touch, what "good" means for your business, the call that something's ready to ship, and the judgment to override the machine when it's confidently wrong. Onboarding the agent properly is exactly what earns you that 70. Skip it and you're not delegating, you're gambling.

You already know how to do this

You don't need a new theory of AI to get real work out of an agent. You need to apply the old one. Give it a clear job, the right access, real context, and a manager who reviews its work, the same things that turn any promising hire into a dependable one.

That's the heart of what we build with clients: an Agentic OS where agents have real job descriptions, scoped access, and a feedback loop you can trust, not a pile of clever prompts. If you've got agents that demo well but you don't yet trust them with real work, that's the gap we close. Let's talk.