Building workflows¶

You build a workflow by describing it to the architect, ship changes by publishing them, and let the workflow improve itself through suggestions. This page covers all three.

The architect¶

The architect is the agent you work with to build and maintain a workflow. It creates the capabilities a workflow has; the runner that executes runs can only use what the architect set up. That split is what makes runs flexible without being unpredictable.

It builds incrementally: stages appear on the canvas as you describe your process, and it asks clarifying questions along the way rather than front-loading an interrogation.

It also tests its own work as it builds. It can run a script with sample data, render an email template to check it reads right, or do a dry run of the whole workflow before anything goes live, then fix what doesn't match your intent. Workflows are validated before publishing, which catches gaps like data that's collected but never used, or steps that can never be reached.

When your process changes, you tell the architect what's different. It edits the existing workflow, surgically where possible, rather than starting over.

Editing & publishing¶

Workflows are versioned, so you can change one that's already in use without disrupting it.

Drafts¶

Editing a published workflow doesn't touch the live version. It creates a draft, a new version you work on while the published one keeps serving runs. You can test the draft before anyone else sees it: open its draft run link and run it end to end, exactly as a real user would.

Publishing¶

When the draft is ready, publish it. The draft becomes the live version, and the version it replaced is kept as history, so you don't lose it.

Runs already in progress stay on the version they started on. Publishing a change never reaches into a run that's already underway; it finishes on the version it began with. Only runs that start after you publish use the new version. So you can fix or improve a busy workflow at any time without disrupting work in flight.

Suggestions¶

Workflows drift: a tool changes, a step turns out to be brittle, a real run hits something nobody anticipated. Suggestions are concrete, reviewable improvements to your workflow, generated for you rather than waiting for you to notice.

Where suggestions come from¶

Background reviews. After the architect edits a workflow, reviewer agents examine it in the background, each from a different angle:

• Does it do what it says? The implementation is checked against your stated intent, catching a stage whose instructions contradict the workflow's description, or a component configured differently than the guidance claims.
• Is it efficient? Unused data, redundant stages or components, over-engineering.
• Is it brittle? Hardcoded values that should be configurable, overly-specific instructions that will break on the next variation.

Real runs. When the agent running a workflow hits a recoverable problem, something it could work around but that affected the run's quality, it reports what happened and what it recommends. Those reports are analyzed alongside the background reviews, so recurring runtime friction turns into concrete suggestions too.

Reviewing them¶

Nothing changes until you approve it. New suggestions show up in the workflow editor, with an email digest when they arrive:

For each one, send it to the architect to implement (optionally with your own guidance), dismiss it, or snooze it for later.

Review, don't rebuild¶

Because the workflow's source of truth is your intent, improving it is a review-and-approve step, not a rebuild. The system proposes; you decide what actually changes.