Steward queue guide

A Steward is the human accountable for an agent seat. The Steward queue is where unresolved agent questions, approval requests, and boundary decisions land.

What belongs in the queue

• Agent go-live approvals.
• Tool and permission manifest approvals.
• Must-escalate Charter conditions.
• Ambiguous customer, money, legal, or authority calls.
• Repeated dry-run failures.
• Charter revision recommendations.

How to review an escalation

Read the seat, Charter, evidence, and recommended action. Decide the narrow question first. If the same escalation repeats, revise the Charter rather than answering the same question forever.

In the app, the evidence is shown as a legible card, not raw data: a proposed tool call lists the tool and its summarized arguments, and any attached context shows as labeled fields. Values that read like credentials are redacted, so you can decide without seeing secret material.

When nothing is waiting, the Steward page still proves the governance loop. It shows which agent or hybrid seats the human stewards, how many escalations were raised or decided recently, and whether any are open. That empty state is an operating summary, not a dead end.

The Steward page itself only lists charter-clause escalations (Queue, Escalations). Agent-raised confirmations that need a sign-off — Charter approvals, tool/permission grants, and other gated commands — live in the consolidated /approvals queue, one click away from a header link on the Steward page. See the confirmations guide for how that queue works.

How escalations reach you

An escalation reaches you the same way no matter how the agent raised it — in a chat or CLI session, or on its own scheduled cloud run. When the agent stops at a boundary it opens the queue item and sends a notification to the accountable human along the steward chain, preferring a connected Slack channel and falling back to email. If no human occupies the agent's seat, the chain walks up to the next Steward. Delivery is idempotent: a retried run never notifies you twice for the same escalation, and the notification carries only summarized, redacted evidence — never secret material.

Safety refusals read distinctly

When an agent declines a task on safety grounds it raises a first-class safety refusal, not a silent stall. The escalation carries a category of safety_refusal that every read surface (the queue reads, the CLI/MCP escalation.list/escalation.get output, and the steward notification) shows differently from an ordinary held tool call — the notification reads "refused (safety)" and names that the agent declined and is waiting on you. A cloud run that ends because the agent refused is labeled "declined (safety)" in its run summary rather than reported as a plain success, so a refusal is always visible as a refusal.

Where notifications land

Every notification sent to you — escalations, approval requests, sync briefs, and your daily digest — also appears in your in-app Inbox, with unread state you can clear. A Slack or email delivery that fails is retried automatically on a bounded schedule; once it can no longer be delivered it stays visible in the Inbox rather than being lost. A once-a-day digest rolls up the day's deliverables, open approvals, and exceptions into a single message, so a quiet day stays quiet and a busy one is summarized in one place.

Work the queue from CLI or MCP

The Steward reads the queue from any surface but decides as a human.

• Read: rost escalation list --json / escalation.list / rost_list_escalations (own steward chain for humans, own seat for agents). Read one with rost escalation get / escalation.get / rost_get_escalation — evidence, recommendation, and decision state. An item may carry a short title (≤90 chars) the raising agent wrote as the "Needs you" headline; the full narrative stays in reason.
• Decide: rost escalation resolve / escalation.resolve and rost escalation reject / escalation.reject. escalation.resolve and escalation.reject are none at the confirmation layer, but they are deliberately NOT exposed over MCP — decisions.decided_by must be a human, so there is no rost_resolve_escalation tool. They are kept human-only by that MCP exclusion plus the human-only decided_by, not by a confirmation gate. The CLI runs them as the authenticated human; an agent session must hand the decision to a person.
• Approve gated requests: when an escalation or Charter change produces a pending confirmation, the human approves with confirmation.approve (or rejects with confirmation.reject). Go-live runs through agent.go_live.

Blocked — awaiting grant

Sometimes an agent cannot proceed because a specific grant is missing — a tool capability its Charter does not cover, an OS permission on its Runner, a provider connection that needs reconnecting, or a vaulted credential. When that happens the attempt does not sit paused holding compute: it terminates cleanly, releases its lease, and records a durable "blocked — awaiting grant" item with the exact missing grant and a bounded checkpoint. The item surfaces on the agent's seat and in Home's "Needs you" band with the specific ask and a one-click grant.

Granting is a human decision. A one-time grant authorizes the exact action the agent blocked on and nothing more — it revalidates your current authority and never widens the Charter; if the action changed since it blocked, the stale grant is refused rather than replayed. Choosing to always allow that capability is a separate Charter re-sign, not a one-click action. Declining keeps the checkpoint for audit and creates no continuation. When you grant, a new linked continuation attempt is created from the checkpoint — the agent resumes from where it stopped, not from the start.

• Read: rost command run agent_grant_intervention.list --json / agent_grant_intervention.list — the open blocked items with their blocker kind, missing grant, and checkpoint (secret-scrubbed metadata only).
• Grant or decline: agent_grant_intervention.decide (action: grant or decline). A grant writes your decision (decisions.decided_by is you) and enqueues the continuation; a permanent grant returns requires_charter_resign so you review and re-sign the Charter instead of widening authority in place.
• Resume: agent_grant_intervention.resume retries only the continuation enqueue for an already-granted item whose enqueue did not complete — it never re-grants authority.

When to stop for confirmation

Every steward decision is the human gate itself. An agent never calls resolve, reject, approve, or go-live on a human's behalf. It prepares evidence and a recommended action and stops. See the confirmations guide.

Good Steward habits

Keep agent scope tight at first. Approve more autonomy only after evidence. Use escalations to improve the system: clarify a responsibility, add a measurable, remove a tool, or split a seat.