Workflow 006: Pareto, The SOP Builder

If I had to hire ten employees or build ten agents tomorrow, it would be easy.

Not because I'm fast. Because every repeatable process in my business is already written down.

An SOP builder is an agent that takes a recording, a transcript, or a walkthrough and turns it into a formatted standard operating procedure, written so that both a person and an AI can follow it. Mine is called Pareto. I hit record, talk through what I'm doing, and get back a document I can hand to a new hire or turn straight into an agent.

That second use is the one people miss. The SOP is not paperwork. It's the raw material an agent gets built out of.

What this replaces

Documentation as a chore nobody does.

Most people hear "SOP" and flinch. Writing down what you're doing while you're trying to do it feels like a tax on real work. So it doesn't happen, and the process stays in somebody's head.

Then AI arrives and the bill comes due. Around 95% of businesses lose money on AI, and it's rarely the tool's fault. They downloaded a skill, grabbed a workflow off the internet, bolted it onto something that was never documented, and it didn't move anything.

You cannot automate a process you haven't described.

Blueprint

Give the agent raw material. Get back a structured SOP.

Trigger: manual, whenever a process is worth capturing. Input: a recording, a transcript, a screen share, or you talking through the steps out loud. Output: a formatted SOP that a human can follow on day one and an AI can be built from.

The important design choice is that last part. Most SOP templates are written for people. Pareto writes for both audiences at once: clear enough for a new hire, precise enough that the steps can become an agent's instructions without a rewrite.

Organize

What you need before you start:

• A way to capture: screen recording, a meeting transcript, or just a voice memo of you narrating the work
• Agreement on what a good SOP looks like in your business: same headings, same level of detail, every time
• One place where finished SOPs live, reachable by both your team and your agents
• A list of the processes worth capturing, starting with anything that repeats and produces the same output every time

That last filter is the whole selection criteria. If it happens more than once and the result should look the same each time, document it.

Systematize

The build is one prompt, saved as a skill. The quality comes from teaching it what good looks like.

You are [AGENT NAME], my SOP writer. I'll give you a recording, a
transcript, or a description of a process. You turn it into a standard
operating procedure.

Write every SOP so two different readers can use it:
- A new person who has never done this task
- An AI agent that will be built from this document

Use this structure every time:

1. TITLE: the outcome, not the activity. "Publish the weekly newsletter,"
   not "Newsletter stuff."
2. PURPOSE: one sentence on why this exists and what it produces.
3. TRIGGER: what starts this. A time, an event, a request.
4. WHO OWNS IT: the role responsible today.
5. TOOLS AND ACCESS: everything needed before starting.
6. STEPS: numbered, in order, one action each. Use concrete verbs. Name
   the exact buttons, files, and fields. Never write "manage" or "handle."
7. DECISION POINTS: every place a judgment call happens. State the
   condition and what to do in each case.
8. DEFINITION OF DONE: what the finished output looks like, specifically
   enough that someone could check it.
9. EXCEPTIONS: what to do when it goes wrong, and when to escalate to a human.

Rules:
- If the source material skips a step or leaves something ambiguous, ask
  me rather than filling the gap yourself.
- Write in plain language. No jargon the next person won't know.
- Keep steps atomic. One instruction per step.
- Flag any step that needs human judgment, so I know what can't be automated.

When the SOP is done, tell me whether this process looks like a good
candidate to become an AI agent, a good candidate to delegate to a person,
or something that should stay with me. Explain why in two lines.

How to set it up

1. Save the prompt as a skill.
2. Test it on a process you know cold. You'll spot the gaps immediately.
3. Correct the output and fold your corrections into the file. It learns your standard.
4. Once the format is right, use it on everything: hit record, talk, get an SOP.
5. Keep the finished documents in one library, not scattered across people's drives.

Assign

What the agent does: structure the process, write the document, spot the missing steps, and tell you which parts need human judgment.

What stays human: knowing how the work actually happens, and deciding who owns it once it's written.

Here's the loop that makes this the most useful workflow in my stack.

The inbox agent and the meeting agent from the last two days were both built out of SOPs. My assistant had already written down how she managed my inbox. I had a process I followed before meetings. Those documents became the agents.

So the SOP builder is quietly an agent generator. Document a repeatable process, and turning it into a skill is the easy part afterward.

And there's a benefit nobody mentions until they've run agents for a while.

Because I wrote the standard, I know when the agent is wrong.

If you never defined the output, you have no way to tell whether the thing running unattended every morning is doing its job or drifting. The SOP is the reference. It's how you supervise something that works while you sleep.

Rule of thumb from this build: document it, then decide who runs it. Not the other way around.

Integrate

The SOP library is the layer everything else sits on:

• Repeatable processes get documented first, before any decision about automating
• Documented processes become agents, or job descriptions, or onboarding material, depending on what the Assign call says
• The SOP stays the reference for checking whether the agent is still doing it right
• When something changes, the document gets updated and the agent gets rebuilt from it

Ten new hires or ten new agents becomes the same problem: hand them the library.

Tomorrow: the templates skill. The assets your agents reach for when they build something.