# Autonomy, rooms, and Conductor

>  © 2026 Quadropic Pvt Ltd. Proprietary and confidential. [Use restrictions](NOTICE.md).

Autonomy is Syntheo’s board for work that benefits from staging, lifecycle visibility, shared objectives, or multiple agents. It is not automatically better than one focused thread.

## When multi-agent work pays off

Use one thread when:

- one subsystem owns the change;
- tasks depend on the same evolving implementation;
- the job is mostly sequential;
- the work is small enough for one context;
- coordination would take longer than execution.

Use a room and several agents when:

- work splits into genuinely independent scopes;
- different workspaces must be coordinated;
- discovery, implementation, tests, and review can proceed with clear ownership;
- a long project needs durable shared artifacts;
- one integration owner can combine results.

Bad fan-out:

```text
Have five agents all investigate this bug and tell me what they find.
```

Better fan-out:

```text
Use one investigator to own reproduction and root cause, one owner for the
client state layer, one owner for the API consistency fix, and one reviewer for
the integrated diff. Do not duplicate full-suite validation.
```

## General Hall and named rooms

**General Hall** is the unscoped triage area. Use it for:

- ideas that are not ready to run;
- single agents that do not need shared state;
- short-lived tasks;
- sorting work before assigning it to a project room.

A **named room** has a name and objective. Use it for a coherent initiative such as “OAuth refresh hardening” or “July onboarding polish.”

Named rooms provide:

- room-scoped task lists;
- Exposé, Kanban, and Detailed views;
- shared coordination context for agents;
- durable room artifacts;
- an optional shared worktree.

Make the objective outcome-oriented:

```text
Ship consistent session-expiry behavior across the web client and API, with one
user-visible outcome and regression coverage for refresh and offline recovery.
```

Avoid room names that become meaningless later (“stuff,” “phase 2,” “fixes”).

## Views

### Exposé

The spatial floor shows rooms and agent avatars. Use it to:

- see where work is happening;
- drag tasks into rooms;
- open context menus for room or agent actions;
- create rooms and agents from a location;
- spot agents that need input.

### Kanban

Kanban organizes agents by lifecycle:

- **Triage / To do** — staged, not running;
- **Planning** — Architect work or planned state;
- **In progress** — working or interrupted;
- **Completed** — finished and ready for review/archive.

Moving a card expresses lifecycle intent. Starting and stopping are still explicit runtime actions.

### Detailed

Detailed view combines room conversations and merged changes. Use it when the room has several workers and you need to inspect messages or select a specific agent. Detailed view is available for named rooms, not General Hall.

## Create a useful agent task

The task form includes:

- **Task** — a short outcome title;
- **Preset** — the model lane;
- **Plan** — whether the first run should Architect before implementation;
- **Description** — full acceptance criteria;
- **Context Brief** — room/project facts the worker needs;
- **Workspace** — the base project;
- **Worktree** — execution isolation;
- **Priority** and **Tags** — board organization.

### Worktree modes in a named room

**Inherit:** Use the room’s worktree. Best for agents contributing directly to one integrated deliverable.

**Detached:** Use the base workspace rather than the room worktree. Best for read-only research or work that must not see unmerged room changes.

**Child:** Create an isolated child worktree. Best for risky sub-changes or alternatives that need a later integration decision.

In General Hall, the Virtual Edit toggle creates a child worktree for the task.

### Plan first

Enable **Plan** when:

- requirements are incomplete;
- the change spans several layers;
- data migration or API compatibility is involved;
- you want to review affected files and validation before implementation.

The planning run writes a durable plan. After review, resume/run the task to implement. Skip Plan for mechanical changes whose acceptance criteria are already precise.

## Agent lifecycle actions

Right-click an agent or use its details:

- **Open / Review** — inspect the linked thread.
- **Edit Task** — change brief, priority, tags, preset, or worktree mode.
- **Plan** — start an Architect run for an idle task.
- **Run / Resume** — start or continue implementation.
- **Stop** — interrupt a running agent.
- **Drop** — remove an idle staged agent.
- **Archive** — remove a non-idle agent from active views while preserving history.

An interrupted task belongs in In Progress until you decide to resume, revise, or archive it.

## Room worktree workflow

1. Create a named room and enable its worktree.
2. Write an objective with acceptance criteria.
3. Create tasks with non-overlapping ownership.
4. Use **Inherit** for contributors to the shared implementation.
5. Assign one integration owner for shared files and final assembly.
6. Assign one validation owner for project-wide tests.
7. Review the combined diff.
8. Use **Merge into main** from the room menu.

Because inherited agents write to the same worktree, parallel edits to the same file can collide. The harness provides coordination; it cannot make ambiguous ownership safe.

## Use Conductor

Open Conductor from the Autonomy edge control or with:

- macOS: `⌘⇧C`
- Windows/Linux: `Ctrl+Shift+C`

Conductor can coordinate one or several selected directories. Its sessions are durable and searchable from the task history menu.

### What Conductor can do

- create or select rooms;
- set room objectives;
- create board tasks;
- start every created task;
- steer running workers;
- stop workers;
- make dependencies explicit;
- ask workers to write durable room artifacts.

Creating a task card does not by itself start an agent. Say **start/run every worker** when you want immediate execution.

### A strong Conductor prompt

```text
Coordinate the implementation of consistent search filters across the selected
client and API workspaces.

Create one named room with a shared objective. Decompose into:
1. reproduction and root-cause evidence;
2. client state and UI fix;
3. API query and compatibility fix;
4. focused regression tests;
5. final integrated review.

Assign exclusive file/subsystem ownership. Start every created worker except the
final reviewer, which must wait for the implementations. Use one shared
full-suite validation owner; do not make each worker run it. Put the root-cause
record and integration checklist in room artifacts. Stop and ask me before any
protocol-breaking change.
```

Include:

- selected directories;
- final outcome;
- decomposition you care about;
- ownership rules;
- dependency order;
- which tasks should start now;
- shared validation policy;
- destructive or compatibility boundaries.

### Steer Conductor

While Conductor runs, send short operational deltas:

```text
New constraint: the client must remain compatible with API v1. Keep response
changes backward-compatible and notify the API owner.
```

```text
The investigator confirmed the bug is client-only. Stop the API implementation
task and reassign the test owner to client regression coverage.
```

Conductor can coordinate, but you should still inspect the board. Verify that created cards are actually In Progress when execution was requested.

## Durable room artifacts

Use artifacts for shared information too long or important for chat nudges:

- specifications;
- root-cause reports;
- API decisions;
- integration checklists;
- test evidence;
- review findings;
- plans.

Ask the owner to write a named artifact and tell peers the path:

```text
Write the approved compatibility decision to the room artifacts directory as
api-compatibility.md. Announce only a one-line summary and the path.
```

An artifact should record:

- scope and owner;
- applicable revision/worktree;
- decision or result;
- commands and outputs that matter;
- unresolved issues;
- when the artifact becomes stale.

## Coordination anti-patterns

- Several agents editing the same central file without an owner.
- Every worker re-running the same expensive build.
- A reviewer starting before dependencies finish.
- Long specs repeated in every message instead of one artifact.
- Creating agents for trivial local tasks.
- Assuming a created card is a running worker.
- Merging a room worktree before reviewing its combined state.
- Leaving completed room work unarchived so active views become historical logs.