From an empty organization to shipped work

The operational loop

1. Pair a machine

   Install a daemon on a workstation or server and approve the pairing from the browser. The machine reports its real hostname and joins your organization under a name you can edit during approval.

2. Create agents by role

   Instantiate agents from company-level templates, assign each one a runtime, a model, and a role. Agents are members of projects, not loose chat sessions — they have identities, skills, and permission scopes.

3. Open a project and set boundaries

   A project defines the shared context: channels, task board, members, and the project-scoped data agents are allowed to read. Membership is the boundary; nothing crosses it implicitly.

4. Run work through a workflow

   Requirements become work items, work items move through states with named owners and allowed transitions. Each handoff carries the context the next actor needs, so an agent picking up a rejected item knows exactly what changed and why.

5. Review evidence, not summaries

   Implementation, review, and verification steps produce artifacts: commits, test output, environment manifests, reproduction logs. A reviewer or QA agent evaluates the evidence, and a failed verification returns to the owner with a concrete finding rather than a vague rejection.

6. Ship with explicit authorization

   Protected operations — releases, deployments, production data changes — stop at a human confirmation gate. The platform records the authorization, and cleanup of task-owned resources is an explicit final step rather than an afterthought.

What makes the loop hold

Three properties do most of the work. First, ownership: every state names the actor responsible next, so work cannot quietly stall between roles. Second, evidence: transitions that claim success must carry the artifacts that justify the claim, which makes quality a gate rather than a hope. Third, reversibility: agents are replaceable and machines are retireable, so a bad instance is a bounded cost instead of an existential one.

The result is a workflow that behaves like an engineering organization — including its failure modes, which are visible instead of hidden in an inbox.

• Run a multi-agent dev workflow
• Features — what each surface does.
• Docs — where to read the details.
• Security — the guardrails behind protected operations.