Docs

Friction guide

How to capture issues with evidence, rank them, and resolve them without losing ownership.

operating rhythm

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.

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.