Running workflows¶

When a workflow runs, one agent executes it: the runner. It works in the background and communicates through the workflow's channels: forms and interactive pages, Slack or Teams messages, emails.

What it can do¶

The runner can do exactly what the workflow was built with, no more and no less. The architect creates the capabilities (the components in each stage); the runner uses them. It exercises judgment in how it uses them, handling edge cases, choosing what to say, and deciding when to ask. What it can't do is invent a new tool or reach a system the workflow wasn't given. That's what keeps runs adaptable without going off-script.

Each stage is its own objective, and stages gate what comes after them. An action that's meant to happen after a review can't run until that review passes, and if the review is rejected, it doesn't run at all.

How it behaves with people¶

• It asks focused questions when it genuinely needs input, and prefers proceeding with a reasonable assumption (and confirming it) over interrogating the user.
• It avoids interrupting for status updates; pauses are reserved for decisions and information only a person can provide.
• It writes user-facing text in plain language, in your business's terminology, not in internal field names or jargon.

When the runner hits a recoverable problem that affected a run's quality, such as a flaky API or ambiguous guidance, it reports what happened, and those reports become suggestions.

Seeing what happened¶

Two ways to check on runs:

• The executions dashboard: every run of a workflow, its current state, and what happened at each step.
• Ask the architect. It can pull up recent runs or find a specific one by its collected data ("the run for invoice 4021"), then explain what happened and why. If a run didn't go well, you can ask it to make a change and re-run that run with the same data to see if the fix works.