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 an immediate live run without changing the saved schedule. Cloud agents dispatch to the Inngest executor; runner agents queue work for the paired runner. The command is ungated but still requires a live staffed agent and 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 tool-call 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, and product-visible run errors; 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 a denied_tool_call_count rollup — the actions held because they exceeded the charter. 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.

When to stop for confirmation

agent.create_from_template, agent.create_custom, staffing.assign_user, agent.go_live, agent.update_schedule, 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 not human-gated because it does not expand authority or change the schedule; it only queues an immediate run for an already-live agent. 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.