Teaching it through real runs
How a published workflow learns: sequential agentic runs, accepting or rejecting each one, and the readiness signals that say it is ready to codify.
A published workflow that has not been codified runs agentically. One agent, built from the SOP, with your connected systems plus web search, a sandbox and a browser. It reads the trigger, makes judgement calls, calls tools, and gets the job done while you watch.
This stage has a second job. The work gets done, and while it does, the platform watches what the procedure actually looks like against real data.
Learning runs go one at a time
Triggers that arrive while a run is in progress queue. They do not run in parallel, and nothing is dropped. Each workflow has one lane, and that lane stays occupied until the run reaches a terminal state, including the time a run spends suspended while it waits for you to approve something.
There are two reasons for the pacing. Every accepted run sharpens the SOP that the next run executes against, so the lessons have to arrive in order. And you never have to review two interleaved runs at once.
The workspace shows the backlog: the Queue fact on the SOP panel says how many items are waiting and how many failed before they could start.
Once a workflow is codified this pacing goes away. There are no lessons left to order, so ten triggers in the same minute mean ten runs side by side.
The agent asks before it does anything consequential
During a learning run, the agent stops and asks you before an action it judges consequential or irreversible: sending a message a person will read, moving money, deleting data, submitting a form. The run suspends, the request lands in your Inbox, and the run picks up exactly where it left off once you answer. It can wait minutes, hours or days.
That checkpoint comes from the agent's own judgement about the action, not from a switch you set on a step. See approvals and gates.
Accept or reject each run
Open a finished run and you get two buttons: Accept and Reject.
Accept records the run as an example, and starts an SOP revision. An agent reads the run you just accepted, along with the decisions you made during it, and drafts a sharper SOP.
That draft is not live. It is parked where nothing runs it, and it shows up in the Versions tab as a proposed revision with its own Accept button. Only your confirm turns it into the workflow's SOP. An unconfirmed draft never becomes what a run executes against.
Reject draws a line under the history. The run is judged, and the accepted streak starts over from zero.
A test run cannot be accepted or rejected. The buttons do not appear on one, because a rehearsal is not evidence about how the job goes.
Readiness is a signal, not a gate
The SOP panel carries a card headed Ready to codify?. It shows:
- An Accepted runs meter, counting the current streak against a recommended number. The default recommendation is five.
- The streak itself, newest first, each row naming which run it was and when you accepted it.
- A button: Start codification walk-through.
The tooltip on the meter is the honest version of the whole feature. It recommends at least that many agentic executions before codifying, and then says outright that this is a recommendation, not a requirement.
Five is arbitrary. It is too many for a two-branch job you understood after the second run, and too few for a workflow whose rare branches have not appeared yet. You can start codification any time you have at least one accepted run, and you can keep running agentically long past five if the interesting cases have not shown up.
Crossing the recommended number does not change anything about how the workflow runs. It sends you a notification saying the workflow has seen enough examples to run on its own, and the assistant panel offers a Start codification button. Between that point and your confirm at the end of the interview, every run is still a learning run.
Console test fires are excluded from the meter. It accumulates only from real scheduled, event-driven and manual runs.