Skip to content
ITWillRock

12 min read

SAW: self-revised agentic workflows

By Artem Panfilov

What SAW is

In the first article I described SOCIA, separation of concerns in AI. One session per concern. Five concerns: Discover, Analyze, Plan, Execute, Verify. A one-page handover file as the only interface. A gate at every seam, held by a person.

That works, and it has a cost: a person is in every round, and most rounds only need someone to check the plan against the map and say what drifted. That is a bounded task, and bounded tasks are what agents are for.

SAW stands for self-revised agentic workflows. I came up with the acronym, and that is the whole of my claim on it; the parts are all SOCIA's. I am not putting a trademark on three letters. Take that, MTV. SAW is what SOCIA becomes when you automate the rounds between the human gates. It has three moves.

First, build the system from proper skills and agents. A skill is a move inside a session. An agent is a phase with a clean handover. Each has a contract: what it reads, what it writes, what it may not touch.

Second, define and find the right gates. Every seam is one. So is every place where a claim becomes a dependency for the next step, and every place where the cost of an error jumps.

Third, put agents on the gates. A gate agent reads the contract, meaning the plan, the spec, or the previous handover, and the artifact produced against it. It never reads the producer's conversation. It returns a verdict and a drift list: what the contract asked for that is missing, and what the artifact did that nobody asked for. The producing phase revises and resubmits, and the gate runs again, fresh.

That loop is the self-revision: the workflow corrects itself without a person in every round. "Self" means the workflow, not the producer; the part that revises shares nothing with the part that produced.

Which gates stay human? Anything with consequences: merge to the main branch, touch production data, approve validation evidence, communicate with a customer unsupervised, make a decision a customer, a patient, or a regulator will feel. A named person signs each of these, as everywhere on this site. SAW automates the revision rounds before that signature, so the human gate gets cheaper, because what reaches it has survived an independent review, and rarer, because less reaches it. Not absent. The red star on our diagrams marks the person, and it does not move.

Why it works

When I was a kid I never saw my own mistakes. I saw other people's at once. A friend's homework had an error in the second line, and I saw it from across the table. Mine was fine until the teacher handed it back. Same eyes, same brain, same kind of error. The only variable was whose it was.

I did not grow out of it. The internet has a whole population built on this asymmetry: the sofa experts. They genuinely exist because of it. They cannot see one problem in their own work and will point out ours before we finish the sentence, and they are often right about ours. It is what I had as a kid, and psychologists have a name for it, the bias blind spot: we see bias in other people's judgment and not in our own.

The reviewer's advantage is not intelligence. It is distance. A different context, none of the author's assumptions, because they were not there when the assumptions were made, and nothing to defend, because the mistake is not theirs. Put the reviewer inside the author's head and the advantage is gone.

The author's window and the next windowTwo context windows side by side. The left one, labeled EXECUTE, the author's window, holds a box labeled author beside two boxes labeled fact and one labeled assumption, all drawn the same way, with a note that nothing is marked as a hypothesis. Only the diff leaves it, as a file across a dashed seam: a red dot in the gap between the windows is the file crossing, a red star above it the person who holds the gate. The right window, labeled VERIFY, a fresh window, holds two files, plan.md as the contract and the diff as the artifact, feeding a box labeled reviewer with the note no history. A measure line under both windows reads distance, not intelligence.execute: the author's windowauthorfactassumptionfactnot marked as a hypothesisgateverify: a fresh windowfrom PLAN: plan.mdplan.mdcontractdiffartifactreviewerno historydistance, not intelligence
The next concern reads the file, not the chat.

We inherited the same flaw in LLM systems, in a purer form, because a model has nothing but its context.

The same context cannot be used for the build and for the verification. A model reviewing its own output in the same window carries the assumptions that produced the error, the framing that made it look right, and the plausible story it told itself on the way. Ask it "is this correct" and it will agree with itself, hedge a little, and rationalize, because the mistake is sitting in its context as a fact.

That sounds like a personality trait. It is mechanics.

A model completes from what is in the window, and the window holds the whole path to the artifact: the assumption made in the first minute, the moment it decided the config is loaded here and not there. None of that is marked as a hypothesis. If the config decision was wrong, the window does not contain a wrong decision. It contains a fact, and when the review starts that fact is the ground the review stands on, not a candidate under test. Confidence is what a mistake looks like from the inside.

A model that has produced an answer has a strong prior toward it. Rationalization in a model is not a character flaw. It is the objective: produce the plausible continuation, and a defense of the previous answer is very plausible. In my experience, self-review in one window produces cosmetic edits, and telling the model to be very critical changes the tone, not the facts.

The defect is also usually upstream of the artifact. The model checks its diff against the plan it wrote from the map it drew. If the map was wrong, the diff is faithful to a wrong plan, and a reviewer in the same window cannot see that, because the map is the floor it stands on. In the first article's workshops, teams voted to ship finished diffs whose defects had been planted at discovery or planning.

Now connect this to SOCIA. A fresh context that holds only the contract and the artifact has nothing to agree with. It never saw the reasoning, so it cannot inherit the assumption. It has nothing to defend, because it did not write the artifact. That is distance, built in: the sofa expert's advantage without the sofa expert's blindness, because the gate never reviews its own work.

Review inside the EXECUTE window against a fresh VERIFY windowTop, one window labeled execute and verify holds the chain map, plan, diff, with the assumption in the map; a review arrow runs from the diff back to the plan and never reaches the map. Bottom, a fresh VERIFY window receives only the plan as CONTRACT and the diff as ARTIFACT, each crossing the gap between the windows through a red dot, and writes a verdict file.one window: execute and verifymapassumptionplandiffreviewthe map is thefloor; thereview nevertests itverify: a fresh windowCONTRACTthe planARTIFACTthe difftwo files in, noconversation, nothing toagree withverdict
The loop stays in the window; the gate gets two files.

A different model at the gate adds a second kind of independence, because two runs of the same model share training and failure modes, and a different vendor shares less. The first article's illustration applies: two independent checks that each miss 20 percent of defects jointly miss about 4 percent, because 0.2 times 0.2 is 0.04. That is arithmetic, not a measurement, and it holds only if the checks are independent. SAW makes the independence mechanical.

How to build one

SAW is SOCIA plus gate agents, so start with the first article: run its two-prompt exercise and hold a seam by hand, so you know what a good verdict looks like.

Skills and agents with contracts

Every phase gets a written contract: what it reads, what it writes, what it may not touch, where it stops. A skill stays a skill until its output has to survive the session; then it becomes an agent, one definition file each, committed next to the handovers.

Finding the gates

A gate belongs at every seam. Then look for two more kinds of place.

Wherever a claim becomes a dependency for the next step. The map says the payment module is not touched, and the plan builds on it. If the claim is wrong, nothing downstream can detect it. The gate's question there is "is this claim cited?"

Wherever the cost of an error jumps: before code is written, before a diff is accepted, before deploy, before data is touched. Before deploy a mistake is a rollback; after, an incident.

Gates along a change, and the cost of an errorFive boxes in a row, map, plan, diff, deploy, data. Small squares mark gate agents at the first two seams; red stars mark the two seams before deploy and before data, where the edges are dashed. Under the row a step line labeled cost of error rises at every seam, with the biggest step before deploy, from a rollback to an incident.claim becomes dependencybefore codebefore deploybefore datamapplandiffdeploydatacost of errora rollbackan incidentgate agenta person signs
A gate at every seam; a person where the cost jumps.

Then prune. A gate that never sends anything back is unnecessary or blind; plant a defect to find out which. A gate that always sends things back means the contract upstream is wrong, not the producer.

The gate agent's contract

Inputs: the artifact, and the contract it was produced against, meaning the spec, the plan, or the previous handover. Outputs: a verdict, a drift list, and the gate's own blind spots; a gate that reports no blind spots has not looked hard enough. It has no authority to fix, only to pass, send back, or escalate. A gate that can fix will fix, and then you have a second producer with no gate on it.

Paste this into a fresh session or an agent definition; fill the angle brackets.

You are the gate between <producing phase> and <next phase>.
You may not edit the ARTIFACT.

Your only inputs:
  CONTRACT: <path to spec, plan, or previous handover>
  ARTIFACT: <path to handover file or diff>
You have not seen, and must not ask for, the conversation
that produced the ARTIFACT.

Check the ARTIFACT against the CONTRACT, claim by claim.
Drift is: a claim not supported by the CONTRACT or a cited file;
a requirement missing or partly met; anything the ARTIFACT does
that the CONTRACT did not ask for.

Write handovers/gate-<seam>-round-<n>.md with exactly:
VERDICT: PASS | REVISE | ESCALATE
DRIFT:
  - <where> | <contract says> | <artifact does> | <what would pass>
BLIND SPOTS:
  - <what you could not check with these inputs, and why>
ROUND: <n> of <max>

Rules:
- PASS only if DRIFT is empty.
- REVISE if every item is fixable inside the CONTRACT.
- ESCALATE if the CONTRACT is wrong or ambiguous, if a fix would
  touch something it forbids, or on the last round.
- Do not soften a finding because the ARTIFACT looks well made.
Then STOP.

The runner fills in the round number; the gate never remembers it.

The revision loop

Something has to run the loop, a script, a pipeline step, or a person starting each round; call it the runner. It holds the round counter and passes files; it has no opinion.

On PASS, the artifact becomes the next phase's input. On REVISE, the runner hands the drift list, the contract, and the current artifact to a fresh producer session. The revision session is fresh for the same reason the gate is: a drift list fed back into the window that made the mistake invites a defense; a new session reads it as a work order. The gate then runs again in a fresh session of its own; a gate that remembers its last verdict starts to agree with itself.

The SAW loop: producer, artifact, gate agent, verdictA producer session writes an ARTIFACT file, which crosses into the gate through a red dot. A gate agent, fresh each round, reads the CONTRACT and the ARTIFACT and writes a verdict file. PASS leads to the next phase and, over a dashed edge that ends at a red star, to the person who signs. REVISE loops back into a fresh producer session, counted by the runner up to round three. ESCALATE goes to the same person. The producer's conversation sits apart with no edge to the gate.runnerCONTRACTspec or planproducerfresh sessionARTIFACThandover or diffgate agentfresh each roundverdictdrift listREVISE, round n of 3PASSnext phaseESCALATEa person signsmerge, production data,validation evidenceconversationnever readno path to the gate: itdoes not exist there
Agents revise between the gates; a person signs at the end.

Put a round limit on the loop. I set it at three, and the basis is the shape of the failures, not a measurement. Round one fixes what the gate found. Round two fixes what the fix broke. A third failure means the problem is in the contract, not the artifact, and only a person can change the contract. On the third REVISE, or on any ESCALATE, a person receives one folder: the contract, the latest artifact, and every drift list in order. Three short lists, not a transcript.

Independence rules

These rules are enforced by the environment, not by a sentence in a prompt.

The gate runs in a fresh context every round, with read-only credentials, and it has no access to the producer's transcript. Not "please do not read it": the transcript does not exist in the gate's environment.

The gate runs on a different model where you can afford it and a different vendor where you can arrange it. Shared training is shared priors, and shared priors are correlated misses.

The evaluation set the gate uses is not writable by the producer. If the producer can edit the test, it will, in good faith, adjust the test to the artifact, and the gate becomes a mirror. Every agent on this site lives by the same rule.

One named person owns each gate definition. A gate with no owner cannot be trusted.

The gate's environmentTwo outlined regions. Left, the producer on vendor A with its session and its transcript. Right, the gate on vendor B, fresh every round, holding the ARTIFACT and CONTRACT files, a gate agent with read-only credentials, a red star for the named owner, and an evaluation set the producer cannot write to. The artifact file is the only edge between the regions; the transcript has no path in.producer, vendor Agate, vendor B, fresh every roundproducerwrites the artifacttranscriptstays hereno path intothe gatefileARTIFACTCONTRACTgate agentread-only credentialsowner: a named personevaluation setthe producercannot write
The rules live in the environment, not in the prompt.

What to measure

Record four numbers per gate.

Acceptance rate: how often an artifact passes on the first round. Low means a weak producer contract or model. Very high, with defects found downstream, means a weak gate.

Revision rounds per task: the mean and the tail. A rising trend means the contracts are drifting from the work, and it shows before the escape rate moves.

Escape rate: defects found after a gate that should have caught them. For every defect found later, record which gate it passed. This is the number that says whether the gates earn their cost.

Cost per accepted change: tokens across all producer and gate rounds, plus human minutes, divided by the changes that got a signature.

Four numbers per gateFour outlined panels. Acceptance rate as a partly filled bar. Revision rounds per task as three falling bars for rounds one, two, three. Escape rate as a step line falling with one bump. Cost per accepted change as a fraction, tokens and minutes over changes marked with the red star. Each panel has a one-line reading.acceptance ratepasses, round one0100low means a weakproducer; very highmeans a weak gaterevision rounds per task123the mean and thetail; rising meansthe contracts driftescape rateper gate, over timedefects found aftera gate; record whichgate each one passedcost per accepted changetokens + minutessigned changesevery producer andgate round, dividedby signed changes
Four numbers per gate; the escape rate matters most.

What it gives you

Fully automated revision loops

The rounds between the human gates run without a person. A plan that reaches for a file the map does not list is sent back before anyone reads it. You still read the plan, once, after it has survived the gate.

Independence you do not have to remember

A fresh session per concern works when a person remembers it. Late in a long day the person does not. SAW encodes the rule in the pipeline: the gate was never given the producer's transcript. The independence is structural, so it is there at two in the morning.

Cheaper review where it changes nothing, human review where it changes everything

Most review rounds do not change the decision. They fix a citation, catch a missed requirement, or remove a change nobody asked for. A gate agent does that work. The rounds that change the decision go to a person with the drift history attached.

Measurable quality

Every verdict and every drift list is a file in the repository, so you know, per gate, what was sent back, how often, and why. When the escape rate rises, you can see which gate let the defect through. It is the change trace this site describes elsewhere, extended one level down.

Vendor-agnostic gates

The gate reads two files and writes one, so the producer can run on one vendor's model and the gate on another's. A gate on another vendor is the cheapest independence you can buy: a configuration line, and no shared training with the producer.

Where SAW stops

SAW stops at the signature.

The gates that stay human are the ones with consequences: merge to the main branch, touch production data, approve validation evidence, communicate with a customer unsupervised, make a decision a customer, a patient, or a regulator will feel. A named person signs each of these. The agents in a SAW pipeline are bounded and supervised. They revise. They do not decide. A gate agent can tell you the diff matches the plan. It cannot tell you the plan was worth doing, or answer when someone outside the team asks who approved this.

So "fully automated" refers to the revision rounds, not to the decision. The workflow revises itself. It does not sign for itself. The loop makes work match the contract; it does not ask whether the contract was right. If the map was wrong and the plan was faithful to it, every gate downstream will check faithfully against the wrong thing, and only a person reading the map with the goal in mind will notice. That is why ESCALATE exists, and why the person at the human gate reads the contract, not only the artifact.

I started with a kid who could not see his own mistakes. The kid is still here, and he now writes prompts. The fix was never to try harder to see. It was to hand the work to someone who was not there when the mistake was made and who has nothing to defend. SAW does that on a schedule, and then it puts the result in front of a person whose name will be on it.

Want a similar result?

Talk about a similar problemAbout software development