Codification

Codification is where a workflow stops paying for a model to rediscover the same procedure every time. The runs it learned from become ordered steps, most of them plain code, and from then on a trigger fires and the workflow just runs.

It is not a compile button. The system does not disappear for two minutes and hand back a black box. It walks the procedure with you, start to end, and asks about the parts the runs left ambiguous.

Starting it

The Ready to codify? card has a Start codification walk-through button, and the assistant panel offers Start codification once the workflow is eligible. Either opens the same thing.

You need at least one accepted run. That floor is real: the workflow is codified from what actually ran, so with nothing accepted there is nothing to codify from. Everything above that floor is your call.

What happens in the walk-through

The assistant opens with the workflow's own history. It reads the accepted runs first, in full, then the current SOP. Then it writes a first draft of the steps and explains it to you.

From there it is a conversation:

• Every step is narrated in plain language. Each step carries an explanation of what it does, written for the person who owns the process. You should never have to read code to know what a step is for, and the assistant will not show you code or JSON unless you ask for it.
• It asks rather than guesses. Where the runs were ambiguous or a branch never appeared, the question comes to you: in every example the amount was under ten thousand, so what happens above that?
• Everything you tell it goes back into the SOP. The workflow should come out of codification better documented, not only better automated. Seeing a real procedure walked with real data is what surfaces the rules nobody ever wrote down.

This is the most important conversation in the product, and it is worth taking slowly.

What you can pin

Two things survive the walk-through because you asked for them.

Keep a step agentic. Some work needs judgement every single time and will not survive being frozen into code. Say so, and the step stays an agent step. Those appear in the panel under Staying judgment, each carrying a keep agentic badge, described as steps that were decided to need a judgement call every run.

Pin a permanent gate. A gate pauses the autonomous workflow for a person's approval, forever, at a specific point. Write one where a human must be on the hook every time regardless of how confident anything is: before money moves, before a contract goes out. A gate is a whole checkpoint rather than a setting on a tool, and it does not go away when the workflow becomes autonomous. See approvals and gates.

The trade-off is worth stating plainly. A pinned gate is safer and always pauses. Leaving it to the agent's in-run judgement is faster and still asks a human when the action is consequential.

How the steps are shaped

Steps are split the way you think about the work, never by technique. A step is something you would name out loud: calculate the invoice amount, send the invoice. Pagination, a lookup plus a write, three requests to the same service: if they complete one business operation, they are one step.

The one split that is always worth making is between the part that can safely be repeated and the part that reaches the outside world. Working out what to send is one step. Sending it is another.

Data between steps is explicit. Each step declares exactly which earlier values it reads, and a reference to a later step is rejected before anything runs. That is also what keeps a step's explanation honest, because its inputs are visible rather than "everything so far".

What each step is allowed to reach

The panel shows a card headed What each step can reach, listing every step that runs code, including the ones that reach nothing.

Steps are default-deny. A step gets no network and no credentials unless it asks for them, and the card is where you see what each one asked for: this step runs with no network access, this step can reach the public internet, this step is granted the CRM connection.

The card's own hint is the honest caveat: it tells you what a step is permitted to reach, not what its code does with that permission.

Nothing is executed to check it

The candidate is never run. Not during the interview, not when you confirm it. Running unconfirmed, machine-authored code that holds real credentials is exactly the thing this platform will not do.

What is checked is structure. Step ids are unique, every value reference points backwards, every code step has a real entry point, every declared capability is legal. That check runs on every save, and a workspace that fails it is rejected whole rather than half-applied.

So the first real evidence that a step works is its first real run. That is the price of never executing code nobody has confirmed, and it is why the walk-through matters more than any automated verdict would.

Confirming

Your confirm at the end of the interview is what promotes the workflow. There is no automatic flip, no threshold that does it for you, and no setting that turns it on.

Two conditions: the candidate has to be structurally valid, and it has to actually codify something. A candidate with no code step in it is not a codified workflow.

Confirming mints one version carrying the new steps, the SOP as the interview rewrote it, and the reference files, all together. They cannot drift apart later because there is nothing to drift between.

What changes afterwards

The workflow shows as Operational, and the workspace unlocks its Operational view: the steps as a canvas, built from the latest codified run, where you can click a step to inspect it and jump to the runs that executed it.

Underneath, the run itself changes shape:

• A fully codified workflow costs zero model calls. Nothing initialises an agent to narrate a chain that is already deterministic. Steps run one after another, in milliseconds, the same way every time.
• Agent steps are the exception, engaged only where you or the walk-through decided judgement was unavoidable. Control returns to code the moment the call is made.
• Gates fire as pinned, every run, forever.
• Runs go in parallel. The one-at-a-time pacing of the learning stage exists to keep lessons ordered, and a codified workflow has no lessons to race.

Everything is still recorded the same way. Going autonomous changes how the work runs, never whether it is written down.

When a codified run fails

It does not fail silently and it does not repair itself mid-run. The run stops, a review lands in your Inbox, and a repair interview opens on that exact failure. See editing and revising.