How to write an AI-first SOP

An AI-first SOP is a standard operating procedure written for an agent to execute rather than for a person to read, which means it names the task, the exact accounts and tools it may touch, the inputs, what a good result looks like, and the conditions under which it has to stop and ask a person. In current practice it takes the form of a skill: a folder holding a SKILL.md file whose YAML frontmatter carries two required fields, name and description, alongside whatever reference files and scripts the procedure needs (Anthropic Agent Skills documentation, retrieved 2026-08-22). The work of writing one is mostly the work of resolving the ambiguity a human reader would have filled in from experience, and of turning “check with me on the big stuff” into conditions a program can test.

This is where the site’s argument ends up. You do not have to wait for your apps to add AI, and the reason is that the connection between your tools and the work is now something you can own rather than something a product team has to build into a feature. An AI-first SOP is that ownership written down: the procedure, the accounts, the stopping conditions, in a file you keep. The vendor’s roadmap does not enter into it. The longer version of the argument is on the manifesto, and the vocabulary is on what Claude skills are.

What is an AI-first SOP?

It is the same procedure you already run, rewritten so that nothing load-bearing lives only in the head of the person who normally runs it. A human-first SOP can say “review for accuracy and send to the client.” An agent cannot act on that, because it does not know which client record is authoritative, which mailbox to send from, what counts as accurate, or whether sending is something it is allowed to do at all. The AI-first version answers each of those in writing.

That is also why this format is worth having even when no agent runs it. A procedure you cannot specify to an agent is usually a procedure you cannot hand to a new hire either, and the specification exposes which parts were never actually decided.

How is this different from the SOP I already have written down?

Four things change, and none of them is the writing style.

The official path is replaced by the real one. Most written procedures describe the system of record and omit the spreadsheet someone keeps on the side. Both belong in the model, and neither is automatically the authority. Recording the workaround is what makes the procedure runnable.

“It depends” has to be resolved. When a step can only be described that way, the useful question is whether the phrase names irreducible expert judgment or merely missing structure. If it is judgment, it stays with the person and the SOP routes to them. If it is missing structure, you write the structure: acceptance criteria, two or three representative examples, and the guardrails.

Roles become accounts. “The finance team” is a role. An agent needs the specific connected account, the specific mailbox, the specific workspace. A procedure that does not name them will either fail or act in the wrong place.

Supervision becomes testable. This is the largest single difference. “Ask me about anything significant” cannot be executed. Predicates can: an external recipient, a destructive operation, a permission change, money movement, an item count above a threshold, regulated data, any expansion of the declared scope. Writing those out is usually the moment a procedure stops being vague.

What does one actually look like as a file?

A short instruction file with the detail pushed into siblings it can reference. The frontmatter is what an assistant reads at startup to decide whether the procedure applies, so the description has to say both what it does and when to use it; name is capped at 64 characters and limited to lowercase letters, numbers, and hyphens (Anthropic Agent Skills documentation, retrieved 2026-08-22).

---
name: overdue-invoice-nudge
description: Draft reminder emails for invoices past their due date in the
  accounting system. Use when asked to chase overdue invoices, or on the
  Monday review. Drafts only, never sends.
---

# Overdue invoice nudge

## Account and scope
Accounting account: `<the one accounting workspace>` only. Read invoices and contacts.
Mail account: `<your own work address>`. Draft folder only.

## Trigger
Explicit request, or the Monday review checklist.

## Inputs
Invoices with status unpaid and a due date more than 7 days past.

## Procedure
1. List matching invoices. Report the count before doing anything else.
2. Group by customer. One draft per customer, not per invoice.
3. Draft using `references/nudge-tone.md`. Never state a new due date.
4. Leave every draft unsent. Report the list of drafts created.

## Never without asking
- Sending any message to an external recipient.
- Writing anything back to the accounting system.
- Any invoice outside the 7-day window.
- More than 12 drafts in one run. Stop and report.

## Verification
Re-read the drafts folder and confirm the count matches step 4.

Two structural rules keep this from turning into an unreadable wall. Keep the core procedure short and move detailed material into files the instruction file points at, so only the part a given run needs gets read. And add a script only after repeated use shows that running deterministic code is more reliable than having the agent generate the equivalent each time. The vendor documentation describes the same layering from the other direction, as progressive disclosure: frontmatter is always loaded, the body loads when the procedure is triggered, and bundled files cost nothing until they are read (Anthropic Agent Skills documentation, retrieved 2026-08-22).

Which procedures should I not turn into an AI-first SOP?

Work whose rules are still changing. Writing the specification for a procedure that will be different next month spends the effort in the wrong place, and the specification will be wrong in ways nobody notices until it runs.

The wider point is that this format is one fit among several, not the end of a sequence. Four ways of working with an AI on your own stack, each right for some work and wrong for other work:

None of these is a step toward the next. A read-only habit is the permanent right answer for plenty of work, and a written SOP is the wrong answer for anything where the definition of a good result is still moving. The full version of the table, with what each shape is wrong for, is on the manifesto.

Two more cases to leave alone. Work that only one person can describe, where writing it down would convert their tacit knowledge into something anyone can run, is not yours to specify without their agreement. And a procedure that turns out to need simplifying rather than automating is finished when you simplify it. Reshaping the work is a complete outcome, not a delay before the real automation.

How do I write down the part where the AI has to ask me first?

Classify each action by consequence rather than by which app it happens in. Read-only, internal-only, and readily reversible actions are low-consequence. Contained writes, drafts, and changes inside a shared workspace are medium. Actions that communicate externally, destroy data, alter permissions, move money, or carry legal or compliance weight are high, and high-consequence actions should never default to running unattended.

Then pick a posture per action, from a set that includes never propose it, ask every time, ask on significant actions, ask once and remember, and always allow. These are peers for a given task, not rungs. Ask-every-time can be the correct permanent setting for a step you will run for years.

It also helps to keep four permissions separate rather than treating the first as implying the rest: authorizing the connection, reading metadata, reading content, and taking an action that changes something. Connecting an account is capability, not intent. A procedure that reads invoice totals has not thereby been granted permission to read email bodies.

Where does the file live, and how does the AI reach my apps?

In a Git repository, because the useful properties of an SOP are the ones Git already provides: you can see who changed a step and when, read the diff, and revert. In Claude Code, skill folders are read from ~/.claude/skills/ for personal use or .claude/skills/ inside a project, and the project location is the one that ends up in version control (Anthropic Agent Skills documentation, retrieved 2026-08-22). One caveat from the same documentation, which is easy to get wrong: custom skills do not sync across surfaces. A skill uploaded to claude.ai is not available through the API, and Claude Code’s filesystem skills are separate from both.

Reaching the apps is a separate mechanism from the procedure file. Tool access for assistants converged on the Model Context Protocol, whose public registry at registry.modelcontextprotocol.io/v0/servers is a paginated open API whose limit parameter caps at 100 results; walking all 243 pages with version=latest on 2026-08-22 returned 24,221 distinct server names. Registry presence does not establish that a server is the vendor’s own. Two checks settle that, a reverse-DNS namespace on the vendor’s own domain or an io.github.<org> namespace whose organization owns the product’s canonical repository, and the applications that passed are on the best MCP servers page.

The credential question is where the practice diverges most from a hobby setup. The naive route is an API key pasted into a config file, which then sits in the repository alongside the procedure, expires without warning, and is as broad as whatever it was issued for. A managed connector holds the authorization outside the repository instead: Composio stores the auth config and connected account, refreshes OAuth tokens before they expire, and marks a connection expired only after refresh attempts fail, so the failure shows up as a connection status rather than as a procedure that silently stopped working (Composio authentication documentation, retrieved 2026-08-22). Either way the rule for the file is the same: no key, token, or session cookie goes in the repository.

For scale, this site publishes 589 applications from Composio’s connector catalog, which holds 1,000 in total, with a median of 19 actions retrieved each, queried 2026-08-22 from an inventory built 2026-08-14. The 1,000 is the ceiling of the tool that produced the snapshot, which records the truncation in its own metadata, so it is a floor rather than a count. The median matters more than the total. Most applications expose enough actions for a bounded procedure and not enough for an open-ended one, and the tools index has the per-application detail, including Notion, Slack and Asana.

When am I supposed to find the time for this?

Not inside the work, which is why most people who intend to write one never do. The writing competes with the doing, in the same hours, and the doing always wins because it has a deadline attached. Almost nobody sets aside time to stop working in their work and work on it, and being told that AI helps without being shown where makes that worse rather than better.

The unit that fits a real week is one procedure and one sitting, and the procedure to pick is the one you are about to run anyway. Write it while you run it, which costs the run plus some, rather than scheduling an hour you will lose. Stop at the first version. A file that names the accounts, the inputs, and the stopping conditions is a complete outcome even if no agent ever executes it, because the next person to run it by hand needs exactly those three things.

How do I keep it from going stale?

Date every claim in it and keep the date honest, then treat a correction as new evidence rather than as a replacement. When something in the procedure conflicts with what you find later, do not resolve it by taking the newer value. Newer is not the same as more authoritative, and a material disagreement should be visible and decided rather than quietly overwritten.

Four timestamps are worth keeping apart, because collapsing them is how a stale procedure looks current: when the thing happened, when you recorded it, when you last verified it, and when the source itself last changed.

The most common decay is not in the steps but in the numbers. Prices, plan gates, feature availability, rate limits, and thresholds copied from research into a procedure are not implementation truth, and they age faster than anything else in the file.

Do I have to be technical to write one?

No, and assuming otherwise is the most common reason people do not start. The belief is that AI capability sits on top of tool expertise, so you would need to be an expert in the tool before you could specify AI work inside it. The specification is about your work, not about the tool’s internals.

What it does require is answering four questions about the task, which is a different skill from knowing the software:

1. What is this task’s one job?
2. What does a good result look like, specifically enough that someone else could tell?
3. What must never happen without my approval?
4. What supervision does this task need?

An agent that has read a well-specified procedure will ask about the gaps. Answering those questions is the work, and the answers are the SOP.

The honest test of whether you have written it down is to run it in a fresh session, with no prior conversation to fill in the blanks. What breaks is what was still in your head. Test that separately from whether the output was any good, because a procedure that never triggered and a procedure that triggered and produced the wrong thing need different fixes.

What could not be established here?

• Whether this saves time, and how much. No measurement was run for this page. Any figure you have seen attached to SOP automation, including ones we might produce later, is an estimate until it is measured against the specific procedure.
• Whether a written procedure runs identically in another vendor’s assistant. The format itself is portable and published: the specification is an open standard at agentskills.io, a count of its client showcase on 2026-08-22 found 46 named products reading it, and Anthropic’s own help center states that skills you create are not locked to Claude and that the same format works across platforms that adopt the standard (support.claude.com, what are skills, retrieved 2026-08-22). What was not established is execution: no cross-client test was run here, adopting a specification is not the same as implementing every part of it identically, and bundle-level packaging is explicitly out of scope for the Skills Over MCP working group. Separately, Anthropic’s own documentation states that custom skills do not sync across Anthropic’s own surfaces (Agent Skills overview, retrieved 2026-08-22).
• How many of the 589 a person can turn on unaided. The 589 published applications were not checked for how many are reachable without an administrator enabling something first. That count does not exist yet.
• How much of a typical business is specifiable. No count exists here for how many procedures in a given company are the kind you can write down exactly. The claim that most are would be a guess.
• Whether registry-listed servers are official. The namespace is the discriminator and namespace verification was not performed for this page, so no claim is made about any specific vendor’s MCP server being first-party.
• Demand for this topic. ai first sop returns no measurable volume on Google Ads and no measurable volume in the AI channel; agentic sop returns 6 in the AI channel. Measured 2026-08-22, United States, English. Absence of reported volume is not absence of demand, since Google Ads omits keywords below a reporting threshold, and the AI channel figure is modeled from People Also Ask data rather than observed assistant traffic.
• Whether anyone has written one from this page. No reader has been observed doing so.

Sources