Docs

Add agents to your Responsibility Graph

The visual journey for adding an agent seat: where to start, choosing a mode, placing the seat, naming a Steward, setup, the safety gates, and go-live.

staffing

A seat is a function, not a person. Adding an agent means staffing a seat with an agent occupancy that a human Steward is accountable for. This guide walks the visual journey; for the same flow from a terminal, read the agent staffing playbook.

Where to start

You can open agent creation from three places:

  • Responsibility Graph. Hover or focus a seat node and use its Add agent action to add an agent seat under that seat. The graph toolbar's Add agent action adds an agent and then asks where it should report. On an empty or small graph, Add first agent starts the same flow with the founder or owner seat as the default Steward.
  • Left sidebar. The Agents item in the Define section opens the agents surface. Add agent at the top of that surface is the primary action.
  • Agents surface. The unified agents page has Templates, Custom, and Existing modes. A template's Use template action enters the same wizard with that template selected.

Starting from a selected graph seat carries the parent seat and a default Steward candidate into the wizard so you do not re-pick them.

Choose a mode

The first screen asks how you want to create the agent:

  • Use a template — start from a stock template (see the stock agents guide) and adapt it.
  • Design a custom agent — answer operational questions and let the Charter Builder assemble the job (see the custom agents guide). No prompt-writing is required.
  • Connect an existing agent — register a Claude Code, Codex, Cursor, or local Runner agent against a seat (see the stock agents guide's connect section and the local runner guide).

Place the seat and name a Steward

Every agent seat needs an explicit place in the graph and a human Steward:

  • Parent seat — where this seat reports. This keeps the org shape honest.
  • Seat typeagent for a fully agent-run seat, or hybrid to keep a human occupant alongside the agent.
  • Steward — the human accountable for the agent. The no-orphan-agent rule means an agent occupancy and go-live are blocked until a Steward chain resolves to a real person. A solo founder defaults to their owner seat.

Work through setup

The wizard builds a teammate, not a prompt:

1. Responsibilities and authority — what the seat owns, what it may do alone, what needs approval, and what must escalate. Every clause is editable before sign-off. 2. Signals — the measurables the seat is judged on. 3. Tools — connect or decline each proposed tool. Declining a tool updates the permission manifest and the dry-run task so the agent stays safe. Credentials go in through write-only credential ingress and are stored as vault references, never shown again. 4. Schedule and lane — when the agent runs and on which lane. These stay advanced unless the mode needs them.

You can save and resume a draft setup at any point. Returning to the flow restores the parent, Steward, mode, answers, tool decisions, and dry-run result.

The safety gates

Every mode ends at the same conservative gates, shown at each step:

1. Draft Charter — a draft, not an active job, until a human approves it. 2. Signed manifest — a human signs the permission manifest before any tool is live. 3. Sandbox dry run — the agent rehearses a representative task and is expected to escalate where the Charter says it must. A failed dry run keeps the draft and shows the reason; you edit and rerun. 4. Human go-live — a person promotes the agent live. An agent never approves its own setup, signs its own manifest, or goes itself live.

After creation and after go-live, the flow returns you to the graph with the new agent selected.

Reopening the builder for a seat whose agent is already live shows its live state — the same active Charter and passed dry run the CLI and MCP report (agent.status, charter.get) — rather than a disabled draft go-live. If you have started a new revision, the builder shows "live charter vN active; draft vN+1 in progress" so the live agent and the amendment-in-flight are both visible. The web, CLI, and MCP surfaces always read the same charter for a seat.

If something blocks you

  • No valid Steward: the draft is created, but occupancy and go-live stay blocked until a human Steward exists. Add one and continue. Naming a brand-new seat and adding an agent to it works even before you choose a Steward — a tenant owner can create the draft, and the Steward step comes next; go-live stays blocked until the Steward chain resolves to a real person.
  • Parent or Steward seat archived during setup: go-live is blocked until you choose a live parent or reassign the Steward.
  • Failed dry run or a declined tool: the draft is preserved; fix the Charter or tool decision and rerun. See the troubleshooting guide.

In read-only or demo mode the Add agent affordance never starts a write. The public demo instead replays the add-an-agent journey end to end — describe the role, watch the draft Charter assemble, see the four safety gates light, and watch a sandbox dry run reach the must-escalate boundary and stop — then routes go-live to sign-up, because going live is a human decision.