MalleableMalleable

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.
  • It replies in the language the person is using: a form submitted in Spanish gets its responses and summaries in Spanish, unless asked otherwise.

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, labeled by what triggered it, 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") — and when you only half-remember a value, it can check which values actually occurred and narrow down from there — then explain what happened and why — including what started the run, whether that was a form submission, an incoming email or message, a webhook, a schedule, or an MCP call. Its account comes from the runner's own step-by-step record of that run, which it can search for one specific detail — a particular error, or where a value came from. 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.