Operating procedures for an AI that won’t sit still
Your SOP folder was written for a world where tools changed every five years. AI tools change every five weeks. Rewrite the manual around outcomes, not vendors.
Most of the operating procedures on the shared drive are already wrong. They name a tool that got deprecated, a model that got renamed, a vendor that got acquired, or a workflow that quietly moved to a different team six months ago. This was annoying in 2021. In 2026 it is a strategic problem, because the part of your business that uses AI now turns over every quarter, and the part of your company that writes SOPs still reviews them once a year.
The fix is not to write SOPs faster. The fix is to write SOPs differently. Describe the outcome, the contract, and the owner. Stop describing the tool.
Why the old SOP format breaks
A 2019 SOP says “In Zendesk, click Macros, select Refund-Full, paste the order ID.” A 2026 SOP written in the same style says “Ask the assistant to draft a refund message using the v3 prompt template in the refunds folder.” Both are wrong within a year. The first one rots because Zendesk moves the button. The second one rots because the prompt template gets replaced, the model provider deprecates the version you were using, or your team switches to a different assistant.
Industry writeups this year landed on a label for the rewrite: living SOPs. The real change is subtler. The best operating manuals we see now describe the job in three layers: the outcome the business needs, the contract that defines “done,” and a thin, swappable layer at the bottom that points to whatever tool currently satisfies the contract. When the tool changes, you only edit the bottom layer.
Outcome, contract, tool - in that order
An SOP that survives an AI reshuffle looks like this. The outcome is “customer receives a correct refund confirmation within 15 minutes, with PII redacted in the ticket log.” The contract is a short list of what a good response looks like, plus the audit log requirements. The tool section is a paragraph that says which assistant, which prompt version, and which escalation path - and it gets a separate review cadence from the rest.
This sounds like paperwork. It is not. It is the difference between a team that survives a model swap in a Tuesday standup and a team that loses a sprint to rewriting every procedure because the vendor put out a new SDK. We wrote about the same pattern from the engineering side in our note on why most AI pilots stall before production. The production-readiness checklist there is just the engineering mirror of this SOP structure.
Put a review cadence on the fast-moving layer
The outcome layer changes every few years. The contract changes maybe once a year. The tool layer should have its own calendar. Every quarter, the team that owns the SOP looks at that bottom paragraph, checks whether the model is still the best fit, whether the prompt still passes its eval, whether a cheaper tool now does the job. If nothing changed, the review takes ten minutes. If something changed, you rewrite fifteen lines, not fifty pages.
The teams that do this well treat the review the way good engineering teams treat dependency updates. Boring, scheduled, owned. Not a fire drill every time OpenAI or Anthropic ships a new release.
Name the owner, or the SOP dies
Every AI-adjacent SOP needs a named owner - not a team, a person. The owner is responsible for the tool paragraph. They are allowed to change it without a committee. They are also the person who gets paged when the SOP is wrong. Without that single throat to choke, the SOP drifts, and drifted SOPs are worse than no SOPs at all. We see this in every strategy engagement: the companies moving fast have names on the procedures, not department boxes.
What to do this month
Pick three of your most-used procedures. Rewrite each one in three layers: outcome, contract, tool. Put the tool layer on a quarterly review. Assign an owner. Delete everything else in the document that is not one of those three things. You will be surprised how short the new version is, and how much longer it lasts. Teams that want help threading this through their process automation and customer-facing AI usually start with a workshop on exactly this pattern; see our process page for the shape it takes.
The company that is still shipping AI in 2028 is the company whose operating manual can be rewritten in a week, not a year. That is not a tooling problem. That is a format problem, and it is one of the cheaper things on the list to fix.