Codify Once: How to Write a Workflow Down for AI, and the One Call That Never Goes In

What Does It Mean to Codify a Workflow?

It means writing down how a recurring piece of work is done, in plain text an AI system can follow, so that later runs start from the written result.

The route is worked out first; after that, most of the attention can go to the case.

In the operating-model framework I use, this is the second verb. Codify is the firm's method written down: its standards, its checks, the rules for how a piece of work gets made.

This article sharpens that definition in one respect. The method codifies. The call on which method fits the case in front of you stays with the expert.

None of this is new as an idea. A good precedent file, a checklist or a house style has always done the same job: it saves the firm from deriving its own practice again every time.

What is new is that the written version can now be run by the system, not only read by a person. My own AI operating system runs on written procedures that the system itself follows.

A word about the sources

The external examples here come from 3 pages published by 2 AI companies (2 by OpenAI, one of them about AT&T's in-house legal department, and 1 by Anthropic), a working paper and an academic article from 2002.

None of the company pages is independent evidence. Each is a company describing its own customers, research or plans, with a commercial interest in the products it mentions.

So the point is the move they describe, which any firm can test on its own work without believing anybody's numbers. Nothing here is a recommendation to buy a product.

How Does a Watched Workflow Become a Written Procedure?

The route is worked out first, by doing the work, and then written down, so later runs start from the written result. 2 examples from very different settings show the same move.

An onboarding process, demonstrated once

OpenAI, in a guide published on 1 September 2026, describes Basis, a company that builds AI agents for accounting firms.

According to the guide, Basis "demonstrated the onboarding process once, then turned it into a reusable skill with a clear trigger, known steps, access to the right tools, and a clear definition of 'done.'"

A skill, in the page's own words, is "a reusable set of instructions and resources for a specific workflow".

A laser, aligned by trial and then by script

Anthropic, in a research preview announced on 27 August 2026, describes a setting with nothing in common with onboarding: a shared standard for AI agents to operate physical devices.

Anthropic reports that its model, Claude, adjusted a laser, watched the result through a camera and repeated, working out how each adjustment moved the beam.

According to Anthropic, Claude then "packaged what it learned into code files, writing a deterministic script", so that it no longer had to reason at each step and "the whole process could run as a single command."

In both, the route is worked out first and then written down, so later runs start from the written result.

Neither example comes from a law, accountancy or consulting practice, and carrying the move into one is my argument, not the vendors'.

An example from my own system

The covers of my newsletter are a modest example, and the one I know best. The early covers were worked out from scratch, draft by draft; the second and third each took 2 days and several versions.

In late May, once the fourth matched the look I wanted, I asked for the method to be written down, so that nobody would have to search for the context again.

It was written that night as a procedure: what starts it (a new edition needs a cover), the steps, the tools, and what a finished cover looks like. The covers of Editions 5 to 13 came from that written version.

To be precise about its scope: the procedure makes the picture and sets the lettering. The title, the words and the argument of each edition are mine.

What Goes Into a Workflow's Job Description?

5 parts: what starts the work, the steps, the tools and material, what done looks like, and where it must stop for a person. In my experience, most of what a good professional does without being asked fits into one of them.

The most useful line in OpenAI's guide is a short instruction: "Write the agent's job description."

It asks, among other things, for what triggers the work, the outcome, the context, tools and permissions it needs, and "what evidence it must produce and where it must stop for human review."

That is a kind of document a managing partner already knows how to write. A firm already writes job descriptions for the people it hires. Written for a workflow, it comes down to 5 parts.

1. The trigger

What starts the work, and what does not. "When a signed engagement letter arrives" is a trigger. "When a client needs something" is not, because nobody can tell from it whether the procedure applies.

A good trigger also says what is out of scope, so the procedure is not stretched over work it was never written for.

2. The steps

In order, including the checks a good person makes without being asked. In my experience, these are the steps that go missing, because the person who does the work well no longer notices doing them.

Watching the workflow done once, end to end, is the cheapest way I know to find them.

3. The tools and material

What the system may use, open and change, and what it may not. A procedure that names its sources is easier to check, and one that names what it must not touch is easier to trust.

4. What done looks like

The standard the result must meet before anyone relies on it, written so that a second person could tell whether it has been met.

If done cannot be described, the workflow is probably not ready to be written down yet.

5. Where it must stop

The points at which a named person decides. This part matters most. A procedure with no stopping point is hard to trust with anything that matters, because nobody has said where a person takes over.

Not every stopping point needs to be a sign-off. Some are a check against a standard; some are a window in which a person can say no. What matters is that each one is written down, with a name beside it.

An illustration

Take, as an illustration rather than a client's case, the pack a firm prepares before a monthly review meeting with a client.

The trigger is the meeting in the diary. The steps gather the month's figures and correspondence and set them against the agreed format. The tools are the firm's own records, read only.

Done is a pack the partner can read in 10 minutes. It stops before anything reaches the client, with the partner, who decides what the meeting is really about this month.

How Does a Written Procedure Get Better Over Time?

From its exceptions. The other half of codifying is improving the written version every time a case does not fit, so the improvement lives in the procedure rather than in someone's memory.

OpenAI's guide puts it plainly for Basis: "When recurring questions or exceptions appear, HR can update the skill before the next cohort."

A case that does not fit is a reason to improve the procedure, not to abandon it. Run that way, the procedure a team uses in March is better than the one it used in January.

The same guide ends its list of steps on the same note: "Each new experiment should give the next team a better place to start."

What that looked like in my own procedure

In August, run exactly as written, my cover procedure produced pictures I could not use, and I turned the cover down on publication morning.

Within about 10 minutes there were 3 new covers, and the procedure itself had changed. It now makes 5 pictures, keeps the best 3 as genuinely different ideas, installs one as the default, and there it stops.

Which cover fits the edition is my call. The written version hands over 3 options and stops there. Choosing between them is left to me.

Keep a log of the exceptions

The simplest habit I would recommend is one line per exception: the date, the case that did not fit, and what changed in the procedure because of it.

The log records why the procedure says what it says, so each change can be traced back to the case that prompted it. That is also what I would want a new member of the team to read first.

Whether the method is actually improving is a separate judgement, which the owner can make by reading the log alongside the results the workflow produces.

Keeping the exceptions log also connects to whether the team can run the system without the person who built it. A procedure whose reasons are written down can be maintained by someone who was not there when it was written.

Which Call Never Goes In?

The call on which method fits the case in front of you. A written procedure can carry a great deal of judgement: the checks, the standards, the order of work, the warning signs.

What I would keep out of it is the decision about whether this case is the one the procedure was written for.

The Anthropic preview carries a detail that stops this being a story about automation. Anthropic reports that, working with protein samples, Genentech researchers had to guide Claude to see that errors caused by foaming were "physical failures, not software bugs".

My reading is that the expert's contribution was not doing the procedure. It was knowing which kind of problem this was. The agent needed people to tell it what it was facing, and that one call decided which fix applied.

OpenAI's guide reaches the same place from the other side. On Exa, another AI-native company, it says: "People still decide which opportunities matter, which commitments Exa should make, and how external relationships should be managed."

A newer page, published by OpenAI on 21 October 2026, describes AT&T's in-house legal department and a planned system that would bring relevant precedent and past work to a lawyer's request.

The general counsel's principle is stated without qualification: "The decision making will always remain with the lawyers." The system is a plan, not a result, and I quote it for the principle.

In an expert firm, that call is a large part of what clients come to the firm for: the matter that looks routine and is not, the request that is really a different request.

Codifying the routine is how a firm protects the time for that call, not how it replaces it.

Who Should Write the Procedure Down?

The heaviest users should draft it, and the people accountable for the result should approve it and own its stopping points.

A working paper published in August 2026 adds a complication a leadership team should hear. Studying organisations that use ChatGPT Enterprise, its authors, from OpenAI, Columbia and Wharton, report "a strong negative seniority gradient in message volume".

Among adopters, early-career workers and trainees send "roughly eight to nine more weekly messages than the average active user within the same firm", while managers, directors and executives send fewer.

The authors caution that message volume is a measure of how intensively a tool is used, not a complete measure of economic importance. The version cited is a working paper.

The inference is mine: in organisations like these, the people who use the tools most are often not the people with the authority to decide what gets written down.

If codifying waits for the most senior people, it may wait for the people who, on this evidence, use the tools less.

So ask the heaviest users to draft, and keep approval and the stopping points with the people accountable for the result.

Which Workflow Should a Firm Codify First?

One that recurs often enough to learn from, matters enough to be worth the effort, and has been watched end to end at least once.

OpenAI's guide puts the first 2 conditions in one line: the workflow "should repeat often enough to learn from and matter enough to justify redesign."

There is also an older argument for going further than the obvious repetitive work.

Zollo and Winter argued in 2002, in Organization Science, that deliberate codification is relatively more effective on work that is infrequent and varied, in contrast with common managerial practice.

Theirs is a theoretical argument with hypotheses to test, not a finding. Its logic is that experience accumulates slowly on work a firm does rarely, so writing down what was learned matters more there, not less.

In an expert firm, in my judgement, that describes much of the client work itself.

My suggestion is to start where the work repeats, learn how to write a good procedure there, and then carry the habit into the rarer, more varied work where the case for it may be strongest.

The Verdict

Every time a firm works a recurring workflow out from scratch, it repeats thinking it has already done.

Writing the method down once, with its trigger, steps, tools, definition of done and stopping points, gives the next run a settled place to start.

What never goes in is the call on which method fits the case in front of you. That call stays with the expert, and a firm that has written its method down can give it more of the expert's time, not less.

A firm that writes its method down gets a year better at its own work, instead of a year older.

This is the work I do, and I run my own practice on the same kind of system.

If there is one workflow your team would most like to write down, see how the engagements work and send me a note about it.

The thinking continues in The AI Operating System, my fortnightly LinkedIn newsletter, where an earlier version of this argument first appeared.

Frequently Asked Questions

What is a codified workflow?

A recurring piece of work written down as plain instructions an AI system can follow: what starts it, the steps, the tools, what done looks like and where it stops for a person.

Some vendors call such a written procedure a skill. The name matters less than whether a second person could read it and know what will happen.

Is codifying the same as automating?

No. Codifying decides what the work is; automating decides who or what carries it out. A codified workflow can be run by a person, by a system, or by both with a stopping point between them.

In my experience, automating a workflow nobody has written down tends to automate whatever habits the last person happened to have.

What should never be written into an AI procedure?

The call on whether this case is the one the procedure was written for. The procedure can carry the checks, the standards and the warning signs. The decision about which method fits the case in front of you stays with the expert.

Who should own the written procedure?

A named person accountable for the result the workflow produces, who approves changes to it. In my view, the people who use it most are well placed to draft it and to propose changes from its exceptions.

How often should a written procedure change?

Whenever a case does not fit and the reason is understood.

One line in an exceptions log for each such case, and a change to the procedure when the owner agrees, keeps the reasons for each change in the procedure's record rather than in someone's memory.

Sources

Each page was read at the publisher's own site on 27 October 2026; the 2002 article's abstract was read through its DOI record. The first 3 are organisations describing themselves.

• OpenAI, How AI-native companies turn workflows into operating capability, 1 September 2026.
• Anthropic, Previewing the Model Hardware Standard, 27 August 2026 (a research preview).
• OpenAI, How AT&T is rethinking in-house legal work with OpenAI, 21 October 2026.
• Aaron Chatterji, David Holtz, Neel Rakholia, Prasanna Tambe and Gawesha Weeratunga, How Organizations Use AI: Evidence from ChatGPT, arXiv working paper, August 2026.
• Maurizio Zollo and Sidney G. Winter, Deliberate Learning and the Evolution of Dynamic Capabilities, Organization Science 13(3), 339-351, 2002 (DOI 10.1287/orsc.13.3.339.2780).

Dr Bruno Oliveira — PhD · Associate Professor, University of Bath. Founder of GustoMind.ai. Builds and installs AI operating systems for expert-led firms, running the same system daily in his own work.