OpenClaw Runtime Roster

This doc maps the current live runtime on argobox-lite to the target engineering organization defined in the operating-system docs.

The goal is to stop treating the runtime as a set of generic seats and start treating it as an explicit engineering team.

Canonical Runtime

The canonical networked runtime is the OpenClaw gateway on argobox-lite (10.0.0.199).

This workstation can keep a local mirror for development and testing, but the production roster should be defined against the remote runtime first.

Current Live Roster Snapshot

Observed current agent IDs:

• main
• fast
• reasoning
• decision-safe-implementer
• deep
• cheap-coder
• verifier

That roster is workable, but it is weakly named and only partly specialized.

Target Role Map

Use the following target roles:

Target Role	Current Seat	Immediate Use
conductor	main	intake, routing, dependency control
sprint-lead	reasoning	sprint packets, scope discipline, board updates
architect	deep	architecture, decomposition, tradeoffs
builder	cheap-coder	default implementation lane
reviewer	verifier	code review, regression review, acceptance challenge
verifier	fast	quick acceptance checks, evidence collection, doc completeness
builder-safe	decision-safe-implementer	bounded implementation for explicitly ruled decision work
doc-curator	new seat or shared fallback	docs, runbooks, change records, backlog hygiene

Role Notes

Conductor

Rename or mentally treat main as conductor.

Rules:

• route work
• keep sprint flow coherent
• do not turn into the main builder

Sprint Lead

Use reasoning as the planning seat.

Rules:

• owns the sprint packet
• keeps acceptance criteria current
• decides whether a task is ready, blocked, or needs huddle

Architect

Use deep for cross-module reasoning and hard design choices.

Rules:

• architecture only
• not the default lane for routine coding
• escalates governance work instead of deciding it alone

Builder

Use cheap-coder as the default coding seat.

Rules:

• build within the sprint packet
• leave tests, assumptions, files changed, and risks
• never self-approve

Reviewer

Use verifier as the main independent reviewer.

Rules:

• findings first
• reject unsafe or incomplete work
• focus on bugs, regressions, and missing tests

Verifier

Use fast as a distinct acceptance seat when the task needs evidence but not deep reasoning.

Rules:

• confirm tests or explicit test gaps
• check docs and rollout evidence
• confirm the task matches acceptance criteria

Builder-Safe

Keep decision-safe-implementer as a special lane, but narrow its meaning.

Rules:

• only for implementation that is already clearly authorized by an existing decision or bounded ruling
• not a judge
• not a shortcut around huddles or governance

Doc Curator

Add a dedicated doc-curator seat when practical. Until then, let fast or reasoning temporarily cover documentation chores that are not acceptance-critical.

Rules:

• keep docs discoverable
• update runbooks, sprint packets, changelogs, and indexes
• reduce rediscovery cost for later agent turns

Model Strategy

Keep model choice subordinate to role quality.

Recommended bias:

• conductor: strong reasoning lane
• sprint-lead: strong reasoning lane
• architect: strongest reasoning lane available
• builder: strongest coding lane available
• reviewer: separate strong coding/review lane
• verifier: fast reliable lane with tooling
• builder-safe: conservative lane with narrow authority
• doc-curator: medium-cost documentation lane

Do not use the same weak seat as both builder and reviewer just because it is convenient.

Minimum Config Changes For The Next Pass

• rename the generic seats in config or operator docs so role names are visible
• make the conductor and sprint-lead read the sprint artifacts first
• keep reviewer and verifier logically separate from the builder
• preserve decision-safe-implementer as a bounded special lane instead of letting it grow into a fake judge
• add doc-curator when the runtime can support one more seat

Success Condition

This roster is good enough when a new task can be handed to the runtime and the next question is "which role owns it?" instead of "which random model should answer?"