Teams
A team is a hire, not an app. It has no dashboard and no widgets. You talk to it, give it work, and it decides how to get the work done. Use a team when the path changes with the request, and an automation when the path is always the same.
A team or an automation?
This is the only decision that really matters, and getting it wrong is the usual reason something disappoints. Both are built on the same manifest. They differ in who chooses the order of the steps.
| Automation | Team | |
|---|---|---|
| Who decides the steps | You do, once, when it is built | A coordinator, at run time, per request |
| Shape | A fixed pipeline (type: dag) | A roster (type: team) |
| Good for | “Every weekday, chase overdue invoices.” | “Handle whatever comes into this inbox.” |
| You see it as | A page with runs and receipts | A room you talk to |
| Bad fit when | Requests differ every time | The task is identical every time, and you are paying a model to rediscover it |
The Team Room
A team is a headless app, so the room is its whole interface. It has four tabs.
- Work
- Initiatives and tasks. What the team is doing, what it finished, and what it is waiting on.
- Chat
- Where you talk to the team. Ask for something and it becomes real work, not a reply.
- Team
- The teammates, their roles, and what each one is allowed to touch.
- Knowledge
- The documents and data sources the team may read, and the record of what it read.
Asking for work
Messages in Chat are not a chatbot exchange. When you ask for something that requires action, the team spawns a task, does it, and reports back with what it actually did. A task keeps a record of every external action it took, so “I have emailed the three vendors” can be checked rather than believed.
Correcting it
Tell the team when it got something wrong. That feedback is kept as a standing directive and applied to later work, so the same correction does not have to be given twice. This is the intended way to shape a team. Rewriting its instructions from scratch is not.
What a team is made of
In the manifest, a team is a workflow with a roster instead of steps. The coordinator is handed the request and the roster, and decides who does what until it has an answer.
workflows:
- id: handle-request
type: team
team: [researcher, writer, reviewer]
maxIterations: 8
budgetCents: 40
inputs:
request: { type: string, required: true }
outputs:
result: "${coordinator.output}"| Field | Meaning | Bounds |
|---|---|---|
team | The teammate agent ids the coordinator may delegate to. | Must not be empty. |
maxIterations | How many delegations before the coordinator must finish. | Defaults to 8. Between 1 and 50. |
budgetCents | An upper bound on model spend across the whole run. | Caps the sum of the teammates’ own budgets. |
coordinatorPrompt | Extra instructions for the coordinator itself. | Optional. |
team workflow must not declare steps, and a dag workflow must declare at least one. The manifest is rejected at load if you mix them, which is better than a team that silently runs a fixed pipeline.Connections and knowledge
A team owns its own connections rather than borrowing yours, so you can see exactly which accounts it can reach and revoke one without affecting anything else. Data sources added under Knowledge are governed: the team may read them, and each read is logged against the task that made it.
A team can also be reached from Slack. Messages sent to it there arrive as work, and its replies come back in the same thread.
Winding one down
Deactivating a team stops its scheduled work and keeps everything it did. Deleting removes the team and its history. Deactivate first if you are not sure, because the record of what it did is usually the part you want to keep.