AI Agent Onboarding: Give It the Job Before the Tools

An AI agent can sound like a very competent stranger. It answers quickly, uses the right vocabulary, and still misses how your business works. That's why I think about AI agent onboarding as more than naming the bot and connecting a few apps. Creating the agent is the hire. Equipping it is the work that comes next.

I've skipped parts of that work myself. Then I've wondered why the output wasn't what I wanted. The instructions, examples, and limits I hadn't written down were still in my head. The agent didn't have them.

In my walkthrough of the agent hire pack, I filled out a hire pack for an Inbox Maintenance Triage agent. I used a demonstration, not a real inbox or resident records. The point wasn't to turn a maintenance process loose without supervision. It was to make the job and its limits specific enough that I could test them.

AI agent onboarding starts with one job

The job I gave this agent was to triage new maintenance intake into a board and draft the next steps. That gives me something concrete to evaluate. I can look at the incoming information, compare it with the draft, and decide whether the agent did what I asked.

It's tempting to keep adding responsibilities. While it's looking at maintenance, why not have it update owners, manage the vendors, check leasing, and answer the phone? Before long, the job is a list of everything you haven't had time to get to.

Start narrower. Write one sentence that describes the work. Give the agent a named owner, too. Someone needs to be responsible for checking its output, deciding what to change, and noticing when the underlying process has changed.

The short job description doesn't have to contain every operating detail. It has to tell you what belongs in this role and what doesn't. The rest of the hire pack fills in how the work gets done.

That distinction also makes it easier to work with an assistant you've already created. You don't necessarily need to start again. Compare its current instructions with the job you actually want it to do. You may find that it has a personality and a name, but no clear definition of a successful result.

Write the stop line before you connect the tools

For the maintenance example, I wrote down what the agent must not do. It must not invent unit details, approve spending, or decide habitability. Money and safety decisions stay with a person. Sending, posting, publishing, and deleting also need their own explicit boundaries.

Those aren't details to add after an agent surprises you. They're part of the job description. A draft-only assistant and an assistant authorized to contact a vendor are doing different jobs, even if both can produce the same message.

The practical question is simple: where does the AI stop and a person take over? Write the answer in language your team can explain. If the agent prepares an owner update, who checks the facts? Who confirms an amount? Who sends the final message through the company channel?

Don't assume that writing a rule creates a technical restriction. Instructions tell the agent how you want it to behave. Permissions and tool settings determine what access it actually has. Check both. If a connection supports narrower access, use the access the job needs rather than granting everything because it's easier during setup.

In the walkthrough, Gmail was an example of a connection that could prepare drafts without being authorized to send. A property-management connection could be limited to reading open tickets rather than closing them. Those are intended operating boundaries to verify in the actual tools, not a claim that every connector offers identical controls.

Give it the information and process it needs

Next comes the material the agent must use. In my maintenance example, that included a vendor list and approval limits. The hire pack records where those documents live so the agent isn't relying on a vague instruction to use company policy.

A link by itself isn't proof that the information is available. Open the source through the connection the agent will use. Check that it can read the right document and that the document is current. If the approval limits are missing, the answer isn't to let the agent estimate them.

Skills and standard operating procedures serve a different purpose. The reference information tells it what to know. That is the same source-review work I describe in building a Business Brain for your property management team. The process tells it how this work gets done in your business. For maintenance intake, that might mean preparing approved input, organizing the ticket, identifying missing information, drafting the next communication, and stopping for human review.

If you haven't documented the process, that doesn't mean you can't start. Walk through a small example and write down the steps you actually approve. Then test the written process. Don't mistake an agent's plausible sequence for the way your business has decided to operate.

File access deserves the same attention. Name the folder the agent may use and whether it can read, write, or both. A dedicated working folder is easier to review than an instruction to save things wherever they belong. Keep sensitive records outside that working area unless the task genuinely requires them and the access has been approved.

Check cost and prove the work before you repeat it

The hire pack also has a place for costs. In the demo, I used a $20 monthly cap and a $1 per-run limit as example boundaries. Those figures aren't a recommendation for every agent. They're a reminder to decide what spending is acceptable before connecting a service that can charge you.

A spending instruction isn't the same as an enforced account limit. Check what controls the provider actually offers, set applicable limits, and decide what should happen when a task approaches them. Some tools may have different billing models or controls, so the check needs to happen on the service you're using.

Then give the agent two different inputs and inspect the results. One good answer is useful, but it doesn't tell you what happens when a ticket is incomplete, contradictory, or outside the intended job. Pick examples that reveal those differences without exposing information the tool isn't authorized to receive.

Look for more than whether the output reads well. Did it stay with the supplied facts? Did it flag the missing information? Did it stop where you told it to stop? Can the person reviewing it tell what still needs a decision?

Make corrections, run another example, and record what passed. Only then consider a routine. A completed form, a working connector, or an agent repeating its instructions back to you isn't proof that the whole process is ready to run unattended.

Use the same standard for the agents you already have

The useful part of the hire pack is that the questions travel with you. The specific setup will depend on the platform, but you still need a job, an owner, approved information, an agreed process, access limits, and a way to evaluate the work.

Choose one agent you already care about. Work through those decisions before adding another responsibility or another connection. You may not need a different tool. You may need to finish equipping the one you have.

If you're working through something like this, feel free to reach out. I'm always happy to talk through it.