Creating a workflow

You create a workflow by naming it. That is the whole form: a name, a Create button, and a placeholder that suggests something like Inbound Sales. Everything else comes out of a conversation.

The console says it plainly on that screen: name it, and the assistant will interview you for the rest.

The setup interview

Once the workflow exists, an assistant opens a chat and starts asking. It is a real interview, not a wizard with a progress bar. On every answer you give, it does three things:

• Rewrites the written procedure with everything it now knows.
• Names the outside systems the job touches, the moment you mention one.
• Sets the timing as soon as you say it, whether that is a schedule, on demand, or whenever something happens in one of your systems.

Then it asks one or two sharp questions about the thinnest part of what it has so far: the emptiest section, the branch it has not heard about, the judgement call that is still vague. That is where the value is. People forget things about their own processes and remember them when something asks a specific question about a specific case.

The SOP is the contract

What the interview writes is an SOP, a Standard Operating Procedure. It is one plain markdown document, and it follows the same ten-section skeleton for every workflow:

1. Purpose and desired outcome
2. Scope
3. Trigger
4. Inputs
5. Roles and responsibilities
6. Systems and tools
7. Main procedure
8. Process variants and known branches
9. Completion conditions
10. Outputs and side effects

The skeleton is a structure, not a quota. A section can be one line, and it can be empty: a bare heading with nothing under it is a visible to-do, which is a perfectly good state early on. What the assistant will not do is invent a different structure per workflow, because two of those sections do real work later. The Inputs section becomes the workflow's typed input parameters at codification, and the Main procedure section becomes its steps.

The SOP is always rewritten whole, never appended to. That is why a new detail you mention in turn nine lands in the right section instead of at the bottom.

You are never blocked

An SOP is allowed to stay underspecified. That is a design decision, not a tolerance: the two-stage model exists precisely because the gaps get caught by a human at run time and sharpened run by run. So the assistant does not demand completeness, does not refuse, and never tells you a workflow is unsupported or that you must finish something first.

Connecting the systems it needs

Name whatever the job actually touches. The systems already connected to your account are not a menu you have to pick from, they are just what happens to be there already. Anything else gets connected during the interview itself. The details are in integrations.

Three things are always available to a running workflow and never count as systems to connect: web search, a sandbox that can run code and handle files, and a real web browser.

Publishing checks the connection behind the trigger itself before it arms anything; other systems the workflow names are not checked at publish, a missing credential there shows up on the first run that needs it, with a notification. Either way the assistant will not tell you a system is unsupported.

Testing before you publish

The workspace has a Test run button, and it runs exactly what you are looking at. While a setup interview is open, a strip above the panel shows Unpublished changes with a toggle between the published version and the draft. Whichever the toggle shows is what a test run executes.

A draft test run pins an immutable snapshot of the draft, labelled v1.1, v1.2 and so on. Those snapshots appear in the Versions list, but they never advance the version counter and can never be published by accident. Testing a draft cannot change what is live.

Every console test fire is a test. It does not count toward the readiness meter and it can never be accepted as an example, which keeps rehearsals out of the learning loop.

Publish

Publish accepts the current SOP, promotes it as the active version, and arms the trigger. The button's own tooltip says as much.

What it validates is deliberately narrow. An empty SOP is refused. A named system that does not resolve to a connection is refused. There is no completeness gate and no open-questions gate, because either would contradict the point above.

Publishing does not codify anything. The workflow moves from Setup to Learning and starts doing real work with a human in the loop.

Re-publishing after more interview turns just promotes the newer draft and re-arms the trigger. Publishing content identical to what is already live mints nothing.

Pausing

Pause is the reverse. It disarms the trigger and unpublishes the workflow: no schedule fires, no event is delivered, and the workflow shows as Paused in the list. Publish again when you want it back.

The five states you will see

Every workflow shows exactly one status:

• Setup: created, never published.
• Learning: published and running agentically, with you accepting or rejecting each run.
• Operational: codified, running as deterministic steps.
• Paused: disarmed by you.
• Needs review: a codified run failed and something is waiting on you.