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.

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; 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 agent's task lands as a draft proposal (origin: agent_proposal) for a human to review and hand off — not a live offer in the owning seat's accept/decline queue. A seat runs its 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.

When to stop for confirmation

friction.resolve is human_required; resolving an issue is a human decision. friction.link_task, task.create, task.accept, task.decline, and task.complete are none, so a seat files issues, creates commitments, and runs its own task queue directly. 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.

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.