Your SOPs Are Now Agent Instructions

Your SOPs were written for people who can ask questions.

That is why they work. A new hire reads "update the lead status" and walks over to ask which status, and when, and what counts as qualified. The document only has to be roughly right because a human fills the gaps in real time.

An AI agent cannot lean over a desk. It reads what you wrote, takes it literally and acts. Which means every vague line in your process is now a place where something can go quietly wrong. The quality of your agent is capped by the quality of your instructions.

What does Anthropic say about writing instructions for agents?

On September 11, 2025, Anthropic published "Writing effective tools for AI agents, using AI agents." It is written for developers, but the principles apply to any process an agent might touch.

The line that stuck with me: when writing tool descriptions and specs, think of how you would describe your tool to a new hire on your team. Include the implicit context you would normally share, such as specialized query formats, niche terminology and how resources relate to each other.¹

That is a perfect description of what is missing from most SOPs. They leave out exactly the things the writer finds obvious.

A few more principles worth borrowing

• Do not wrap everything. Anthropic advises building a few tools for high-impact workflows rather than mirroring every endpoint, noting that "more tools don't always lead to better outcomes."¹
• Name things clearly. Use unambiguous parameter names, such as user_id rather than user.¹
• Return what is meaningful. Prioritize high-signal information, such as names over cryptic identifiers.¹
• Write helpful errors. Error messages should suggest specific fixes, not just fail with an opaque code.¹

Translate each one to a business process and you get a decent editing checklist.

What does an agent-ready SOP contain?

Eight parts. A person can skim them. An agent can follow them.

Anthropic's separate guide to building agents echoes this on the design side: write clear descriptions with example usage, edge cases and input requirements, as if documenting for a junior developer.²

What does a rewrite look like?

Here is a made-up lead-handling step, written the way most SOPs are, and then rewritten. The business is invented to show the structure, so substitute your own details.

What changed

Every line in the "after" column answers a question the "before" column left open: how fast, by what rule, with which exact words, and when to stop. A new hire would also find the second version easier to follow, which is the point. If a person can follow it without asking, an agent probably can too.

Should you use an agent at all?

Not always. Anthropic draws a useful line between workflows, where "LLMs and tools are orchestrated through predefined code paths," and agents, where "LLMs dynamically direct their own processes and tool usage." Its advice: build the plainest thing that works, and add moving parts only when they are needed.²

If your SOP has predictable steps in a fixed order, a workflow in an automation tool handles it more reliably and more cheaply. n8n's explainer makes a similar point, noting that "for some tasks, agents with fixed behaviours and clear performance metrics are better suited."³ Reserve a true agent for work where the number of steps cannot be known in advance, like researching a prospect or triaging a messy inbox.

Where do checkpoints belong?

Wherever a mistake would be expensive or hard to reverse.

Anthropic notes that agents can pause for human feedback at checkpoints or when they hit blockers, and recommends extensive testing in sandboxed environments, guardrails and stopping conditions, because autonomy raises costs and the risk of compounding errors.² Write those checkpoints into the SOP itself:

• Before sending anything to a customer.
• Before changing a record that other systems rely on.
• Before spending or committing money.
• Whenever the input does not match any decision rule.

How do you test whether your SOP is ready?

The same way Anthropic suggests testing tools: with realistic tasks and by reading what happened. Its engineering guide recommends building evaluation tasks that mirror real work, running them and reading the transcripts to find where the agent got confused.¹

The new-hire test

1. Pick one process and its SOP.
2. Give it to someone who has never done the job, with no verbal explanation.
3. Ask them to do three real examples, and write down every question they ask.
4. Add the answer to each question into the SOP.
5. Run it again with a fresh person, or with an agent, and repeat until the questions stop.

What is the practical order of operations?

Start with the process, not the tool, the case I made in Your First AI Hire Is a Writer. Document one repeated task end to end. Rewrite it with the eight parts. Test it on a human. Only then decide whether it belongs in a workflow or with an agent.

Without staff, my processes live or die by whether they are written down clearly enough to hand off to a tool or a contractor. That discipline has paid off more than any single piece of software, and it is the foundation of the system I build for clients.

The upside of this work is that it improves everything at once. A process clear enough for an agent is clear enough for a new hire, a contractor and the version of you that has forgotten how you used to do it.

Keep building.Ekai