From SOP to AI workflow: a worked business example.

Start by defining the job: the information it needs, the decisions it can prepare, the exceptions it must expose and the output someone will use. A written standard operating procedure (SOP) can supply much of that material. A person demonstrating the work can supply it too.

Illustration: prepare a weekly delivery brief.

An invented engineering firm wants a draft briefing for its project leads. Each week, an operations coordinator reads the project tracker, approved change log and meeting notes, then flags commitments at risk and decisions that need an owner. The project lead checks the draft before the meeting.

The existing procedure says, “Review project status and summarize important changes.” The coordinator knows what that means. A reusable workflow needs the rules behind it.

Define the handoff before listing the steps.

Each item in the brief must name the project, the relevant commitment, its source, any unresolved issue and the person who needs to act.

The handoff ends when the project lead receives the draft and open questions. Updating project dates or notifying customers would require separate rules and permissions.

Give each input a job and a source of authority.

The project lead sets one rule for this illustration: a date proposed in meeting notes cannot replace an approved date unless the change log confirms it.

Begin with permitted files or exports if they serve the job. A live connection can be considered later when freshness or repeated preparation makes it useful. The skills and MCP guide explains that choice.

Ask the expert about the awkward cases.

Have the person demonstrate a routine example and one that required judgment. Ask what they trusted, what they questioned and what would have made them stop. Record any checks missing from the written procedure.

For this illustration, the approved date is 6 November. Meeting notes suggest moving it to 13 November, but the change log contains no approval. The intended draft should preserve 6 November as the approved commitment and flag 13 November as a proposal awaiting confirmation. If no decision owner is recorded, it should say so.

Write the method in a form the AI can use.

The open specification provides a small metadata header and a Markdown body for instructions. Supporting reference files and templates can accompany it. Anthropic also describes creating skills by explaining a workflow in conversation, then reviewing and testing the resulting package. (Specification, creation guide)

This abbreviated instruction excerpt is illustrative. It omits the actual reference files and has not been executed as a skill.

---
name: weekly-delivery-brief
description: Prepare a draft weekly delivery brief from a project tracker,
  approved change log and meeting notes for a project lead to review.
---

# Prepare the delivery brief

1. Confirm that the required files cover the requested reporting period.
   If a required file is missing or outdated, identify it and ask for it.
2. Use the project tracker and approved change log to establish commitments.
   Keep proposals in meeting notes separate from approved changes.
3. Draft each item with its project, approved commitment, source reference,
   unresolved issue and decision owner. Mark an absent owner as unassigned.
4. Check each date and approval statement against its cited source.
5. Return the draft and open questions for the project lead. Do not change
   source records or send the briefing to other people.

Review the instructions with the practitioner and resolve disagreements about which record controls the date. The final instruction states the intended boundary; it does not disable tools. Match the application's permissions to the task. (Agent Skills application integration guide)

Try fresh examples before calling it ready.

Keep the examples used to explain the job, then add fresh cases: complete inputs, conflicting dates, a missing owner and an outdated file. Write the expected behavior for each before running it.

In the invented date-conflict case, a brief that silently adopts the proposed date should fail review. The expected draft preserves the approved date and flags the proposal. These are review criteria, not results from a test run.

Record what happened, revise the instructions where needed and try the earlier cases again. The testing guide shows how to keep that review concrete.

Make the workflow available to the people doing the job.

Assign an owner to the skill, keep its reference material together and show the intended users how to supply inputs and review the draft. Changes to the procedure should lead to a review of the skill and its tests.

Hand over the maintained package with instructions, reference rules, exception handling and output templates. Include separate test inputs and expected outcomes, the performance record from those tests, and notes on how to run, review and update the workflow. Name its owner and where the maintained version lives. Review package security and access controls before extending its reach.

Fully Powered Studio supports this capture work: bringing together documented procedures, informal routines and expert judgment as AI workflows the team can run and improve. A business establishing a new function can start with selected workflow foundations and an agreed standard instead.

Explore Capture what works for the implementation approach.