How To Onboard An AI Employee To Your Business

Onboard an AI employee the way you would onboard a sharp human hire with no memory: write the rules file before day one, give it the access it needs, start it on one real task instead of a test, correct each mistake exactly once by adding a line to the rules, and resist the urge to do its work for it when it stalls. The onboarding is mostly done in the first week. The difference from a human is that everything you want it to retain has to be written down, because nothing is absorbed by osmosis.

Day zero: write the rules before the agent arrives

You would not let a new operations manager start without telling them how you work. Do not let the agent either. Before you give it a single task, spend thirty minutes on the Rules For Working With Me file: how you communicate, how you want it to communicate, this-not-that, and an empty irritation list. The thirty-minute guide walks through it.

Owners who skip this step spend the first two weeks discovering, one annoyance at a time, what they should have written down. Owners who do it spend the first two weeks getting work back.

Day one: give it access, then make it ask for the rest

Most onboarding stalls are not intelligence problems. They are access problems. The agent needs a login, an environment variable, an API key, and it does not have it, so it either improvises around the gap or hands the work back to you half done.

Run the checklist we teach: agent, then skills, then tools. Does the agent exist and read its rules? Does it have the skills (the documented procedures) for the jobs you are giving it? Does it have the tools (the actual access)? Set up what you can up front. Then put one line in the rules: "If you need access you do not have, tell me the exact name of the thing in one line and stop." That line turns a wasted day into a one-minute request.

One operator on the Optimus Mastermind calls, with no technical background, spent two weeks dragging build folders to a deployment by hand before she learned the agent could deploy itself. The agent could always do it. Nobody had told her to ask, and the agent, assuming she knew what she wanted, did not volunteer. That is the gap this step closes.

Day one, continued: start with a real task, not a test

Do not ask the agent to write a poem or summarize an article to "see what it can do." Give it something you actually need done this week, small enough to check in ten minutes, real enough that the output matters. A report you pull by hand every Monday. A renewal email you have been putting off. The first draft of the SOP you keep meaning to write.

Real tasks surface real gaps in the rules. Test tasks surface nothing, because you do not care about the output enough to notice what is wrong with it.

Before it starts, use the phrase: "Ask me every question you have now, then don't stop until it's done. No sandbagging." Front-loading the questions is the single biggest change to how the first week goes. One member front-loads every question before a build and the agent "just goes to work"; it wrote chapters 7 through 16 of his book in his voice.

Week one: correct once, in writing

The agent will do things wrong. That is expected. What matters is how you correct it. The wrong way is to explain the correction in chat and move on, because the next session starts with no memory of the conversation. The right way is to add one line to the irritation list in the rules file: what it did, what it should have done. It reads that list before every shift, so the mistake is made once.

This is the part of onboarding that compounds. My own frustration with my agents went from roughly 40 percent of interactions to about 5 percent once the irritation list existed. Nothing about the underlying agent changed. The list did.

A few corrections show up in nearly every first week and are worth writing in advance:

• It asked questions one at a time instead of all at once. Rule: ask everything up front.
• It gave you a plan instead of doing the work. Rule: do everything you can yourself; hand me only what needs me.
• It walked you through a manual process when an API existed. Rule: check for an API or MCP first, read the docs, do not guess.
• It said it read a document and clearly had not. Rule: confirm you actually read it.

Week one: decide what is code and what is agent

As the agent takes on recurring work, you will notice some of it needs judgment and some of it does not. The decision rule: a hard-and-fast rule is code, a judgment call is the agent. If the Monday report must go out at 8am every week in the same format, schedule it as a job and stop asking the agent to remember. If the renewal email needs a read on the customer's mood from the last three tickets, that is agent work. Sorting tasks into these two buckets in the first week prevents the two classic failures: babysitting work that should have been automated, and automating work that needed a brain.

Week two and after: hand off between sessions

Agents forget between sessions unless you make them write things down. Before you close a long working session, use the phrase: "Write me a handoff file; I'm opening a fresh window." The agent writes down where it is, what is done, what is next, and what it needs. The next session starts by reading that file. Without this, every new window is day one again.

By the end of the second week, you should have: a rules file with a handful of irritation lines, a short list of scheduled jobs the agent runs without you, a clear sense of what it escalates and what it handles (see the escalation rules), and a habit of writing corrections down instead of saying them. That is onboarding done. Everything after that is just working together.

FAQ

How long does it take to onboard an AI employee?

About two weeks to a stable working relationship, with most of the effort in the first few days. Thirty minutes to write the rules file, an hour or so to set up access, then one real task a day with corrections written into the irritation list as they come up.

Should the first task be a test or real work?

Real work. A small task you actually need done this week, checkable in ten minutes. Test tasks reveal nothing because you do not care about the output enough to notice what is wrong. Real tasks surface the gaps in your rules immediately.

What do I do when the agent stalls?

Run the checklist: agent, skills, tools. Does it have the rules, the documented procedure, and the actual access it needs? Most stalls are a missing login, env var, or API key. Put a line in the rules telling the agent to name exactly what it needs and stop, rather than improvising around the gap.

How do I stop the agent forgetting everything between sessions?

Two things. Keep standing preferences and corrections in the rules file it reads before every shift. And before closing a long session, tell it to write a handoff file covering what is done, what is next, and what it needs, so the next session starts by reading that instead of starting over.