The OAK model

Workflows & the fleet

Workflows are scripted fan-outs, and the fleet puts every running agent on one board.

Above a single session sit two things OAK tracks specially: a workflow run, which is a scripted fan-out of many agents, and the fleet, which is every running agent on one board. Together they turn a swarm into something you can watch and account for.

Workflow run

A workflow run is a scripted fan-out of agents, one level above subagents, that Claude Code's orchestration executes deterministically. The observatory mines each run from its own transcripts and state file: name, running or done state, per-phase progress, and per-agent tokens, time, and edits. An interrupted run that never recorded completion is not shown as running.

The Workflows tab: one row per multi-agent run with an informative name, a running or done badge, phase progress with tokens and elapsed time, and an activity sparkline, unfolding to per-phase groups and their agents
Workflow runs, with their phases and the agents inside them.

The fleet

The fleet is every running agent across the repository's worktrees, unified into one board. Each row carries a live phase, worktree and branch, an activity sparkline, line deltas, tokens and time, and risk. Tracking is read-only and path-only: file names cross between agents, file contents never do.

The Workers tab: per-agent rows across the repository's git worktrees, each with a live phase badge, worktree and branch, an activity sparkline, line deltas, tokens and time, and risk; subagents nest under their parent
The fleet. A phase inferred from inactivity carries a tilde.

Phase

A phase is a fleet row's live state: working, awaiting input, awaiting permission, idle, or done. A phase inferred rather than reported (from inactivity, or from a background agent’s completion notice not having arrived yet) is marked with ~ and presented as a heuristic, never asserted.

Process

A process is a background shell the session launched with run_in_background. Its identity is the harness's own shell id — a transcript records no operating-system process id, and the agent may be running over SSH or in a container, so inferring one from local processes would be wrong. A process with no recorded end reports its runtime up to the last moment the session is known to have existed.

The Processes tab: one row per background shell with its state, the harness's shell id, the shell's description, its runtime and how much output it produced; running shells sort first
Background shells, after the call that started them scrolled away.

Live conflict

A live conflict is one file holding pending edits from two or more siblings, at least one of them active. Detection is by path only. Live conflicts lead the Actions view because they need attention before the agents collide further — see Conflicts.