patrick sAIkas

Blog · August 3, 2026 · 4 min read

The SOP test: how I decide what to hand to an agent

I have a new trigger for automation, and it's a thought I used to have all the time without acting on it: "I could write a step-by-step SOP for this."

That thought is a diagnosis. If a task can be captured as a standard operating procedure, with rule-based steps and no real judgment calls, then a capable AI agent can almost certainly run it. The test I now apply before doing any repeatable task by hand: could I hand this to a new hire by writing them a clear set of instructions? If yes, I write the instructions once, and hand them to an agent instead.

Not every task passes. But far more pass than most people suspect, and the ones that pass are usually the ones quietly eating 20–30 minutes of your week, every week. Here are three of mine.

The Friday report

Every Friday morning I ran the same quality check: cross-reference a few sources, flag issues, format the output. About 30 minutes of focused, repetitive work. Every decision in it was rule-based; that's what made me catch myself mid-thought thinking about writing an SOP.

So the SOP became a prompt. I spent under 30 minutes setting up a scheduled agent that owns the whole thing, and now every Friday a Slack message arrives with the completed report: issues flagged, output formatted, ready to review. My job changed shape, from running the process to confirming the output looks right. That shape change is the whole point, and you'll see it in all three examples.

The receipts folder

Collecting receipts after a work trip is the task everyone dreads and nobody discusses: hunt down the coffee receipt, the ride share, the hotel folio, then rename everything, convert it all to PDF, and drag it into the expense platform. Half an hour, minimum, of pure clerical motion.

The before picture: fourteen files, four formats, zero naming convention.

After one trip I dumped a folder like that on Claude Cowork with instructions that were, in essence, an SOP: scan my Outlook for any receipts I missed (it found one I'd forgotten), convert everything to PDF, extract the date, vendor, amount, and purpose from each, and rename every file to a format I could drag straight into the expense platform. I walked away, came back a few minutes later to a perfectly organized folder.

If expense reports were a weekly part of my life, the same logic from the connector post would apply and I'd wire it into the expense platform directly, cutting out even the upload. For a few trips a year, the folder-in, folder-out version is exactly enough.

The deck audit

The third example runs in the other direction: not producing the work, checking it. I no longer send a deck to anyone, client or internal, without first running the deck and its source data through AI.

The SOP here is a review protocol: check every number in the deck against the source data, check consistency across slides, check whether each stated insight is actually supported by the data it cites, and flag spelling, grammar, and terminology drift. Real catches from this routine, all of which had survived human read-throughs:

  • Mistyped averages introduced while moving numbers from Excel to a slide
  • A score reported as one value on one slide and a different value on another
  • A rounding error that flipped a visual ranking
  • Inconsistencies in a yearly analysis traceable to errors in a prior year's data, which nobody had flagged in five years of running it

If you want to steal the starter prompt:

Review this deck against the attached source data; in your output, flag all data inaccuracies, inconsistencies across slides, and insights that aren't actually supported by the data. Also flag any spelling, grammar, or narrative issues. Ask me at least 5 questions to better understand the deck and source data before taking action.

The most common catch: the same number, told two ways, several slides apart.

For modest data (roughly a thousand rows or fewer), one strong model handles the audit well. For very large datasets I pit two frontier models against each other, giving deck and data to both and comparing what each finds. The reason this workflow earns its keep is simple: most data errors survive because no human reads every cell against the source twice. The model does.

What stays human

The pattern across all three: the agent runs the process, I confirm the output. What I keep for myself is everything the SOP can't capture: the judgment call on an ambiguous flag, the go/no-go on anything client-facing, the decision to change the process itself.

The test, one more time: if you could hand it to a new hire with written instructions, stop doing it by hand. Write the instructions once. The 30 minutes you spend writing them buys back 30 minutes a week, indefinitely, and the agent doesn't get bored on Fridays.