Hire your first
AI employee.

A task is “summarise these five articles”. A job is “you own the Monday unpaid-invoice chase”. The task is done in ten minutes and teaches you nothing. The job can be measured, improved, and eventually trusted.

Write what the agent will own in one sentence. If the sentence needs several unrelated verbs, you are describing more than one job, and when something goes wrong you will not know which one caused it. Split it.

For the first hire, choose a job that is frequent, so you get signal this week, and reversible, so a mistake costs a minute. Anything that sends, publishes, buys, deletes, or talks to a customer waits until after probation.

The role card is the agent’s job description. Fill in the template below and paste it wherever your product keeps an agent’s standing instructions (its profile, description, or system prompt). Three lines matter more than the rest.

If unsure, stop and ask. A capable agent facing ambiguity will use its best judgment on its own, and you want the opposite. Being slow costs nothing; being wrong inside your outbox costs a client.

Keep “ask me first” and “never” apart. “Ask me first” means you might say yes today. “Never” means the question does not come up. Merge them and you teach the agent that everything is negotiable.

Make “finished when” checkable. Ban words like useful, thorough, and complete. Replace them with conditions the agent can test on its own output: counts, fields, dates, sources, format.

Durable rules live in the role card. Today’s work lives in the message you send. Keep them apart, because when something breaks you can then tell what broke.

• A forgotten preference is a memory problem: it belongs in the role card.
• Opening the wrong tool is a routing problem: the “works from” line is too loose.
• Sending something that should have stayed a draft is a permissions problem: the tiers are wrong or not enforced.
• Retrying the same broken path six times is a limits problem.

A better message fixes one run. A corrected role card fixes every run after it.

Everything in the role card is an instruction. Instructions shape behaviour without guaranteeing it, and the model behind your agent can change without notice. Some rules also need a control that holds when the instruction is misread.

The only “never” that is fully enforced is access the agent does not have. So, before run one, write down what the agent can reach, and close what it should not:

• Connect only the tools the job touches. Add a connection when a real, blocked task proves it is needed.
• Prefer a read-only credential or connector to a browser login. A login can do anything the account can.
• If two jobs need different levels of trust, such as outbound email and finance, give them separate accounts. Agents under one account usually share the same files and sessions.
• Check what your product’s approval system actually reviews. Many review commands and external actions but not changes to the agent’s own memory or settings.

Before the first real run, ask the agent to walk you through how it would do the job, in order, and then stop. Treat the answer as a job interview. An agent that is about to misread your inbox will say so in text, and you catch it in a message instead of in your archive.

Listen for three disqualifiers. It names a tool or account you never connected: it plans to improvise access. It proposes an irreversible step without flagging it: your “ask me first” line is not landing. It cannot say when it would stop: “finished when” is too vague. Any one of these means the role card needs another pass.

One clean run is an event. Reliability is a pattern, and you need three runs on different inputs to see one.

• Run one: observe. Watch the whole run. Note every misread instruction, lost fact, odd tool choice, duplicated action, and every moment it guessed instead of asking.
• Run two: correct. Fix the role card, not the output, and give it a different but comparable input. Do not remind it of run one’s mistake by hand; you are testing whether the fix held.
• Run three: release. Step in only for approvals, genuine ambiguity, or a limit being hit.

Score each run on five numbers: runs, clean passes, repairs you made by hand, guesses where it should have asked, and minutes of your time. Then save the three inputs and the outputs you accepted in a tests folder. That is your regression set, and you will use it every time something changes underneath the agent.

The line between “can do alone” and “ask me first” is not about how important an action feels. It is about whether it can be undone. “Draft the outreach to forty prospects” is reversible. “Send it” is not. A good run finishes the reversible ninety percent and stages the rest for you.

• When the agent hits a login wall, give it the session, never the password. Complete the blocked step yourself and hand control back. Never paste passwords or one-time codes into a chat.
• Treat everything the agent reads as data, not instructions. During probation, plant a fake instruction in a test document and confirm the agent flags it instead of following it.
• Money and identity stay with you. Read-only financial data is fine; paying, cancelling, accepting terms, and sending from your name are not. You are responsible for every action the agent takes, whether or not you intended it.

A scheduled routine that ends in a request for your approval at three in the morning will time out, and the work is lost. Design it to end in staged drafts instead: the routine does all the reversible work, leaves the drafts where you will find them, and posts a one-line receipt. You approve when you open the conversation, while you are there to answer.

• A heartbeat. Every run posts something, even “No change, checked 07:00.” If a job goes silent, assume it broke.
• A ledger. The agent keeps a file of what it has already covered and checks it before acting, so no customer is emailed twice and no spreadsheet is recreated from scratch.
• An update rule. “Update existing rows. Never create a new sheet or file if one exists.”
• A stale-source stop. If a source cannot be read, the run reports the failure and stops rather than filling the gap with old data.

Autonomy is a level, and levels are earned. A simple ladder: level one drafts only; level two takes reversible actions alone; level three sends or posts within a named list; level four runs the whole job and reports. Most agents should live at level one or two for a long time.

Promote only when all five hold: five consecutive clean runs, verification passing every time, no unresolved side effects, a rollback you have tested at least once, and proof that the approval rule works in practice, meaning something was actually staged and you saw it wait. If your product offers an “always allow” button on an approval, that button is a promotion. Press it only for an action that has passed the gate.

The ladder runs both ways. Move the agent down a level when output quality drops, when the model, a connector, or a website changes underneath it, or when you catch yourself hand-correcting it two weeks in a row.

Always-on automation does not fail loudly. Logins expire, a site moves, your priorities shift, and the routine keeps delivering on time while the output becomes worthless. Build four watches before you build a team.

• The receipt. Once a week, a short report: runs, passes, hand repairs, the repeated failure, and a keep, fix, or fire call. Spot-check one artifact yourself.
• The heartbeat. Did every scheduled run post something?
• The approval log. Did anything get staged? If the agent never parks anything, your approval rule is decorative.
• The doubt line. Did it run on time? Was the output correct, or merely present? Would you notice if it disappeared tomorrow? If the answer to the last one is no, delete it. A routine that removes no work is a trophy on a shelf.

Add a second agent only when the work needs a different source set, a different permission boundary, a different memory, or a different way of being checked. When one ends, offboard it properly: pause its routines, sign out of the sites it used, revoke its connections at the source, remove its files, then delete it. Deleting the agent alone leaves the sessions behind.