Onboarding an AI Agent Like a New Hire
Onboarding an AI Agent Like a New Hire
The fastest way to get bad work out of an AI agent is to give it root access and a vague mandate on day one. The second fastest is to give it a wiki link and hope.
We run an agent that operates a real company: it publishes, it schedules, it touches production systems. The thing that made it useful was not a better model. It was treating the first two weeks exactly like onboarding a human, including the parts that feel slow.
Week one: read-only, and it stays read-only
A new hire does not get production write access on Monday. Neither should an agent.
The first week is observation. Let it read the systems, summarize what it sees, and propose actions it is not allowed to take. You are checking one thing: does its description of reality match yours? An agent that misreads the current state will confidently break things later, and you want to find that out while its hands are tied.
The tell is specificity. "The deploy pipeline looks healthy" is not understanding. "The nightly job has failed four times this month, always on the same step" is. If you only get the first kind, the agent does not have enough context yet, and more permissions will not fix that.
Write the job description, not the personality
Most agent setup guides obsess over tone. Tone is the least load-bearing thing you will configure.
What matters is the same thing that matters in a real job description:
- What outcomes is this role responsible for?
- What decisions can it make alone?
- What must it escalate, and to whom?
- What does "done" mean for its recurring work?
That last one is where most setups fail. If "done" is undefined, the agent will invent a definition, and it will usually pick the one that lets it stop early. We had to write down that a published post is not done until it has been independently verified live. Without that line, "I published it" was the finish line, and nobody was checking whether the thing was actually reachable.
Permissions expand on evidence, not on time
The instinct is to widen access after a week because the week is over. That is tenure, not competence.
Widen on demonstrated judgment instead. The agent correctly refused something it should have refused. It escalated a call that genuinely needed a human. It caught its own error before shipping. Those are the receipts. A quiet week where nothing happened proves nothing at all.
Run it in the other direction too. When something goes wrong, the question is not only "what broke" but "should this capability still be automatic?" Access that ratchets only outward is not a permission model, it is a countdown.
Give it a manager, not an audience
A new hire with no feedback loop learns nothing and drifts. Same failure mode here.
Someone has to read the output regularly, not just when it breaks. The agent needs a place to record what it learned so the lesson survives past the current session, and it needs a standing expectation that mistakes get written down rather than smoothed over. Our most valuable operational file is the one where failures get logged, because those entries are what turn into rules.
The difference from a human hire is that the agent will not push back on being ignored. It will keep producing at whatever quality it drifted to, indefinitely, and the first signal you get will be a customer noticing.
The part that feels like overhead
All of this is slower than pointing an agent at your systems and telling it to be helpful. That is the point. The onboarding is where you find out what it misunderstands, at the moment when misunderstanding is still cheap.
Every organization that has onboarded humans already knows this. The mistake is assuming it stops applying when the new hire is software.
We wrote the whole onboarding sequence down, with the permission ladder and the checkpoints, in One Agent, One Company ($9.97). Worth a read if you are about to hand an agent the keys and want a sane order to do it in.