The Workflow Console

The panel at the bottom of the workflow editor reports what a run is doing. It has two views, and the one you get by default — Console — is a line-by-line stream: one line per thing that happened, oldest at the top, newest at the bottom.

Reading a line

Every line has the same shape:

06:46:51   ✗   TOOL      run_shell    Tool execution failed          121ms
06:47:30   ⟳   MODEL     Calling azure-foundry/gpt-5.4              4.3s…
06:46:38   ✓   RUNTIME   Provisioned isolated runtime               5.07s
06:47:34   ✓   MODEL     gpt-5.4   The test failure is in trace-…   14.6s
06:47:49   ✓   TOOL      run_shell   bun run build && bun test      2.35s

• Time — when the line's work started, on the wall clock.
• Status — ✓ finished, ✗ failed, ⟳ still going, ⊖ skipped, ⚠ warning.
• Kind — what sort of work it was. Hover it for a one-sentence explanation:
  • MODEL — a call to a language model, labelled with the model that answered.
  • TOOL — a tool the agent ran inside its sandbox.
  • RUNTIME — sandbox lifecycle the platform performed for the block. These lines are dimmed: they are context, not your workflow's work. They stay visible because on a cold block the first few seconds you wait are the runtime being provisioned, and hiding that makes the console look stuck.
  • BLOCK — a block of your workflow (a group header).
• Label — reads as an action while it runs (Calling …, Running …) and as a result once it finishes (azure-foundry/gpt-5.4).
• What it did — a short excerpt after the label, so you can tell one step from the next without opening any of them. A MODEL line shows the opening of what the model said, or the tools it decided to call (→ run_shell). A TOOL line shows the arguments it ran with — the command for run_shell, the path for read_file. The excerpt is cut to fit the row; the detail panel shows the rest.
• Duration — how long it took. A line that is still going shows elapsed time with a trailing … and ticks upward.

Blocks group their own lines

Each block is a header row; its model, tool and runtime lines sit indented beneath it.

• While a run is in flight the console follows the newest block. When the next block starts, the finished one folds to a single summary line — Agent 1 · agent · 25 model calls · 26 tools (5 failed) · microvm — so the viewport stays on the work in progress.
• A failed block stays open, down to the line that failed. Errors are never hidden behind a caret.
• Click a caret to fold or unfold a block yourself; your choice sticks for that run.

Opening a finished run therefore shows one line per block, plus any block that failed already expanded.

Following, filtering and searching

• While a run is live the console sticks to the newest line. Scroll up and it stops following so you can read; a control appears to jump back to the latest.
• The chips on the right narrow the stream: All, Err (only failures), Tools, Model. Block and run lines always stay visible so you never lose your place.
• The search box matches block names, tool names and model ids.

Clicking a line

Selecting a line opens the detail panel beside the stream. Its header repeats the line you clicked — status, kind, label, failure message, duration — and underneath it says where the line sits: the wall-clock time to the millisecond, the block it belongs to, and its rank among that block's calls of the same kind (tool 7 of 26).

The sections below read in the order you need them when something failed:

1. Error — only on a failed line. A platform error code (PLANE_EXECUTION_FAILED) is shown as its own chip above the message; multi-line messages keep their line breaks.
2. Files — anything the block published, with an inline preview when the file type renders safely in the browser.
3. Output (or Result for a tool call) and then Input (or Arguments), each with its size and a copy button. Tool results are shown as shape metadata (type, size) rather than content.
4. Details — folded by default. Did carries a model call's text in full, Arguments the tool's arguments, alongside the timing window, model and token counts, runtime attributes, and the block, workflow and execution identifiers.

Maximize (⤢) opens the same panel over the whole editor.

The terminal execution:error carries the same safe code, message, retryable, and optional blockId stored with the run. A block failure updates the existing failed block row instead of adding a second conflicting row. Pre-block or global failures appear once at workflow level. In Monitor → Run Details, the persisted error is shown even when no error span exists; use Focus failed block when a blockId is available. Integration failures also prompt you to reselect the account or required resource when that is the appropriate remediation.

The Timeline view

Switch to Timeline in the header for the trace view: the same run as a span tree with duration bars, and a rollup of where the time went — your workload, platform overhead, and time nothing has accounted for. Use the console to answer what is it doing, and the timeline to answer where did the time go. Your choice of view is remembered.

Opening a past run

Every run in a workflow's Runs table (and on the environment dashboard and a process flow's workflow action) opens in the same console. The sheet has three parts:

• Top left — the run, or the line you picked. Until you select a line it shows the run itself: the failure first (with its error code lifted into a chip), any files the run published, the final output, and the run's details folded underneath. Click a line in the terminal or a block on the canvas and the pane shows that instead; Esc goes back to the run.
• Top right — the canvas, read-only, with each block coloured by how it ended. Click a block to jump to its lines. ⤢ opens it full-screen for a tall workflow.
• Below — the terminal, the same line stream as in the editor, with the same Console | Timeline switch and the same filter chips. Fold it with the caret in its caption when you only want to read; the bar that remains still names the run's outcome.

Saved runs show BLOCK, MODEL and TOOL lines. They do not show RUNTIME lines — the sandbox lifecycle is streamed while a run is live but is not part of the saved record.

On the workflow's operational view the open run is part of the page URL (?run=…), so you can paste a link to a failing run and the person who opens it lands on the same sheet.

Sizing the panel

• Drag the divider to any height you like.
• Maximize (⤢ in the header) hides the canvas and gives the console the whole editor; ⤡ or Esc puts it back.
• Collapse it to a single bar and it still names the activity currently running, so you can work on the canvas and see the run is alive.