Rooms and agents

Start deliberately

1. In the Console, create a Room with a descriptive name. It starts Forming, with no agents.
2. Record the purpose and initial direction. Candidate Rooms already contain inputs/candidate.md; Rooms created through /pentest contain inputs/program.md.
3. Select an agent configuration and a healthy Environment. Optionally change the member name or its prompt for this spawn, then preview the composed instructions.
4. Explicitly spawn the first member. The Room becomes Running and that member starts.

A message does not create a member. There is no mandatory Steward: Steward, Recon, Investigator, and Worker are ordinary editable configurations, not runtime types. A member configured as “Worker” is not a Sonar scan-worker container.

Direct a member, not the whole Room

Use the Console's member mentions to select exactly who should receive a chat message. Only those recipients automatically receive it and wake. An untagged message stays in shared history without waking anyone. Members can explicitly read the shared history, including messages sent to other recipients; targeted delivery is not private messaging.

Messages addressed to busy or suspended members remain pending. Stop prevents execution until Resume. A recorded delivery does not prove the requested work succeeded.

Give concrete instructions: identify the question, allowed scope, expected evidence path, and what needs a decision. Keep routine progress in room/status.md and substantial results in descriptive Room files rather than repeating long reports in chat.

Compose the team

Each member has a stable identity, a captured configuration and prompt, and a selected Environment. Editing or deleting the source configuration does not rewrite existing members' instructions. Per-spawn edits change only that member, not the configuration catalog.

Active members can spawn peers in the same Running Room without an operator approval step. There is a maximum of 30 retained members per Room; suspended members still count. Removing a member frees its place after its lifecycle settles and does not remove peers it previously spawned. There is no database Task, claim, assignment, or backend guarantee against duplicated work. Members coordinate through chat, evidence, and their sections of status.md.

Share evidence

All members see the Room's shared UTF-8 text tree at room/, including when they run on different Environments. Online text changes normally synchronize within five seconds. The Console's Files view reads committed snapshots; it is not a file editor.

• Use descriptive paths for notes, scripts, request/response evidence, and results.
• Binary files, invalid UTF-8, and symlinks stay local rather than silently becoming shared evidence.
• Concurrent stale edits are preserved under .room-conflicts/; reconcile them manually.
• status.md is a shared work summary, not a lock or an enforced allocation system.
• Room files are shared material, not a secrets vault. Git snapshots may retain earlier values.

Stop, resume, or remove

First-host acceptance exercise

After following Linux Environment setup, use a disposable Room with an existing configuration and the new Environment. Before spawning, replace the per-member prompt with this harmless instruction:

Do not contact any target or spawn peers. Create room/setup-check.md containing
"Environment setup verified", then wait. Use no external network tools.

Expect the member to start on the selected host and the file to appear in the Console after sync. This exercises agent launch and shared files; a green host health check alone does not. Stop and Delete the disposable Room afterward. This exercise uses the configured model provider and belongs to the operator, not an unattended installer.