Keep Your AI Workflow on the Right SOP Version

Your team changes the onboarding process. Someone updates the document. The AI still prepares tomorrow's checklist from the old version.

Now the founder has another recurring job: remembering which instructions count.

For a founder-led service business, this is a useful place to tighten an AI workflow. Give each important source an owner, an explicit scope and a rule for when it applies. Then check that the workflow actually retrieves that source.

A folder of accurate documents can still produce the wrong answer if the workflow chooses the wrong one.

Start with one repeatable job

Consider a fictional design studio using AI to prepare an internal onboarding checklist. The workflow reads an approved project brief and the applicable standard operating procedure, or SOP. A coordinator reviews the checklist before contacting the client.

The agent can look up approved references and draft the checklist. It cannot send messages, promise a delivery date, grant access or change the client's scope. This is an illustrative design, not a description of a deployed Flow system or a client result.

The team has three documents:

• Onboarding SOP v2: Approved for standard projects starting before March 15
• Onboarding SOP v3: Approved for standard projects starting on or after March 15
• A draft process note: A proposed experiment that has not been approved

For a project starting March 12, v2 still applies. The later document exists, but it governs a different set of projects. A recent edit to the experiment note gives it no authority over either SOP.

Write that selection rule once. Otherwise, the founder remains the person everyone asks to interpret the folder.

Separate the three dates that matter

Use different fields for different questions:

• Last edited: When did someone change the file?
• Effective from or applicable period: When and for which work does the approved instruction apply?
• Last verified in the workflow: When did someone check what the AI could actually retrieve?

A file edited today might describe a process that starts next month. A file unchanged for six months might still be the approved rule. Neither timestamp resolves its authority by itself.

Record who can approve a revision and what it replaces. If two approved documents conflict for the same work, the workflow should return the conflict to that person. It should not blend the instructions into a compromise nobody approved.

Anthropic's context-engineering guidance recommends selecting relevant information and describes using references to retrieve material when needed. Metadata such as names, locations and timestamps can help interpret that material. It does not make a timestamp a business approval. Read Anthropic on context engineering.

Keep a small source register

Start beside the existing workflow documentation. A short table or structured note is enough for a first pass; another knowledge platform is optional.

For each source the workflow needs, record:

• Its location and a stable identifier, if the tool provides one
• The person accountable for its content
• The version and approval status
• The service, project type or other boundary it covers
• When it becomes applicable and when it stops applying
• What replaces it, if anything
• Who checks that a change reaches the AI workflow

Keep draft, approved and superseded distinguishable. These are proposed working labels, not a universal software standard. An approved document may still be ineligible for this particular project.

In the studio example, the coordinator selects the project start date from the approved brief and checks the source register. If the date is missing, the checklist pauses with that specific question. The agent does not guess the date to finish its task.

The FlowOS approach keeps source information, ownership and boundaries available with the work, and routes exceptions to a named person. Maintaining this register is a practical application of that approach, not a claim that a particular integration is available today.

Check the copy the AI actually uses

Ask the implementer one concrete question: does this workflow open the source when it runs, or search a separately stored copy?

If it uses a search index, an uploaded file or another cached copy, changing the original may leave that copy behind. The update path needs its own owner and verification.

Microsoft's Azure AI Search documentation gives a specific example: indexers detect changed Azure Storage content, while deletion detection requires its own strategy. Updating a source and removing obsolete search content are separate concerns. Those details apply to Azure AI Search; check the behavior of your own tool. Read Microsoft's change and deletion guidance.

Have the implementer demonstrate which version a representative request retrieves after a change. Inspect the returned content and source reference. An upload confirmation alone does not show what the next request will use.

Preserve old versions according to your retention rules. Where they still govern older projects, keep them available only in that appropriate scope. Making a document ineligible for a current task does not require destroying the historical record.

Carry the source record with the draft

The coordinator should not have to reconstruct the AI's inputs from memory. Ask the workflow to include a short internal source record:

Project and task: Fictional standard-design onboarding checklist

Applicable fact: Project start date March 12, from the approved project brief

Selected procedure: Onboarding SOP v2, applicable to projects starting before March 15

Source reference and retrieved version: The actual document link and version returned by the tool

Checked at: The recorded retrieval time

Unresolved questions: Any missing fact or conflicting instruction

Record references from the retrieved material rather than letting the model invent a document name or version. A citation still needs checking: it may point to the wrong edition or fail to support the checklist item.

Keep the input set limited to this task. Use material you are authorized to process with the chosen service, and have the implementer enforce client and project access boundaries. Instructions in a prompt do not replace access controls. Another client's brief should not enter the context just because it looks like a useful example.

Copy this source-change checklist

Use this when an approved procedure changes. It is a proposed operating aid, not a certification of system safety.

• What changed, and who approved the exact revision?
• Which work uses the new version? Which work still uses the old one?
• Are the effective date and replacement relationship explicit?
• Which uploaded copies, search indexes or saved briefs need updating?
• Who owns each update, and what evidence will show it reached the workflow?
• Does a representative request retrieve the expected version and content?
• Does a request outside that version's scope stay on the correct procedure?
• If the source cannot be verified, where does the unresolved work go?

Set review timing around how often the underlying information changes and the consequence of using it incorrectly. A change to a live procedure should trigger a check of affected drafts; it need not wait for the next routine review.

Start with the SOP your team asks you about most. Make its authority, scope and update path visible. Then let the coordinator use that record to review the next checklist.

The useful outcome is fewer routine questions that only you can answer, while the decisions that need your judgment remain yours. That creates room to put your attention where you intended it to go.