ROST implementation method

ROST setup is a staged operating-system implementation. The goal is not to mirror a historical org chart. The goal is to make the company legible enough that humans and agents can operate inside the same accountability model.

Stage 1: Bring the company into view

Start with the company context that already exists: org charts, team notes, planning docs, process notes, metrics, or a founder transcript. The first output is a rough Compass and a draft Responsibility Graph.

Good setup work answers four questions:

• What outcomes is the company pursuing?
• What functions must exist for those outcomes to happen?
• Which seats own those functions?
• Which work can be handled by a human, an agent, or a hybrid seat?

Agents should call onboarding.status before recommending next steps. If context is missing, recommend adding context before creating many seats.

Stage 2: Design functions before staffing people

Build the Responsibility Graph from functions and seats first. Do not start by arranging names. A seat is a function with accountability, authority, and measurable outcomes. A human can occupy more than one seat, and a seat can be vacant while the structure is clarified.

The first graph should be small enough to understand. Start with the top operating seat, then major functions, then the first operational seats that carry measurable work. Add detail only when it clarifies ownership.

Solo founders and small flat teams

If it is just you, or a small flat team of four or fewer people, declare that at the start of org intake. Setup skips the org-chart upload and the "who reports to you" question, and instead asks which functions the company needs covered today. It proposes a standard small-company function tree — company leadership, revenue, sales, marketing, delivery and operations, finance and admin — that you occupy, then pivots straight to which functions to staff with agents. Because there is no one to invite, the team-invite step is skipped. You can still invite people later from settings.

Stage 3: Convert seats into Charters

A Charter is the executable job description for a seat. It should define purpose, responsibilities, autonomous scope, approval scope, must-escalate conditions, measurables, and tool permissions.

For human seats, the Charter creates clarity. For agent and hybrid seats, the Charter becomes operating context and permission boundaries.

Stage 4: Staff carefully

Staffing happens after the seat is clear. A human occupancy should be accountable to the seat's Charter. An agent occupancy must have a human Steward chain and should begin with dry runs before go-live. A hybrid seat must say which responsibilities stay human and which are delegated to an agent.

Durable changes that expand authority require human confirmation.

Stage 5: Run the rhythm

Once the graph is live, run the operating rhythm: Signal tracks measurable health, Friction captures issues, Cascade ties work to goals, and Sync turns the weekly meeting into a decision forum.

The system should surface exceptions before the meeting. Humans should spend Sync time deciding, resolving, and clarifying authority.

When onboarding finishes, the app opens on the Responsibility Graph with a short next-step note: you have a graph, agent seats, and dry runs in place; the next moves are to approve your Compass, add cycle goals, and define the signals you want to track. The same sequence applies whether you continue in the app, the CLI, or an MCP client.

Operate Compass and onboarding from CLI or MCP

The Compass is drafted, then activated by a human through supersession.

• Inspect onboarding: onboarding.status / rost_onboard_status. Attach company reference documents with onboarding.attach_reference / rost_attach_reference_document (text/markdown, with a title, kind, and source; onboarding.upload_context is the back-compat alias). This is reference-only — it lets Compass and Charters cite the docs; you author the Compass directly (see the Compass authoring guide). Advance with onboarding.advance_step; complete with onboarding.finish once graph, Compass, and Charters are ready. Invite teammates with onboarding.create_invite.
• Read the Compass: compass.get_current / rost_get_current_compass or read the resource rost://compass/current (tenant-admin). List context gaps with compass.list_gaps / rost_list_compass_gaps and answer them with compass.answer_gap / rost_answer_compass_gap.
• Draft and activate: compass.draft / rost_draft_compass then compass.update_draft; activate with compass.approve_version / rost_approve_compass_version or discard with compass.reject_draft. compass.set is a compatibility helper for setting the approved Compass over MCP.

When to stop for confirmation

onboarding.finish, compass.approve_version, compass.reject_draft, and compass.set are human_required. onboarding.advance_step, onboarding.create_invite, onboarding.attach_reference, compass.answer_gap, and drafting a Compass are none — none of them returns a pending confirmation. none is not the same as "agent-callable", though: onboarding.create_invite and compass.answer_gap record the human who ran them, so they run as a person, not from an agent session, while advancing a step, attaching a reference, and drafting a Compass are safe for an agent. Approving a version (a supersession) is a human act. The agent drafts and surfaces the approve link. See the confirmations guide.