The operating loop
What I have learned about keeping an AI-assisted workflow useful after the first successful draft or build.
First published 16 May 2026. Revised 26 September 2026 to clarify the argument and remove unsupported estimates and superseded descriptions of my workflow.
After the first result
The first working version of an AI-assisted task can be encouraging. The harder test comes when the source changes, the conversation loses context, or someone else has to pick up the work.
My own use spans writing and software. Both require me to keep track of what was asked for, which material the answer rests on, what has been checked, and what still needs doing. I call that repeated movement from brief to work to verification the operating loop.
The tools in my workflow have changed since I first wrote this essay in May. The earlier version described a division of labour among Claude, Codex, and Gemini that is no longer my current setup. The more useful subject is how the work remains understandable when the tools change.
Keeping the brief intact
A task rarely stays exactly as it began. An initial draft prompts a correction; a product test reveals a missing state; a new source changes a conclusion. If the next attempt remembers only the latest instruction, it can fix one problem while restoring another.
I therefore keep relevant instructions and earlier decisions in an organised workspace and bring them into the task when needed. The important part is selecting the material that applies. A saved note can be stale, and a rule written for one kind of document may be wrong for another.
A useful brief says what the finished work must let someone do. For a website, that includes reading it and using its controls. For a letter, it includes the relationship, the purpose, and the facts the writer can stand behind.
Checking the right thing
A successful build tells me that the code met certain technical requirements. It does not tell me whether a heading makes sense, a phone layout is readable, or a link reaches the intended destination. Those need their own checks on the result.
The same distinction matters in writing. A factual claim needs a source appropriate to the claim, and the source still needs to be read correctly. Retrieving a document does not make every inference drawn from it true.
Mechanical writing checks can catch repeated text, missing material, or some unwanted phrases. They cannot establish that a paragraph sounds like its author. I still have to consider what the reader knows, why each paragraph is there, and whether the piece develops a thought rather than performing a style.
Leaving a usable state
When work stops, the next person or session needs to know what actually happened. A drafted message has not been sent. A local preview has not been published. Files arriving at a destination do not prove that the receiving application can open them.
Those distinctions sound small until they determine the next action. Recording the state precisely helps avoid both duplicated effort and premature claims of completion. It also makes failures easier to investigate: the point where the work stopped is visible.
I want the workflow to make recovery ordinary. If a check fails, preserve the work, identify the cause, and continue from the last state that can be demonstrated.
Taking the lesson into an institution
A personal workflow is a place to learn, but it is not proof that the same arrangement will work in a ministry or public enterprise. Institutions have their own access rules, approval chains, records, and responsibilities. A system has to fit those conditions before it can be relied on.
I would start with a bounded task, an accountable owner, and evidence of how the result performs in ordinary use. The questions are practical: can someone check the answer, correct it, recover from failure, and explain what happened afterward?
That is the part of AI adoption I find most interesting. It brings the quality of an individual output into contact with the habits and obligations of the people who have to use it.