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.

A stage can wait on a person — an approval, a reply — before the workflow moves on. When a run reaches one, it reaches out on the configured channel, pauses, and won't complete that stage until a response has actually arrived. You can also give the wait a deadline: if no one responds in time, the wait is satisfied on its own so the run can move on to the next stage instead of stalling indefinitely. Who it reaches doesn't have to be fixed in advance: the same stage can notify a different person each run — even as a Slack direct message — from an address or handle the run collected earlier.

Files you upload while building stay private to that conversation. If runs need one — a policy document, a rubric, a price sheet — you can ask the architect to share it with future runs, either across the whole workflow or scoped to a single sub-workflow so only that part of the process consults it.

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. Reviewer agents periodically examine your published workflows 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? Concrete failure points the runner can't recover from — a referenced value that's never provided, a non-agent step that depends on data being present and correctly shaped, or a best-effort component configured to stop the whole run if it fails.

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, and an email digest — at most one a week — rounds up new suggestions for published workflows you've recently edited or that hit a failure:

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.