The operational side of the workspace splits along one axis: is the system asking you a question, or just telling you what it's doing? We keep those two modes in separate nav slots so neither drowns the other.

A run that needs human input generates an Inbox item and stays visible in Activity. One entity, two lenses. Dismissing the Inbox item advances the run; the Activity row updates in place.

Nav order reads as a verb sequence: Inbox (what's asked) → Studio (dialogue) → Activity (what's running) → Library (what you've built) → Marketplace. Activity sits in the middle because it's the live tether between talking and shipping.

The badge beside Inbox counts items needing reply. The badge beside Activity counts runs currently running or waiting — it pulses, matching the per-row live indicator, so ambient glance tells you "things are in flight" without requiring a click.

Three panes, same grammar as §18 Inbox: left narrows the set, center is the list, right focuses one. Picking a row fills the right pane with the run's graph and metadata — the same anatomy a single workflow detail page shows, just reachable across every workflow at once.

The list is the same wf-run-row vocabulary as a workflow's own history, plus a workflow-name column on the left. No new row component. A run in Activity is the same run it'd be on the workflow page — both surfaces read the same event stream.

Same five run states as §04 Workflow — Running, Waiting, Completed, Failed, Cancelled. Live states pulse. Terminal states are static. Failed rows keep the red dot but never shout — the severity is in the status word, not the row background. Cancelled reads like "neutral retire."

The row's three useful signals are status (left dot + word), what triggered it (mono sub-line), and where it is in the graph (bits). Everything else — runtime id, elapsed time, input shape — lives in the focused detail on the right, so the list stays scannable.

A workspace with nothing firing isn't broken — just quiet. The empty state acknowledges that and points at the nearest cause (no workflows yet, or workflows exist but haven't run). Same dot-as-weight principle: no visual panic, just information.

If the filter excludes everything (say, "Status: Failed" with zero failed runs), the empty state names the filter, not the workspace: "No failed runs. Clear filter to see everything." — same pattern as Library's empty cells.

The nav icon is a single line tracing a step graph — a miniature of the activity curve the page renders in full. At rest it's the ink line only. When one or more runs are live, an amber dot pulses at the upper-right — the same live rhythm the list uses. Follows the §22 Glyph family: 14×14, 2px stroke, round caps, one filled accent.

The step-up line reads the same metaphorically as the workflow's own bits row: things happening in sequence, rightward. The pulsing dot is a single visual word — "something is in flight" — shared between the nav icon, the row status, and the badge counter.

Runs live on workflows. Inbox items live on runs (when a run is waiting on a user). Activity reads the union. These cross-links keep each surface honest about where data originates.

The rule: runs are owned by workflows; Activity is a join view over all workflows. Nothing lives in Activity that couldn't be reached via a workflow detail page — this surface is a convenience, never the canonical home for any piece of state.

Activity starts as a read-only observational surface. Writes (rerun, cancel, requeue) live on the focused run pane only — no bulk ops. These land v1:

• List runs across all owned workflows, last 7 days, live.
• Filter by status · workflow · trigger kind · time window.
• Focus pane with graph + metadata strip + "Open workflow" deep-link.
• Cancel a Running or Waiting run.
• Live polling tied to §04 Workflow's 5s cadence; falls back to WS events when available.
• Nav badge = count of Running + Waiting across workspace.

Deferred to v2:

• Free-text filter bar (§09 Command Palette covers cross-surface for now).
• Sparklines / throughput chart above the list.
• Custom time ranges beyond the 7-day default.
• Rerun with input overrides.
• Saved filter views.
• Team-scoped visibility (workflows owned by collaborators).