Responsibility Graph playbook

The Responsibility Graph is the company's operating structure. It answers who owns what, where authority sits, and how work flows when people and agents share the company.

Design rules

• Build functions before names.
• Give every active seat one accountable owner or one clear vacancy.
• Keep reporting and accountability clean. Avoid shared ownership for the same outcome.
• Let one human occupy multiple seats when the company is still small.
• Show vacant seats instead of hiding gaps.
• Give every agent seat a human Steward chain.
• Attach goals, measurables, and tasks to seats, not directly to people.

Add an agent from the graph

Agent creation is a first-class graph action. From a seat in the Responsibility Graph you can open the agent setup wizard with the seat already chosen as the parent:

• Hover or focus a seat to reveal the Add agent control next to Open charter and Edit seat.
• Open a seat's side panel and use Add agent beside Add child seat.
• Use the graph toolbar Add agent action, or Add first agent on an empty or small graph.

Each entry opens the same conservative setup flow — seat placement, Steward, draft Charter, manifest sign-off, sandbox dry run, and human go-live — with the graph seat prefilled as the parent and its Steward chain offered as the default Steward. In the public read-only demo the control is omitted; it never starts a write you cannot finish.

Read the graph in the app

The graph canvas fits the whole structure into the frame when it opens and refits whenever the frame changes — opening a side panel, resizing the window, or rotating a phone. Zoom moves between three altitudes: a constellation of seat dots when zoomed out, seat cards at the working zoom, and charter detail when zoomed in. Seat cards stay legible on small screens, and the canvas is the one always-dark surface in the otherwise light app. Search the toolbar to fly to any seat by name.

The graph is also where you land after onboarding — it is the mission control for the company, not a separate dashboard. Switch lenses from the toolbar to recolour the same structure four ways:

• Structure — seat type and reporting lines.
• Cascade — whether each seat's goal branch is on track.
• Signal — the worst measurable state per seat.
• Scoreboard — two live numbers on every seat: work done (agent runs) and cost over the last 30 days. A seat whose cost is a clear outlier above the rest of the fleet is flagged as cost drift (labelled, not colour-only). Human seats and seats with no runs read calmly as no agent cost rather than a bare zero. For a small fleet the Scoreboard also leads with a two-tile summary — total work and total cost — framed as the single question that matters: is it earning its keep.

First-pass structure

Start with the operating root, then major functions, then the few seats that own the most important recurring work. Do not over-model. A graph with eight clear seats is better than a graph with thirty vague boxes.

Each seat needs:

• Name
• Purpose
• Seat type: human, agent, or hybrid
• Parent seat
• Occupancy or vacancy
• Steward, when the seat has an agent
• Initial Charter status

Common setup mistakes

• Starting with employee titles instead of functions.
• Creating shared seats where nobody is finally accountable.
• Hiding work under a leader instead of creating the real operational seat.
• Staffing an agent before a Charter defines authority and escalation.
• Treating vacant seats as failure instead of useful structure.

Operate the graph from CLI or MCP

Read before you write. Load the whole graph first so seat ids, parents, and occupancy are known.

• CLI: rost command graph.get --json '{}' (scope: tenant). Returns seats, edges, root, occupants, and status rollups.
• MCP tool: rost_get_responsibility_graph with {}; or read the resource rost://graph (tenant-admin token).
• One seat: rost command seat.get --json '{"seat_id":"<seat-id>"}' or rost_get_seat_detail.

Then mutate with the smallest change. Create returns the new seat_id:

rost command seat.create --json '{"name":"Finance","seat_type":"human"}'

Rename, reparent, and set-type take an existing seat_id. The MCP aliases are rost_create_seat, rost_rename_seat, rost_reparent_seat, rost_set_seat_type.

Decommission a seat

Retiring a seat is a single audited action. In the app it is the Let go control on the seat page; on the CLI/MCP path it is the seat.decommission command:

rost command seat.decommission --json '{"seat_id":"<seat-id>"}'

It ends every occupancy, archives the seat's active Charter, revokes the seat's MCP tokens and credentials, cancels any agent schedules, and marks the agent and seat decommissioned with a tombstone event — one transaction, one audit row. It is human_required and no-orphan guarded: an interactive human runs it directly; an agent or non-interactive caller is deferred to a human confirmation, and if retiring the seat would leave another live agent without a human Steward chain, the whole change rolls back. To retire only the agent and keep the seat available for re-staffing, use agent.decommission (the seat-page agent operations panel) instead.

When to stop for confirmation

seat.reparent, seat.set_type, and seat.decommission are human_required; seat.create and seat.rename are none, so an agent can add and rename seats directly. The structural commands return a pending confirmation with an approve link over MCP instead of mutating; the human approves with confirmation.approve. Never approve your own structural change from an agent session — surface the pending confirmation to a human. When a seat-targeted command does execute, its audit row is scoped to that seat (queryable by seat_id); on the deferred MCP path the executed audit is recorded against the human's confirmation.approve. See the confirmations guide.

Agent guidance

When operating through CLI or MCP, create fewer seats first and ask for confirmation when the structure would change authority. Prefer draft seats and draft Charters until a human approves the setup.