Susan’s CSR queue shows forty-three replies waiting for a human eye. Twenty-two of them were drafted by Claude. Twenty-one were drafted by Susan. Nobody on the team can tell you, at a glance, which is which.
Ask the head of ops in Monday’s standup what the AI is actually doing. She has an answer. It is a three-word answer. “It helps with email.”
Ask her who owns whether it is doing that well. Silence.
Ask her how she would know if it drifted. A pause, then “we’d catch it in review, probably.” Which review, and by whom, and against what standard, nobody has written down.
This company adopted AI six months ago. There is a document in the shared drive titled “AI Use Policy.” Everyone signed it. Nobody has re-read it since. It talks about safe use of confidential information and appropriate reliance on human judgment. It does not describe a single job.
Six months of Claude drafts have piled up in the queue and nobody can tell you what the tool is supposed to be doing. Just that everyone signed off on it being used.
Here’s the thing. That is not adoption. That is hoping.
The document you have is a permission slip. The document you need is a job spec.
Most of what is being written as “AI policy” this year is a permission document. It describes what employees are allowed to do with the tool. Do not paste client data into a public chatbot. Do not present AI output as human work without review. Do not use the tool for medical, legal, or financial advice.
Yeah. All fine rules. All useless as an operating standard.
A permission document tells a person what they may not do. An operating standard tells a station what its job is. Those are two different conversations, and companies keep mailing the first one and calling it the second one.
The handbook is not a permission document. It is the operating standard for each AI role.
If Susan’s CSR-drafting station has never been given a job, then Claude in that queue is a very fast intern who was handed the intake email address and told to have fun. Susan is doing the same review she was doing before Claude arrived, on twice as many emails, half of which she has to read line by line because she has no baseline for what a good one from the tool even looks like.
That is not an AI problem. It is a management problem, and the tool is exposing it.
What the real handbook looks like, station by station
You cannot write one vague page for “AI at the company.” A vague page produces vague work. What you can write is a repeatable section, one per AI role, that tells that specific station what it owns.
We already have a name for the anatomy this needs. It is called the Professional Recipe, and it has seven ingredients. Training. Context. Guardrails. Examples. Format. Escalation. Feedback. The first five are the setup you write before the station opens. The last two are how the station runs once it is open.
That is not the whole piece. This is a series, and the child pieces will walk each ingredient one at a time. The parent shape is what matters right now.
The parent shape is a page per station. Every AI role in the company gets one page. Not a spreadsheet. Not a philosophy statement. A page.
Take Susan’s CSR-drafting station. Name the work it owns. Draft first-pass replies to inbound customer email. Name the inputs. The incoming email, the customer’s account history, the last three interactions on record. Name the output. A written draft ready for Susan to review, sent in the shop’s voice, with any dollar amount or timeline flagged in brackets. Name what it cannot do. Cannot quote a firm price. Cannot promise a service window. Cannot process a complaint that includes injury language. Name who checks it. Susan, before the reply ever leaves the queue. Name how you know it worked. Reply time on standard tickets is down, escalations are flagged before Susan opens them, complaint-language catch rate is at ninety-five percent or higher.
That is one page. It is not exhaustive. It is enough for Susan to know what to expect from Claude, and for the head of ops to know what the station is supposed to produce.
Now do it for the dispatch helper that recommends which crew gets which job. Different inputs. Different output. Different forbidden work. Different checker. Different page.
You do not write these all at once. You write the one that hurts most first. The Prep List tells you which one that is. But the shape of the page does not change from station to station. That is what “company-wide” actually means. Not one policy for all AI. One repeatable spec, filled in per station, collected in one binder.
Why this hits Ops the hardest
If you are the person running ops in this business, you already knew this. You have been the one Monday-morning-quarterbacking the CSR queue for six months. You have been the one nodding through the policy signing ceremony and then quietly triaging the actual mess in the shared drive.
You knew the document was wrong before you signed it. You just did not have a name for what it was missing.
Here’s the thing. The document was not missing rules. It was missing jobs.
A policy grades the human. A job spec grades the station. The person can behave perfectly correctly under the policy and the station can still produce completely useless output, and by the end of the quarter you will not be able to tell the two situations apart.
Does that make sense? You need the second document to know whether the work is any good.
I have literally watched this happen in three different companies this year. The pattern is identical every time. The company signs a policy. Six months later, somebody on the ops side pulls a random week of AI-drafted work and cannot tell whether it is on standard, drifting, or actively creating small compounding messes that will surface as a client complaint next quarter. Nobody can answer because the standard was never written.
The Chef of the kitchen has to be able to walk to any station, taste one dish, and say “this is on standard” or “this is not.” That is not possible if nobody wrote what “on standard” means at that station. Not once. Not for that dish. Not with examples.
The move is to write the job before the shift starts
The habit to break is announcing AI roles before defining them. Every time a tool gets deployed with permission but no spec, the operator is telling the team “figure it out.” Six months of “figure it out” is what turns into the CSR queue where nobody can tell Claude from Susan.
The move is not faster policies. The move is to stop confusing the two documents.
Right? If your business needs a rule about not pasting client data into a public chatbot, write that rule. It belongs in the employee handbook. It is not the AI handbook.
The AI handbook is what the stations run against.
The Monday Move
Run the One Station Job Spec.
Pick one AI job currently running in your business, or one you have been meaning to hand off but have not yet. Not “AI at the company.” One station.
Write one page with seven fields:
- Station name.
- The work it owns.
- The inputs it needs.
- The output it produces.
- What it cannot do.
- Who checks it.
- How you know it worked.
Fill each field in the language the person actually doing that work would use. Not the language of the policy document. The language of the station.
Guardrail: do not write one vague page that tries to cover “AI in the company.” Write a page per station. If you have three AI-touched stations right now, that is three pages, done in three sittings. The company-wide handbook is the binder those pages sit in, built up over months. It is not one document written in a weekend.
Next step: choose three past examples of that station’s work and draft the first small test set. If you cannot fill the seven fields yet, the handoff is not ready. Write the job before you hire the tool.
The close
The handbook is not a permission document. It is the operating standard for each AI role.
If nobody in your business can look at a station and tell you what it is supposed to produce, what it cannot do, and how you would know if it drifted, then you do not have AI work. You have a queue.
Original framework. Distilled from operator work. This piece names the Professional Recipe. More at incrayon.com/frameworks/professional-recipe/. First of the AI Employee Handbook series. Child pieces follow on job specs, standards, tests, handoffs, and review rhythm.
~ source material · Original framework. Distilled from operator work.
