Workflows
A workflow turns a process you repeat into something you can run, see, and trust.
Some work is the same shape every time: gather, clean up, format, file. When those steps live only in your head, they are easy to get wrong and impossible to hand off. A workflow writes the steps down as something you can run on demand, watch as it goes, and review afterward.
When to reach for a workflow
- a multi-step routine you do often enough to be tired of doing by hand
- a process where the order matters and a missed step causes problems later
- work you want a record of: what ran, in what order, and what it changed
- anything you would like to hand to a teammate, or to an agent, without writing a page of instructions
A run you can see
The point of a workflow is not just automation, it is automation you can trust. Each step runs in sequence, and the run is inspectable from start to finish: you can see what happened at every step and why. Nothing changes your workspace behind your back. When the result is wrong, the run shows you exactly where it went wrong instead of leaving you to guess.
What a workflow can touch
A workflow works across the same things you do: notes, plans, files, and AI steps. That lets a single process read source material, transform it, and write the result back into your workspace as real items, all in steps you laid out and can review.
What a step looks like
You build a workflow out of a small set of step types, dragged in from the builder’s toolbox. Each one does a single, predictable thing:
- Input. A piece of starting material you supply: plain text, a URL, a number, or a block of JSON. This is the raw thing the rest of the workflow chews on.
- Quick AI. A single AI call with no tools attached. Use it for a pure text transform: rewrite this, summarize that, pull the key points out of a paragraph.
- Agent. An AI step with more reach. It can use the tools and skills you allow, under the workflow’s permissions, so it can do more than rewrite text. Reach for this when a plain text transform is not enough. See Agents for what an agent is and how its permissions work.
- Human Approval. A deliberate pause. The workflow stops and waits for you to say go before it continues, so a person stays in the loop at the moments that matter.
- Export. The step that writes a result back into your world, as a new note or a plan. This is how the finished work leaves the workflow and lands somewhere you can use it.
The Input, Quick AI, Agent, and Export labels are the friendly names in the builder. Under the hood each maps to a typed step kind, but you work with the friendly names.
Adding and ordering steps
You add a step by dragging it onto the builder canvas, and you can copy, duplicate, and delete steps as you arrange them. Steps run in the order you connect them, not the order you happened to drop them. The order is the wiring between steps, so a later step never starts until the steps it depends on have finished.
How one step feeds the next
Steps are not just stacked, they are wired together. A step produces an output, and you connect that output to the input of the next step. So an Input step’s text can flow into a Quick AI step, whose result flows into an Agent step, whose result flows into an Export step that saves it. Each connection is a visible line in the builder, which means the path your data takes is something you can see and change, not a hidden assumption.
Think of it as a pipeline you can read left to right: this came in, this transformed it, this is where it went. If a result looks wrong later, you can trace it back along those connections to the step that produced it.
Build one from a template
You assemble a workflow in the Workflow Builder from a set of steps, and you can start from a template rather than a blank page. The Recipe Importer preset is a worked example: it walks a recipe from raw text through extraction, normalization, and formatting, with review built in so you approve the result before it lands. It is marked experimental, so treat it as a strong starting point you adapt rather than a finished tool.
Inspect a run
Every run leaves a record, and the run inspector is where you read it back. This is where the promise of a trustable run becomes concrete: instead of taking the result on faith, you can open the run and see what actually happened.
A run record shows you:
- The run at a glance. Its status (succeeded, failed, cancelled, or waiting on you), how long it took, and the input values it started from.
- Step by step. A list of every step with its own status, so a green run with one failed step is obvious at a glance, plus a short preview of what each step produced. That per-step output is how you confirm a step did what you expected, or spot the exact one that did not.
- A timeline. A timestamped trace of events as the run unfolded: run started, this step started, this step succeeded, this step failed. When something goes wrong, the failed step carries its error message right there.
- What got saved. If the run wrote something back, the inspector names the saved item and where it landed.
When a step is about to write to your workspace, the run does not just do it. It shows you a preview of the proposed note or plan first, and you choose whether to add it or continue without it. You are reviewing the actual result that would land, not a vague description of it, so trust comes from seeing the change before it happens rather than after.
A run record is the account of what changed, but it is not a permanent backup. Treat the saved items themselves as the durable result, and the run as the receipt that explains how they got there.
Validate a workflow before you run it so problems surface early, then keep the run record as your account of what changed.
Where to go next
- Agents: the AI helpers a workflow can call on for a step.
- Notes and Plans: the items a workflow reads from and writes back to.
- Local-first trust: why an inspectable, reviewable run matters.