Steering and fleet control
Your coding agent uses Yoke to take a STEERING seat claim for one or more projects and working strategy docs. It files work items, staffs them on an available harness on your machine or another connected machine, and orchestrates delivery while you guide the work and make key decisions.
STEERING uses Yoke to launch parallel CLI sessions across available machines and coding harnesses. Fleet messaging lets it communicate with those sessions and coordinate execution and delivery.
STEERING
CURRENT-PLAN
STEERED
CURRENT-PLAN
STEERED
CURRENT-PLAN
STEERED
CURRENT-PLAN
Steer and coordinate work
Who coordinates which scope
A steering seat records responsibility for a scope of work. A project-wide seat covers the project; a document-scoped seat covers items linked to that working strategy document. Document locks keep two coordinators from independently rewriting the same standing plan.
A steering seat differs from a work claim. Steering coordinates the work; a work claim identifies the session doing a particular item. The dashboard shows these roles so a team can see who is responsible without reconstructing separate chats.
Standing plans and work selection
The working strategy doc holds direction and the rolling plan. Filed work enters the Frontier, where dependencies, workflow requirements, priority, and ownership determine what can advance. Steering staffs eligible work and follows it through the required steps.
Steering is not a promise that every machine can run every harness. A launch needs a connected relay, an available supported harness, the required sign-in, and suitable capacity. See Yoke CLI and relay.
Reading waits and decisions
A waiting item may need a dependency, QA result, release, human decision, or available capacity. The steering report brings these facts together so the coordinating agent can act on the cause rather than repeatedly trying to start blocked work.
A parked session can keep a valid work claim during a wait. That is deliberate ownership, not evidence that the item has been abandoned.
Resolving contention
Work and path claims identify existing owners. When work overlaps, agents coordinate or record the relevant dependency instead of silently taking each other's files. Explicit release, completion, cancellation, or authorized termination changes ownership; inactivity alone does not make protected work free.
See the session reference and steering report.
Messages and human decisions
Messages versus decisions
Fleet messages carry instructions, questions, blockers, and results between sessions. A message receipt records delivery or acknowledgement, not agreement to perform the requested work.
A decision is a separate request whose answer satisfies a configured requirement. Your agent can bring decisions to you in conversation, and Inbox shows pending approvals with their evidence and effects.
Delivery and queued messages
A running session can receive messages through its hooks. A parked or idle session may require you to open the chat and start its next turn; its card explains that delivery is queued. Relay-supported wakes and operator-driven delivery are distinct paths.
If delivery fails, inspect the recorded reason and recovery. A queued message is not proof that the recipient acted, and an acknowledgement is not proof that the work finished.
Human approval and follow-up
Review the subject and evidence before approving. Different decisions can concern an item's work, QA evidence, or a deployment run. Answering one does not settle the others.
See Inbox and messaging and Team collaboration.
Levels and staffing
What levels mean
Execution levels group model and minimum-effort choices for staffing. They let a workflow ask for an appropriate level without hard-coding a single model into every stage. They are unrelated to the Git worktrees that isolate code changes.
Models and effort
A session's model and effort determine which configured level it matches. Levels can provide multiple model choices, and workflow stages can have defaults. The available choices come from the current model and harness configuration rather than a permanent list in this guide.
Who assigns work
Steering or explicit operator staffing chooses what a worker does. A session's level does not itself claim work. The workflow binding determines the skill used for the current segment, while ownership and readiness still govern whether execution can proceed.
Capacity and recovery
Launch limits and available harness capacity can delay staffing. Yoke records queued launches and the reasons they wait. Your agent can inspect those facts, choose an eligible placement, or follow the named recovery when a relay or harness fails.
See Execution levels, Level launches, and Capacity recovery.
Sessions
Harness sessions and work ownership
A harness session is a coding-agent conversation registered with Yoke. It retains its identity, work claims, and coordination records across turns. A session starts in a project or outside projects and may work on accessible items according to its permissions.
A browser sign-in session is different: it establishes dashboard access and is not a coding worker.
Registration and heartbeat
Harness hooks register sessions and report activity. The relay supplies machine and process information. Presence, tool activity, pause intent, holdings and the next actor are separate facts; an old activity timestamp does not by itself mean work is abandoned.
The Sessions page and Frontier share three server statuses: Working,
Waiting and Ended. Working means a live tool call or an unfinished turn
with recent activity; a finished turn is Waiting. A native process exit does
not end the session. Working and Waiting are selected by default; Ended loads
history when selected. Each card shows one reason and active age; the
header's (i) holds the detailed state and timestamps. The CLI uses
yoke sessions list --status working|waiting|ended.
Parking and resuming
Parking records an intentional pause. A session holding work can remain waiting while preserving its claims, then resume with the item's records and strategy context. End or release ownership explicitly when handing the work elsewhere.
Relay failure and recovery
A disconnected relay can prevent new launches or automatic wakes while server records remain intact. Check the affected machine and the reported diagnostic before restarting services or terminating a session. See Operations and troubleshooting and Linux relay supervision.
Who acts next
Session and item rows carry next_actor with actor, reason and since.
The session card information disclosure shows its next actor and waiting reason.
Item cards omit next-actor text. JSON and named-field CLI reads retain it. Pending
decisions take priority, followed by unmet dependencies, CI and release runs.
A decision resolves its audience to active people, including organization roles
inherited by the project. An empty audience names the steering owner and asks
for audience repair. The state time comes from the obligation, never a heartbeat.
Older servers may omit this projection; cards name unavailable state and retain
known end and holdings facts. Upgrade the server and refresh for detailed filters.