Friction guide

Friction is where operational issues become visible. A good Friction item is specific, evidence-backed, and owned by a seat.

Good Friction items

• State the observable problem.
• Include evidence or a broken Signal.
• Name the impacted seat, customer, goal, or process.
• Separate symptom from suspected cause.
• End with an owner, decision, or handoff.

Agent-filed Friction

Agents should file Friction when a measurable breaks, a tool fails, a repeated exception appears, or the Charter says a condition must be escalated. The agent should attach evidence and avoid deciding beyond its scope.

In the app, operational evidence is summarized for humans instead of shown as the primary interface. Incident fields, proposed tool calls, schedules, payload labels, and source links render as readable fields with raw details tucked behind supporting context when useful. Secret-shaped values stay redacted.

The Friction page opens with one computed line — how many issues are open, the oldest one's age, and how many are escalated — followed by the open issues themselves as incident-ticket rows (filer, one-line cause, an escalation chip naming the steward when severity is critical). Resolved issues collapse into a single count that expands into a quiet history list. Filing a new issue and the three-step resolution (root cause, owner task, done-by) both live behind one "File friction" action, which opens a drawer; resolving launches that same drawer already seeded from the row you clicked "Resolve" on.

Operate Friction, tasks, and escalations from CLI or MCP

Friction, tasks, and escalations are the issue-to-action loop. A seat files, a task carries the work, and an escalation routes a decision a seat cannot make alone.

• File and triage: rost friction file ... / friction.file_issue (seat) / rost_file_issue. friction.file_issue takes an optional short title (≤90 chars) for the "Needs you" headline — keep the long narrative in summary. List with rost friction list --status open --json / friction.list / rost_list_friction_issues; move between open and diagnosing with friction.update_status / rost_update_friction_issue_status.
• Carry the work as a task: task.create / rost_create_task (a commitment between seats). task.create is none (no confirmation gate), so an agent can file one directly; an ordinary agent task lands as a draft proposal (origin: agent_proposal) for a target-side human to confirm or decline through task.confirm_proposal / task.decline_proposal in /approvals or the CLI — not MCP, and not a live offer in the owning seat's accept/decline queue. A bounded Trusted task-create grant may skip that draft card: it creates an offered handoff by default, and only creates in_progress when both proposing and target seats are live agent seats resolving to the same current accountable human Steward. A seat runs its live queue with rost task list|accept|decline|complete (task.list, task.accept, task.decline, task.complete). Link a task to an issue with friction.link_task / rost_link_task_to_friction_issue.
• Route a decision: escalation.raise (seat) / rost_escalate sends approval-scope or must-escalate work to the Steward queue. Reads are escalation.list / escalation.get. See the steward queue guide for resolution.

In the app, the Tasks surface exposes the same queue operations for a seat's visible work. Offered handoffs show Accept and Decline actions; Decline opens a reason field and records the reason through task.decline. Edit opens a separate task form for title, owner, due date, and description changes on non-terminal tasks. These controls are standard focusable disclosures so keyboard and pointer users can operate the queue without dropping to CLI.

Friction assist

friction.assist / rost_assist_friction_issue is a read-only advisory for an open issue — call it with the issue id. It returns the most-similar prior resolved issues with their root causes and recorded decisions, a recurring-pattern flag, and recommended options drawn from that history. It never resolves the issue or records a decision — a human still resolves via friction.resolve. The similar-issue recall is deterministic; the short narrative is best-effort and degrades to the deterministic summary when the model is slow or unavailable, so the assist stays responsive and never holds up other work.

When to stop for confirmation

friction.resolve is human_required; resolving an issue is a human decision. Resolve authority is role-scoped: an owner or admin may resolve any issue tenant-wide, while any other member may resolve only issues raised by a seat they occupy or a downstream seat in the Responsibility Graph (their seat subtree). friction.link_task, task.create, task.accept, task.decline, task.confirm_proposal, task.decline_proposal, and task.complete are none, so they do not mint pending confirmations. The proposal decision commands still require a human actor with target-side authority and are app/CLI-only, not MCP-exposed; they are not agent-callable approval shortcuts. friction.update_status, escalation.raise, friction.file_issue, and friction.list are also not gated. An agent files Friction, proposes the task, and escalates; a human resolves or decides the proposed commitment.

Resolution rule

Resolving Friction should produce one of four outcomes: a decision, a task, a Charter change, or a graph change. If none of those happens, the issue was probably only discussed, not resolved.