Skip to content
Skip to article
Project SynapseEnterprise agent guide
Open demo

Fleet Command Center

The fleet command center is a live view of one workflow run. When a workflow splits into branches, or fans a list of items out to parallel agents, each branch and each item gets its own lane. You can watch the work move side by side, see which step is waiting for a person, and follow the run to its end.

The view only watches. It has no controls that change a run: approvals are decided in the approvals inbox, and the full record stays on the workflow run page.

Who can open it

Open Fleet in the top bar (in the menu on a phone), or go to /admin/fleet. The view needs the run.read_any permission, which the PlatformAdmin, Approver and Auditor roles hold. Any other signed-in role is sent to /denied, and a signed-out visitor is sent to /login.

The index of active runs

The index lists the latest 50 workflow runs that are pending, running or waiting, with the workflow name, status, age, in-flight lanes and pending approvals. Select a workflow name to open that run's live view. When the list or its counts are capped, the page says "Showing the latest 50 runs; counts marked ≥ are lower bounds." The index shows no cost, and it does not update itself: reload it to see new runs.

With nothing in flight, it reads: "No workflow runs are in flight. Runs advance only while a worker runs; start one and trigger a workflow to watch the lanes fill." A workflow run is a queue of steps stored in the database. A worker picks up each ready step and runs it, so without a running worker no lane moves.

The live view of one run

The header names the workflow, its version and its start time. Beside the run's status sit the live indicator (see below) and a Permanent evidence record → link to the run's full record, which links back with Live fleet view →.

  • The graph draws one box per workflow node, with arrows between them. Labeled routes such as on_fail or on_reject are dashed. Inside a box, each branch or map item that reached the node has a lane showing its status; a node outside any branch shows a single main lane, and map items read item 0, item 1 and so on. A box shows at most eight lanes, then "+n more".
  • Chips. A lane waiting for a person shows its approval kind, such as approval: gate, in place of its status. A map node shows its progress, for example 2 active · cap 3 · 1 done, and adds of 5 once the total is known.
  • The cost card, headed Direct model cost, shows the summed direct model cost of the run's agent steps, its label (estimated, reconciled or unknown), how many agent runs are priced, and "not an invoice".
  • The lane table lists every lane, including any beyond the graph's eight: node, branch or item, status, attempt, failure, pending approval and start time. A failure shows its kind, source and code with a fixed plain-language message. When a run has no lanes at all, it says "No lanes yet. Runs advance only while a worker runs."

The view shows structure and status only. It never shows agent output, item values or workflow context. A very large run is capped: its counts then carry "≥", the graph notes "lanes are partial", and the table lists the newest lanes.

Live updates

While a run is in progress, the page follows a change stream. It reloads the view shortly after each change, and at least every 15 seconds as a safety net. The indicator shows where that stands:

  • Live: the stream is connected.
  • Reconnecting…: the connection dropped and the page is retrying, waiting longer each time, up to 30 seconds. Each connection also renews itself after four minutes, so a long run shows this briefly now and then.
  • Ended: the run completed, failed or was cancelled, and the page loaded its final state. A run that had already ended when you opened it starts here and never streams.
  • Live updates stopped: five connection attempts in a row failed before the stream answered. A Refresh button loads the latest view once; reload the page to follow the run again.

If a reload fails, the page keeps the last view. When the server answers with an error status, or with JSON that is not a valid view, the page also says "The latest view could not be loaded; showing the last known state." A reload that gets no response at all keeps the last view without that note.

Run the demo

The repository seed includes a manual workflow built for this view, Fleet Demo Fan-out (fleet-demo-fanout). A planner runs first. A map then fans the items out to parallel item workers, at most three at a time and at most five items in all. A best-effort join collects the results, a reducer summarizes them, and a human approval comes last. The opening paragraph of Meet the agents names its three agents.

You need a database seeded with the demo and a worker running against it (see the next section). A PlatformAdmin then opens Workflows, selects Fleet Demo Fan-out, replaces the sample payload under Manual run with a brief and a list of items, and selects Run now:

{
  "brief": "Check each open work order for a missing goods receipt.",
  "items": [
    "Work order 1001",
    "Work order 1002",
    "Work order 1003",
    "Work order 1004",
    "Work order 1005"
  ]
}

More than five items, or an items value that is not a list, fails the fan-out at the start, and no item worker runs. An empty list skips the item workers.

The run then appears in the fleet index. In its live view:

  1. The planner, Fleet Demo Planner, reads the brief on the plan node.
  2. The map node M starts up to three item workers, Fleet Demo Item Worker, each on its own lane of the work node. Each finished item starts the next queued one, and the map chip counts them.
  3. The join J waits until every item has finished, successfully or not, and passes on the results that succeeded.
  4. The reducer, Fleet Demo Reducer, summarizes those results.
  5. The review gate raises an approval, "Review the reduced fleet demo result". The run waits, its lane shows approval: gate, and the index counts it under pending approvals.

An Approver or a PlatformAdmin decides the approval in /admin/approvals. The account that created or published the workflow cannot decide it. On a seeded database that is the seed administrator, so decide it from another PlatformAdmin or Approver account. Once it is approved, the run finishes and the indicator shows Ended.

On the mock provider the agents' outputs are placeholders: the demo shows the flow, not real findings.

Seeding and the worker

Deploying code adds no catalog rows. The demo agents and workflow exist in a database only after the repository seed, pnpm seed, runs against it. On a hosted environment that is a separate step an administrator must authorize. The seed is idempotent.

The hosted demo is web-only: it runs no worker process, so a run started there waits until a worker drains it. The reliable demo path is a real worker against the target database: pnpm worker -- --allow-inline-env. The flag lets the worker start against an EXECUTION_MODE=inline environment.

The inline bridge, WORKFLOW_WORKER=inline, works through workflow steps inside the web process instead. It is an experiment: it runs only while a function instance is alive, and it is unproven on Vercel. WORKFLOW_INLINE_CONCURRENCY, an integer from 1 to 10 with a default of 4, sets how many ticks run at once in each one-second round. The worker runbook, docs/operations/worker.md in the repository, has the details.

Cost

On the mock provider a PlatformAdmin sees the cost card read $0.00. Real cost appears only for approved users on the deployment's active real routes, which on the hosted demo are the four guarded Gateway routes described in Model & cost controls. Other roles see only the cost they may read. When they may read none of it, the card says "Cost is not visible for your role." instead of showing $0.

Tools

Workflow agent steps run without tools today, and the three demo agents carry no tool grants. No lane shows a tool call or a tool refusal, and the view has no column for them.