id

First Team

A practical method for building your first agent team, starting with a CTO, keeping one chain of command, and dispatching named tasks

First Team#

Deploying agents is the easy part. The hard part is arranging them so the work stays coherent: one place decisions are made, one plan everyone builds against, and a record of progress you can check without asking.

This page describes a method for standing up your first team and keeping it coherent as it grows. It assumes the Dashboard or the core is installed and a manager is connected; if that is not done yet, start with the Quick Start.

The Method#

1. Make a CTO right away#

Before you deploy any worker agents, deploy a CTO. Ask your manager to deploy the cto config, which ships with the core and adds a single cto agent to the default team. You do not need to know the command; the manager has the admin-control skill and knows how to drive the daemon.

The CTO is the agent that holds the plan, splits it into work, and hands work out. Standing it up first means every later decision has an owner. If you deploy workers first and add a CTO afterwards, you have to re-explain the build to it, and the workers have already started from your instructions rather than its plan.

2. Tell your manager to talk only to the CTO#

The manager is the coding agent you connected in the Quick Start, and it is the layer you speak to. Instruct it that the CTO is its only counterpart on the team. It does not message workers, and it does not answer worker questions directly.

This is a standing instruction, not a one-off. Give it once, at the start, and restate it if the manager starts routing around the CTO.

You can make the shape explicit in the team config so agents can read their own reporting line. The org: key generates an ORG_CHART.md at deploy time and injects each agent's role into its identity skill (see Configuration -- Org Chart):

org:
  groups:
    engineering:
      lead: cto
      description: "CTO fans work out to the development layer"
      members: [cto, coder, researcher]

3. Write the plan with the CTO, and read it yourself#

Work the plan out with the CTO in conversation, then have it write the plan to a file and ask your manager to read that plan back to you.

Read the whole thing. This step is the one people skip, and it is the one that matters most. A plan you have not read is a plan you cannot review against later, and the CTO will dispatch from it whether or not it matches what you wanted. Reading it is also how you find the parts the CTO guessed at.

The goal is that you and the CTO understand the build the same way. If you disagree with something in the plan, fix it now, while it is one document, rather than after it has become six agents' worth of work.

4. Ask for a commit-by-commit execution plan#

Once the plan is settled, ask the CTO to turn it into an execution plan: an ordered list of commits, each with a named task the CTO can dispatch to a teammate.

Commit-sized units are the right granularity. They are small enough to review, they map onto something a single agent can finish in one pass, and the names carry through to the task list.

Ask for each entry to carry:

FieldPurpose
Task nameA short kebab-case name, reused as the task's real name so the plan and the task list refer to the same thing
Assigneewhich agent the CTO will dispatch it to
Scopewhat the commit changes, and what it deliberately does not
Dependencieswhich task names must be done first
Verificationhow the agent proves it worked (build, lint, test)

The CTO then creates each task and dispatches it. Use the names from the plan as the task names so the plan and the task list refer to the same things.

5. Ask for milestone updates to the manager#

Tell the CTO which points in the execution plan warrant a report back to the manager: the end of a phase, anything that changes the plan, anything blocked. Those reports land where you read them, so you review at the boundaries instead of watching every commit.

For a long-running build, a recurring nudge to the CTO keeps the reports coming without you asking. Ask your manager to schedule one, either way round:

  • On an interval — for example every four hours, asking the CTO for a status roll-up.
  • At a fixed time — for example a 17:00 end-of-day summary on weekdays.

Either kind can be listed, paused, or removed later, so a schedule you no longer want is not permanent. The exact commands and their options are in the CLI Reference.

The Shape This Creates#

A single chain of command#

You talk to the manager. The manager talks to the CTO. The CTO fans work out to the development layer and collects results back.

You
 │
 ▼
Manager  ──────────►  CTO
                       │
              ┌────────┴────────┐
              ▼                 ▼
            coder           researcher

With the default config plus the cto config, that is exactly what you get: a CTO with two agents under it, coder (writes and reviews code) and researcher (research, analysis, and documentation). Deploy both configs and the three agents share the default team.

Three agents is enough to see whether the shape works. Add agents to the development layer as the build needs them; the chain of command does not change when the team grows, only the width of the bottom row.

Why the single chain matters#

Two reasons, both of which show up fast when you skip it.

Conflicting instructions. If you message a worker directly while the CTO is dispatching to it, the worker has two sources of truth and no way to rank them. It will usually follow whichever arrived last, which means your instruction silently overwrites the plan, or the plan silently overwrites yours.

Duplicated work. If two agents can both hand out work, neither knows the full set of what has been handed out. The same file gets edited twice, in two directions, and someone has to reconcile it.

Routing everything through the CTO makes both impossible by construction. The CTO is the only agent that dispatches, so it always knows the full set of outstanding work.

When you do need to talk to a worker directly, tell the CTO what you said. An out-of-band instruction the CTO does not know about is exactly the conflicting-instruction case above.

Why named tasks matter#

Verbal progress does not survive. An agent that reports "working on the auth refactor" in a reply gives you nothing you can query an hour later.

Named tasks do survive, because the platform tracks them for you. Every task moves through the same three states:

StateMeaning
todoPlanned, but nobody has started it
doingAn agent has claimed it and owns it
doneFinished

Because every unit of work goes through those same transitions, the state of the build is a query rather than a conversation. Ask your manager to list the tasks at any point and you get the real state, not a summary someone wrote for you.

Anything still todo was planned but not started. Anything doing has an owner. Anything done has a name you can match back to the execution plan from step 4. The TUI shows the same transitions as task.created, task.claimed, and task.done events in the news feed, and the Tasks view in the macOS Dashboard reads the same lifecycle.

Tip: Include task-discipline in defaults.skills in your team config. It tells every agent to run the lifecycle for all non-trivial work, so the task list stays complete rather than covering only the work someone remembered to name. See Configuration -- Skills.

Checklist#

StepDone when
CTO deployed firstThe cto agent is running before any worker
Manager scoped to the CTOThe manager has a standing instruction naming the CTO as its only counterpart
Plan written and readA plan artifact exists in the CTO's output/, and you have read all of it
Execution plan producedEvery commit has a task name, an assignee, and a verification step
Milestones definedThe CTO knows which points trigger a report to the manager
Tasks named, not verbal/task list accounts for every unit of work in the execution plan

Related#