Running and monitoring

Every run of a workflow is recorded as an execution. Starting a run returns immediately with an execution id — the pipeline itself executes asynchronously — and the console drops you straight onto the execution page, which refreshes itself while the run is in progress.

Starting a run

On the workflow detail page (Build → Workflows → your workflow), click Run. What happens next depends on the pipeline's declared inputs:

• If the pipeline references $userinput.<key> placeholders, the Run panel opens with one field per key. All declared keys are required — running with a missing key would send the literal unresolved placeholder to an agent, so the console collects them first.
• If the pipeline declares no user inputs, the run starts immediately. An optional panel still lets you pass extra fields as raw JSON if an agent expects them.
• A JSON toggle on the panel lets you supply the whole input object by hand for irregular shapes.

Scheduled workflows start runs the same way, automatically, at the configured recurrence — those executions appear in the same list as manual ones.

The executions list

The workflow detail page lists all of its executions with started time, status, completed time, and duration. Click any row to open the execution page. Execution statuses you will see:

• Running — the pipeline is still dispatching steps.
• Completed — every step finished and the run closed normally.
• Failed / error states — a step errored; the run stops and the error is recorded on the execution.
• Onhold / aborted — the run was held or cancelled before finishing.

Inside an execution

The execution page shows the run end to end:

• Header — execution id, start/completion timestamps, and a live status chip. While the run is in progress the page re-fetches automatically every few seconds, so you can watch it without reloading.
• Error banner — if the run failed, the recorded error appears at the top.
• Inputs — the exact input object the run started with.
• Agent timeline — one row per pipeline step, in order. Each row shows the agent, its status, its timestamp, its output (when the agent returned one), and its error (when it failed). Because the execution snapshots its pipeline at start, the timeline shows every step from the beginning: the currently executing step pulses as running, steps not yet dispatched render as queued, and finished steps carry their real reported status.
• Runtime events — the chronological audit trail emitted by every agent during this run: tool calls, LLM calls, egress decisions, and denials, each tagged with the emitting agent. This is the same event stream the Security section reads, correlated to the run by execution id.

Diagnosing failures

When a run fails, work top-down:

1. Read the execution-level error banner — it names what stopped the run.
2. Find the first failed row in the agent timeline; its inline error message is the agent's own report.
3. Check the runtime events around that timestamp — a blocked egress call, a denied tool, or a failed LLM call is usually visible there.
4. If the failure was an unresolved input, re-run with the missing $userinput key filled in; the placeholder substitution happens before any step dispatches, so such runs fail immediately without touching an agent.

Follow-up questions and file inputs

Two additional capabilities are available on the platform API:

• Execution chat — each execution keeps a conversation thread, so a client can ask follow-up questions about a run's results and retrieve the message history for that execution.
• File uploads — for workflows whose inputs include files, the API issues short-lived upload URLs so files can be uploaded directly to storage and referenced by the run.

Both are exposed to API clients; the console does not currently surface a screen for them.