Editing and revising

You never have to wait for a workflow to break before improving it. A rule changed, approvals go to someone else now, the tax rate moved, a branch the real world just invented: all of that is an ordinary edit, in either stage.

How the edit lands depends on whether the workflow has code yet.

While it is still learning

Nothing special happens. Keep talking to the assistant, let it rewrite the SOP, and publish again. The next run executes the new instructions.

The same is true of reference files and connected systems. There is no code written against them yet, so a change is just a change.

Once it is codified, three doors

A codified workflow has steps that were written against a specific SOP and specific reference files. Three things can change that definition:

1. A reference file change. Upload, replace, delete, or keep a file a run produced.
2. Promoting a pending SOP revision. The proposed revision sitting in the Versions tab with its own Accept button.
3. Saying what should be different. The SOP panel carries a card headed Change this workflow, with a hint inviting you to say what should be different so the platform can work out what it means for the steps. The placeholder is a good example of the register: stop cc'ing finance on the confirmation.

Adapt or reset

The first two doors ask you a question before anything is written. A sharpened sentence and a genuinely changed procedure look identical from outside, and guessing wrong means either a silently broken workflow or a silently discarded codification. So the platform does not guess.

The dialog says: this workflow has codified steps. The steps were written against how the workflow looked before, nothing can tell a small clarification from a real change, so you decide. Then two options:

Adapt the steps. Opens a chat that works out what the change means for the code. Nothing changes for running work until you confirm it. That last sentence is the whole point of the question: between your answer and your confirm, no run's pinned version has moved.

Go back to learning. Drops the steps. The change applies now, and the workflow runs with a human again until it is re-codified.

Not now closes the dialog and abandons the change. Nothing was written, because the question is asked before any write.

What a revision interview does

It is the same authoring surface as codification, pointed at a change instead of a blank page. The new SOP and the new files are in the workspace as what you want the workflow to be. The existing steps are what it currently does. The agent reads the two against each other.

Three things worth knowing about how it behaves:

• "Nothing needed to change" is a real answer. Most SOP edits sharpen a sentence and most file swaps are this month's version of last month's file. When the steps already do what the new description says, the agent says so in one sentence and changes nothing. Your confirm still mints a version, because the SOP and the file are part of what the workflow is even when no code moved.
• Step identities are fixed. A step's contents can change freely, but its id never gets renamed or renumbered, because your run history and your failure reviews point at it.
• It changes as little as it can. Everything the accepted runs already prove correct has to keep working. A step edited for no reason is a step whose accepted runs no longer prove anything.

If the change is too big to adapt, the agent recommends stepping back to learning instead of papering over it, and you decide.

When a codified run fails

A failed step does not get repaired mid-run. There is no silent self-healing here, by decision: repair at run time is a pattern that has been shipped elsewhere and torn back out, because the fixes cascade and the configuration mutates where nobody can see it.

Instead:

1. The run stops and is recorded in full, with the failing step's inputs, its error, and everything that already succeeded.
2. A review lands in your Inbox as a failed run, with the options Open the repair, Demote to learning and Dismiss.
3. A repair interview opens on that exact failure, seeded from the version that actually ran.

The repair agent reads the run before it touches a file: the error in full, the inputs the failing step was given, every step that ran before it and what each produced. The answer is usually in the inputs rather than the traceback.

Then it makes the smallest change that fixes it, and you confirm. A notification tells you a fix is ready, because you do not live in the chat thread.

Confirming promotes a new version and resolves the review in one go. It refuses outright if a different version has landed since the repair started, since the fix was authored against a baseline that no longer exists.

Stepping back to learning

Some failures are not bugs. The inputs changed shape for good, the procedure moved on, the workflow is now doing something the SOP never described. Patching the code would hide that, and the next run would fail differently.

For those, the agent recommends a demotion and you confirm it. What happens then:

• The workflow returns to the learning stage and runs agentically again, with you in the loop.
• The accepted runs are kept. Everything it learned stays valid; new examples accumulate beside them.
• The SOP is revised with the failure mode, so the thing that broke is written down.
• The work item that failed still gets done. The failed trigger is re-dispatched through the agentic path, which also makes it a fresh example of the branch nobody had seen.

That last point is what makes a demotion survivable on a busy workflow. Suppose a hundred events arrive while it is back in learning. Nobody has to approve a hundred agentic runs. You handle enough of them to nail the fix, and the moment the re-codified version is confirmed, the rest of the queue drains straight through it. The queue resolves each item against whatever the workflow is when its turn comes.

Demotion is a normal outcome, not a defeat.

Two smaller signals worth reading

Repeated failures change the wording, not the mechanism. A single failure says look at this step. After three consecutive ones, the same review says the workflow has stopped working and relearning it may beat patching it. Nothing demotes itself either way.

A run that only got through because it was worked around gets flagged. When a code step fails and the run agent gets past it by supplying different inputs, the run finishes and you still get told. The workflow just proved it cannot execute as written, which is exactly the material a repair wants.