Agent staffing playbook

A seat can be human, agent, or hybrid. The staffing decision should follow the work, the risk, and the measurable.

Good agent-seat candidates

• Repetitive work with clear inputs and outputs.
• Work that benefits from fast exception detection.
• Work with objective checks and evidence trails.
• Work where approval boundaries can be stated precisely.

Poor agent-seat candidates

• Ambiguous judgment without clear escalation.
• Sensitive relationship work where trust is the work.
• Work requiring broad unbounded credentials.
• Work with no measurable or review path.

Safe go-live sequence

1. Draft the seat and Charter. 2. Name the human Steward. 3. Define tool permissions and vault-backed credentials. 4. Run dry runs with evidence. 5. Review Signal, Friction, and tool-call audit rows. 6. Human approves go-live.

In the onboarding funnel

Staffing your first agent is a step in onboarding, right before the finish step. Its content is the stock-template gallery: pick a template to staff an agent seat, and you continue on the agents surface to name the Steward, sign the manifest, and run the sandbox dry run — the same draft-first path described below, not a separate one. Staffing the first agent is the activation moment, so the funnel asks for it before exit.

Working solo, or staffing later? Skip the step with intent and finish onboarding without an agent. Nothing is forced: you can staff an agent any time from the agents surface, and the staffing decision still follows the work, the risk, and the measurable.

Create and stage an agent from CLI or MCP

Two creation paths, both draft-first. Read the stock-agents guide for templates and the how-agents-work guide for the operating loop.

• From a template: list with agent_template.list / rost_list_agent_templates, then agent.create_from_template / rost_create_agent_from_template with seat_id and template_slug. Returns a draft agent and draft Charter only.
• Custom: agent_setup.start / rost_start_agent_setup (returns a setup_id), iterate with agent_setup.get and agent_setup.update, then agent.create_custom / rost_create_custom_agent. Stage tools with agent.configure_tools (vault refs only) and sandbox with agent.run_dry_run.
• Inspect runtime: agent.status / rost_get_agent_status with {"seat_id":"<seat-id>"} returns lane, live state, steward chain, dry-run result, and Runner availability.
• Run on demand: rost agent run-now --seat-id <seat-id> / agent.run_now / rost_run_agent_now queues a manual production run and returns execution_mode: "production_manual" without changing or arming the saved schedule. The command requires the shared readiness result's execution_ready: true; cloud agents dispatch to the Inngest executor and runner agents queue work for the selected paired runner. It is human_required (DER-1766/DER-2081): a human with authority requesting a run acts directly, an agent re-running its OWN seat (same-seat) may auto-execute only under a bounded Trusted standing authorization, and a cross-seat dispatch (one seat running a different seat's agent) always asks a human. An implementation agent onboarding a company may request a run (DER-2961) but never dispatches one itself: every such request stages a confirmation for the owner, and only for a Seat whose agent that same implementation run's own setup receipt created — any other Seat is refused before a confirmation exists. The same bound is re-checked when the approved run actually dispatches, against the agent that is live on the Seat at that moment, so an approval cannot dispatch a substitute agent the receipt never created. It cannot approve its own request. It still requires a live staffed agent and passes the normal server-side tool guard.
• Audit what an agent did (Trust Card): rost command agent.list_runs --json '{"seat_id":"<seat-id>"}' / rost_list_agent_runs returns the seat's run history with per-run Skill activation counts plus tool-call, guard-denied, and guard-held counts; rost agent get-run --seat-id <seat-id> --run-id <run-id> / agent.get_run / rost_get_agent_run_diagnostics reads one run's transcript reference, token/cost usage, outcome, product-visible run errors, and any Skill versions/files loaded for that run. Pass --transcript ({"transcript":true}) to also return the persisted, secret-scrubbed session transcript for that run when one exists — cloud-lane and runner turns persist a bounded transcript at turn end. Final run outcomes are no longer chopped to a short summary; the full report survives. Loaded Skill file hashes and sizes identify the immutable source package; the runtime may still bound or truncate prompt text before sending it to the model. rost command agent.list_tool_calls --json '{"seat_id":"<seat-id>"}' / rost_list_agent_tool_calls returns the tool-call ledger with each call's guard result. Both list commands include denied_tool_call_count and held_tool_call_count rollups: hard guard denials stay separate from actions escalated for review. Pass {"seat_id":"<seat-id>","held_only":true} to agent.list_tool_calls for only the held calls. The web seat page shows the same facts as a Trust Card, and its Activity tab additionally renders the full persisted transcript and artifacts rail for a selected session inline (no --transcript flag needed there) alongside the business-activity ledger (work.record/work.list) — counter tiles and a run-grouped feed with each record's verb, object, outcome, evidence, and template_ref when one was used.
• Read a guard result (one vocabulary everywhere): every guard_result falls into exactly one of three buckets, and the Trust Card, the run-watch panel, the run receipt, and the agent.list_tool_calls rollups all use the same split. Executed is allowed — the call ran. Refused is denied_manifest (the tool is not in the seat's Charter) and denied_budget (the call would exceed the seat's budget) — the guard blocked the call outright and no human review is pending. Held is escalated and denied_tenant_policy (the call exceeded the company automation ceiling) — the call did not run but is waiting on a human, so it is a decision you can still make. The denied_tool_call_count rollup counts refusals; held_tool_call_count counts holds. Refused and held are never merged: a refusal needs a Charter or budget change, a hold needs a person.

Review readiness before go-live

The fleet page, agent_setup.get, and the seat page use one shared readiness result rather than deriving separate answers. It reports lifecycle_admissible separately from execution_ready, requested/effective lane, selected Runner, provider/model and inference funding, current cap state, source/connection state, Steward and Charter/manifest evidence, Skill dependencies, schedule validity, allowed production execution modes, checked counts, stable reason codes, and the canonical configuration_digest. Dynamic Runner liveness, current budget, and source health are fresh checks, not hidden inside that digest.

The distinction matters for runner seats. An unscheduled runner-lane agent may be lifecycle-admissible and go live in a parked state while no compatible Runner is available, but it is not execution-ready and cannot receive work. A non-null schedule is an armed production trigger: go-live, resume, re-lane, and agent.update_schedule refuse to arm it until execution_ready is true. Clear the schedule or resolve the returned readiness reasons before retrying. rehearsal_requirement distinguishes ordinary and legacy agents (not_required) from agents created by an immutable onboarding setup receipt (onboarding_setup). Only the latter require a current application-, revision-, and configuration-bound rehearsal before execution; their passing receipt appears in latest_rehearsal. An ordinary Charter dry run is not represented as an onboarding rehearsal.

A staffed agent row also shows whether the Steward chain, lane or runtime substrate, vaulted credentials, granted tools, model config, sandbox dry run, and go-live state are complete. Each missing item links to the exact setup surface that fixes it: seat staffing, the Charter Builder, agent operations, runner settings, vault settings, or tool configuration.

After an agent runs, review its completed work as well as its telemetry. Seat pages combine explicit deliverables, work-log evidence, and successful run summaries into a readable output trail with safe evidence links labelled as internal, Linear, GitHub, or external. Held confirmations and escalations remain visible until decided or expired: confirmations can be approved or rejected from the seat page, while escalations link to the Steward queue for the human decision.

Change an agent's lane after go-live

The lane a live agent runs on — cloud (the ROST-managed runtime), a paired runner, or an external MCP session — is otherwise fixed once it goes live. To move a live agent to a different lane, use agent_setup.relane (owner-only, human-gated, with a required rationale): it pauses the agent, moves it to the new lane, forces a fresh dry-run rehearsal on that lane so lane-specific tool executability is honestly re-surfaced, then brings it back live. It honours the same substrate gate as go-live: an unscheduled runner target can still go live parked while no compatible runner is available, but a scheduled agent's readiness is checked before it returns to live. If the rehearsal fails, the agent is left paused on the new lane rather than going live, so a failed re-lane never wakes on a schedule. This path does not mint a new Charter version, so a seat whose Charter already carries signed manifest evidence needs that evidence re-signed for the new lane before its rehearsal can run.

The governed AICOS seat's own lane change is a separate, owner-only path — Settings -> AICOS, or aicos.brain_settings.update — and behaves differently on a live, recognized stock AICOS Charter: see the AICOS chat guide for the Charter successor it mints. A draft agent's lane is still set directly with agent_setup.update.

When to stop for confirmation

agent.create_from_template, agent.create_custom, staffing.assign_user, agent.go_live, agent.update_schedule, agent_setup.relane, and mcp_token.create are human_required; agent.configure_tools and credential.ingress are credential_flow (both gate through the vault-backed credential path with human approval; agent.configure_tools stages the request and only credential.ingress takes the raw secret, as a vault reference); agent.decommission is dangerous. agent.run_now is human_required (DER-1766/DER-2081): a cross-seat run always asks, while a same-seat re-run of the acting seat's own live agent may auto-execute only under a standing Trusted grant. An agent may draft, configure (with vault refs), dry-run, and request an on-demand run; the human approves go-live, credentials, schedule changes, and decommission. run_dry_run is ungated by human approval, but it is precondition-gated: the seat's permission manifest must be signed first (charter.sign_manifest). Attempting a dry run before sign-off returns a clean COMMAND_PRECONDITION_FAILED naming charter.sign_manifest, not a generic failure. Go-live after a passed dry run is human_required. See the confirmations guide.

Non-negotiables

No orphan agents. No raw secrets in prompts, logs, or tool arguments. No durable decisions by agents. No tool access based only on what a client asks for. The server guard decides.