Your SOPs are your prompts, so write them for an agent

Google spent last week at Cloud Next telling companies how to build agents, and one of the features it shipped is a plain idea with a new name. In the Gemini Enterprise app, “skills” are saved shortcuts for repetitive tasks, and Google’s own examples are applying brand guidelines and formatting a report (Google Cloud). Workspace got the same thing: teams build skills, share them and call them up wherever they use Gemini.

A skill is a written procedure. Your company already has dozens of these. Some live in a binder, some in a Notion page nobody has opened since 2023, and most live in one person’s head. The companies that get the most out of agents this year will be the ones that write those procedures down well enough for a machine to follow.

Generic instructions don’t help much

There’s a research result from this month that every operator should know. A team from UC Santa Barbara and MIT tested how agents perform when they have to find and use skills on their own from a pool of about 34,000 real-world skills, instead of being handed the perfect one (arXiv). The benefit of skills was fragile. As conditions got more realistic, the gains shrank toward the results agents got with no skills at all.

What brought performance back was tailoring. When the agent refined the skill for the specific task in front of it, results improved. On Terminal-Bench 2.0, a test of command-line tasks, retrieval plus refinement raised Claude Opus 4.6’s pass rate from 57.7% to 65.5%, per the paper.

The lesson for a business is simple. A library of generic prompts downloaded from the internet won’t do much for you. Instructions written for your task, with your rules and your exceptions, will. That’s what an SOP is supposed to be.

Why your current SOPs won’t work as written

Most SOPs are written for a person who already understands the business. They say “process the refund per policy” and assume you know the policy, know where the order lives and know to call your manager when something looks off.

An agent knows none of that. It will follow what’s on the page and fill the gaps with a guess. So when you hand a procedure to an agent, the gaps become the failures.

Here’s what I’d add to any SOP before an agent touches it.

ChecklistWhat an agent-ready SOP contains

The outcome and what done looks like
Every input and where it lives
Steps written as rules with numbers
The exceptions and when to stop
Three real examples of good output
The exact format of the result

The outcome first. One or two sentences on what the task produces and who uses it. “A reply to the customer that answers their question and either resolves the order issue or tells them the next step and when it will happen.”

The inputs and where they live. Name the system, the field and the document. “Order status is in Shopify under Fulfillment. The return window is in the policy doc, section 3.” An agent can’t ask the person at the next desk.

Rules with numbers in them. Replace “use judgment on larger refunds” with “refunds over $200 go to the support lead for approval.” Every place your SOP says “use judgment,” decide whether the judgment can be written down. If it can, write it. If it can’t, that’s where the agent stops.

The exceptions and the stop. List the cases where the agent should hand off to a person: a customer who mentions a lawyer, a chargeback, an order over a set amount, anything the rules don’t cover. Make “I’m not sure, sending to a person” an approved outcome the agent is allowed to choose.

Real examples. Paste in three examples of finished work your best person would sign off on. Examples teach tone and format faster than any description of them.

The output format. If the result goes into a system, define the fields. If it goes to a customer, say how long it should be and what it must include.

Say you run a 40-person e-commerce brand and your support lead handles returns. Her SOP is probably half a page. Written for an agent, it might be two pages, mostly exceptions and examples. That’s normal. The extra page is the knowledge that used to live in her head.

The first version will be wrong, so plan to fix it

Google also announced a tool called Agent Optimizer that groups an agent’s real-world failures and suggests changes to its system instructions (Google Cloud). That tells you how the people building these systems think about instructions. They expect the first draft to miss and treat improving it as ongoing work.

You don’t need a product for this. You need a spreadsheet and a habit.

LoopHow an SOP gets better

1Run it on real cases
2Log every miss
3Group misses by cause
4Rewrite the rule
5Run it again

Most fixes come from adding an exception or an example the first draft left out.

Run the agent on last week’s real cases before it touches live work. When the output is wrong, write down why in one line. After 30 or 40 cases, sort the misses. You’ll find most of them come from a few causes: a rule that was vague, a missing exception, an input the agent couldn’t find. Fix those in the SOP, then run the same cases again.

The person who owns the task should own this loop. They know what good looks like, and they’ll spot the bad output in seconds. Don’t hand it to IT. IT can connect the systems. Only the person who does the work can write the rules.

A side benefit you’ll notice

Writing SOPs for an agent forces you to decide things your team has been deciding case by case for years. What’s the refund limit? Who approves a discount over 20%? When does a lead get handed to sales? You’ll find places where two people do the same task two different ways.

Settle those, write them down, and both your agent and your new hires get better instructions. The SOP becomes the one place the rule lives.

Keep the SOP in one place both people and the agent read from. If the refund limit changes, you change it once and the agent picks it up on its next run. Two copies, one for staff and one pasted into an agent’s settings, will drift apart within a month. Put a name and a date at the top of each SOP so everyone knows who owns it and when it last changed.

What to do this week

Pick one task your team does at least 20 times a week and that already has some kind of written procedure.
Sit with the person who does it best for an hour and rewrite the procedure using the six parts above.
Collect 30 real cases from last week, including the messy ones.
Run the procedure on those cases with whatever AI tool you already pay for and log every miss in one line.
Fix the three most common causes of misses and run it again before you consider using it on live work.