How to Write a Runbook for Your AI Coworker

You ask your AI coworker to draft follow-ups for overdue invoices. It pulls the right list from Stripe, writes clean emails, and addresses your most formal enterprise client as "Hey folks!" It also offers a payment plan you do not have. Nothing got sent, but you just spent forty minutes rewriting drafts that were supposed to save you an hour.

The AI did exactly what you asked. It failed on everything nobody wrote down.

That gap is what an AI runbook closes. An AI runbook is a standing instructions document: the tone rules, escalation triggers, shared definitions, and do-not-touch lists that a human colleague would absorb in their first month, written down once so the AI carries them into every task. This guide covers what goes in one, the order to write it in, and a template you can copy at the end.

Why Your AI Coworker Needs an AI Runbook

When you hire a person, you do not expect them to be useful on day one. They shadow calls, read old threads, learn that "the Henderson account" means handle with care and that "done" in Jira does not mean deployed. Most of that knowledge never gets written anywhere. It moves by osmosis.

AI does not get osmosis. Every conversation starts from whatever context you give it. If your standing rules only exist in your head, you will re-teach them in every session, and you will forget some of them every time. The symptom is familiar: the AI's output is 80 percent right, and the 20 percent you fix is the same 20 percent every week. Wrong greeting. Wrong definition of "active customer." A draft that touched a deal it should never have gone near.

Teams usually respond by writing longer prompts. That helps for one task and evaporates afterward. The durable fix is separating two documents: the task (what to do right now) and the runbook (how we always operate). Teams that skip this are overrepresented in the postmortems; it is one of the most common threads in why AI employees fail. The model was fine. The standing instructions did not exist.

A second reason matters just as much: a runbook makes the AI's behavior consistent across people. If five teammates each carry their own private rules, you get five different AI coworkers wearing the same name. One document, one behavior.

What an AI Runbook Is, and What It Is Not

Get the boundaries right before writing a word, because most failed runbooks fail by trying to be three documents at once.

An AI runbook is not a task prompt. "Summarize this week's closed-lost deals from HubSpot and flag any over $10k" is a task. It changes daily. The runbook holds what stays true across tasks: that closed-lost reasons must be quoted verbatim from the CRM field, that dollar figures are always USD, that summaries never speculate about why a deal died. If you are still learning to write good tasks, start with how to write tasks the AI nails; the runbook sits underneath that skill, not instead of it.

It is not human documentation either. Your internal wiki explains context for people who can infer. A runbook is written to be executed. Every line should be checkable: someone reading an output should be able to point at a runbook line and say "this violates rule 4." If a line cannot be violated, it is decoration. Cut it.

And it is not a policy document. Legal owns policy. The runbook translates policy into operational instructions: not "we value customer privacy" but "never include a customer's email address in any document shared outside the org."

One page is a fine size for version one. The best runbooks are boring, specific, and short enough that people actually maintain them.

The Seven Sections of a Working AI Runbook

After the boundaries, structure. Seven sections cover nearly everything, and each one exists to prevent a specific, recognizable failure:

Write them in that order. Identity and scope takes ten minutes and frames everything else. The change log takes ten seconds per entry. The three in the middle, tone, escalation, and definitions, are where the real work lives, so each gets its own section below.

Tone and Voice: Write Rules You Can Test

"Sound professional" is not a rule. It is a wish. The AI already thinks it sounds professional. Tone rules only work when a third party could read an output and grade it pass or fail against the rule.

Compare:

• Weak: "Match our brand voice."
• Testable: "Never open an external email with Hey. Enterprise contacts get full sentences and zero exclamation points. Prospects who have not bought yet get shorter emails, max 120 words."

Weak: "Be friendly but professional." Testable: "Internal summaries can be casual and use first names. Anything a customer might see uses their company name on first mention, no nicknames, no emoji."

The fastest way to build this section is archaeology, not imagination. Pull the last ten external emails you were happy with and the last ten you rewrote. The differences between those piles are your rules. Common ones worth stealing:

• A banned-words list. Every team has phrases that make them cringe in their own outbound: "circle back," "just checking in," "hope this finds you well." Name them.
• Greeting and sign-off rules per audience. Who signs the email matters as much as how it opens.
• A formality gradient: internal Slack summary, internal document, customer email, public post. Four registers, one line each.
• Number formatting. Currency symbols, date formats, whether "Q3" means calendar or fiscal. This overlaps with definitions, which is fine. Redundancy between sections is cheap; ambiguity is not.

Two or three genuinely good example outputs pasted into the runbook outperform a page of adjectives. Models imitate examples far more reliably than they obey descriptions.

Escalation Rules: Teach It When to Stop

This is the section that keeps you safe, and the one most runbooks skip because it feels paranoid. It is not paranoid. It is the same tiered judgment you would give a new hire, made explicit.

Four tiers cover almost every case:

1. Proceed. Routine, reversible, internal. Summarize the Jira sprint, compile the metrics doc, draft the internal update.
2. Proceed and note. Do it, but flag it in the output. "I excluded two Stripe charges that looked like duplicates; here are the IDs."
3. Draft and wait. Produce the artifact, send nothing, change nothing. All external email. Anything touching a named key account. Anything a customer, investor, or regulator could eventually read.
4. Stop and ask. Do not even draft. Legal language, pricing exceptions, personnel matters, anything involving deleting or renaming records.

Then make the triggers concrete, because "use judgment" is tier soup. Real triggers look like: any refund over $200, any email to a domain on the key-accounts list, any task that would modify more than 20 CRM records, any request that involves an employee's compensation. Numbers and lists, not vibes.

Where you draw the line between tiers 1 and 3 is its own decision with real tradeoffs; when to let AI act without review walks through it in depth. The short version: reversibility and audience decide the tier, not difficulty. An easy task with an external audience is still tier 3.

Tooling should enforce the same shape. This is why Skopx gates actions inside your tools on your instruction and approval, and why its monitoring surfaces propose follow-ups behind an approval step instead of firing them: the platform's defaults and your runbook's escalation tiers should say the same thing. If your runbook says "draft and wait" but your tooling auto-sends, the runbook loses.

Definitions: Kill the Ambiguity Tax

Every organization runs on words that seem obvious and are not. Humans resolve the ambiguity through context and hallway conversations. An AI resolves it by guessing, confidently, and differently each time.

The definitions section is a glossary with teeth. Entries that earn their place:

• "Active customer." Paying this month? Logged in within 30 days? Contract signed but not yet onboarded? Pick one. Write it as the query you would actually run.
• "Done." In Jira, a ticket in the Done column may still be undeployed. If "done" means "in production," say so, or every status report will quietly overstate progress.
• "Revenue." Stripe can give you MRR, cash collected, or booked contracts, and they can differ wildly in the same month. Name which one "revenue" means, and name the others so the AI can use them when asked.
• "The team." Full-timers? Contractors included? The answer changes every headcount reference in every document.
• "Q3." Calendar or fiscal. Thirty seconds to write down, hours of silently wrong reports if you do not.

The test for whether a term belongs here: has it ever caused a wrong number in a real document? If yes, define it. If you are inventing hypothetical ambiguity, stop; the section should stay short enough to be read.

The Do-Not-Touch List

Implied permission is the failure mode here. An AI asked to "clean up the CRM" has no instinct for which objects are load-bearing. Explicit denial beats implied caution every time.

Real entries from the kinds of lists operators actually write:

• Never modify HubSpot pipeline or lifecycle stage structure. Editing a deal is fine; editing what stages exist is not.
• Never change Jira workflow schemes, permission schemes, or delete tickets. Comment freely.
• Stripe products, prices, and coupons are read-only. Reading charge and subscription data for reporting is fine.
• No writes to the production database, ever. Read-only queries are fine.
• QuickBooks is read-only for reporting. Nothing is created, voided, or reclassified without explicit human instruction each time.
• The /Legal and /HR sections of Notion are out of scope entirely: not read, not summarized, not quoted.

Note the shape: each line names the system, the specific objects, and the boundary between allowed and forbidden. "Be careful with Stripe" protects nothing. "Stripe prices are read-only" protects exactly what it names.

Also note what this list is not: it is not a reason to connect nothing. Connect broadly, deny specifically. An AI coworker that cannot see your CRM cannot catch what is slipping in it.

Where the Runbook Lives and Who Owns It

A runbook the AI cannot see at execution time is a runbook that does not exist. The document must be somewhere the AI reads every session, automatically, not somewhere a human remembers to paste from. If you run on Skopx, the natural home is Company Brain, where documents become searchable, cited context for every conversation; wherever you run, the requirement is the same: standing instructions must actually stand.

Ownership is the other half. A runbook with no owner drifts into fiction within a quarter. One named person approves changes, prunes dead rules, and arbitrates when two teammates want contradictory tone rules. That person does not need to be technical; they need to be the person who already fields the "is this output okay?" questions. Choosing them is its own topic, covered in who should manage the AI.

Everyone can propose. One person merges. Treat it like code review for behavior.

A Template You Can Copy

Paste this, delete what does not apply, and fill it in from real corrections rather than imagination:

AI COWORKER RUNBOOK, v1.0 (owner: NAME, updated: DATE)

1. IDENTITY AND SCOPE
You support the TEAM NAME team with reporting, drafting, and research.
You do not handle: legal matters, HR matters, pricing exceptions.

2. TONE AND VOICE
External email: no "Hey" openers, no exclamation points, company name
on first mention, sign as SENDER NAME with title.
Internal docs: direct and casual, first names fine.
Banned phrases: "circle back," "hope this finds you well," ADD YOURS.
Good examples: LINK TWO OR THREE APPROVED OUTPUTS.

3. DEFINITIONS
Active customer = DEFINITION AS A QUERY.
Done = DEFINITION. Revenue = WHICH METRIC, FROM WHICH SYSTEM.
Q dates are CALENDAR / FISCAL. The team = WHO COUNTS.

4. ESCALATION
Proceed: internal summaries, research, metric compilation.
Proceed and note: excluded data, assumptions made, records skipped.
Draft and wait: all external email, anything touching accounts on the
key-account list, anything customer-visible.
Stop and ask: refunds over $AMOUNT, legal or contract language,
personnel topics, deleting or renaming any record.

5. DO NOT TOUCH
SYSTEM: OBJECT is read-only / off limits. (One line per system.)

6. STANDING CONTEXT
Current price list: LINK. Org chart: LINK. Fiscal year starts: MONTH.
People who have left and must not be referenced as current: NAMES.

7. CHANGE LOG
DATE: what changed, one line on why.

Version one should take under an hour, because you are transcribing corrections you have already made, not inventing policy.

Keeping the Runbook Alive

A runbook is a living document or it is a dead one; there is no stable middle. The maintenance loop is simple and takes minutes:

Every correction becomes a candidate line. When you fix an AI output, ask whether the fix is task-specific or standing. "This summary missed the point" is task feedback. "We never quote churn numbers to anyone outside the exec team" is a runbook line. Add it the same day, while the example is concrete.

Review weekly for the first month, then monthly. The first weeks surface the most rules, which is why runbook edits belong on the agenda of your first week with an AI coworker. After a month, the document mostly stabilizes and the review becomes pruning: any rule nobody has invoked in a quarter is a candidate for deletion. Short documents get read; long ones get skimmed.

Log every change. One line, dated, with the reason. Six months from now, "why can't the AI touch QuickBooks?" has an answer instead of an argument.

Extend it to your automations. Standing instructions govern scheduled work too. If you build automations in Skopx, where workflows assemble from a sentence and run on schedules with versions and full run history, the runbook is where you record why each one exists and which escalation tier its output belongs to. A scheduled report is still a report; the tone and definition rules apply on Tuesday at 7 a.m. exactly as they do in live chat.

FAQ: AI Runbooks in Practice

How long should an AI runbook be?

One to two pages for a small team; rarely more than four even for a large one. Length is a cost: every rule competes for attention with every other rule, for the AI and for the humans maintaining it. If the document is growing past four pages, you are probably storing task instructions or wiki content in it. Move those out and keep only standing, testable rules.

Is a runbook just a long system prompt?

They overlap in function but not in lifecycle. A prompt is written once, by one person, and is invisible to everyone else. A runbook is a maintained team document with an owner, a change log, and review. The practical difference shows up in month three: prompts rot silently, runbooks get pruned on a schedule. Mechanically, yes, the runbook's content should reach the model as standing context in every session.

Who should write the first version?

The person who has corrected the most AI outputs so far, because they hold the largest inventory of unwritten rules. That is usually an ops lead or a team manager, not an engineer. Writing version one is transcription, not authorship: collect the last month of corrections and turn each recurring one into a line.

What if the AI ignores a runbook rule?

First check that the rule is actually reaching the model in that session; the most common cause is a runbook that lives in a doc nobody attached. Second, check testability: "be more concise" gets ignored because it is unfalsifiable, while "max 120 words for prospect emails" sticks. Third, check for contradictions between rules, which force the model to pick one silently. If a genuinely clear rule still fails intermittently, move that task up an escalation tier so a human review catches it, and note the failure in the change log.

Should each connected tool get its own runbook?

No. One runbook, with per-system lines inside the do-not-touch and definitions sections. Splitting by tool guarantees drift: the HubSpot doc and the Gmail doc will eventually disagree about tone, and the AI will meet the contradiction mid-task. The exception is a genuinely separate function, like a support desk and a finance team, which are really two AI coworkers and can carry two runbooks.

When should we write it: before or after connecting tools?

Write sections 1, 4, and 5 (scope, escalation, do-not-touch) before granting broad access, because they are your safety rails. Write tone and definitions after a week or two of real outputs, because guessing those in advance produces imaginary rules. The document is a companion to rollout, not a prerequisite for it.

Start With One Page

Nobody regrets writing an AI runbook. People regret the month of identical corrections that preceded it. Open a blank document, write the scope line, the four escalation tiers, and five do-not-touch entries, and you have already prevented the expensive failures. Add tone and definitions as real corrections arrive. Log changes. Prune quarterly.

The teams that get compounding value from an AI coworker are not the ones with the cleverest prompts. They are the ones who wrote down what everyone else keeps in their heads.