Architecture Shipped
The composition model, the three workflow engines a command can run on, and the reason teams ship data rather than code.
The composition
Dispatch is team-first: the first argument is a team, the second is one of that team's commands. There is no intermediate grouping layer and no verb-first fan-out. The surface you see when you type myteams is the union of what the installed, enabled teams contribute — nothing is hardcoded into the front door.
What lives where
| Layer | On disk | Owns |
|---|---|---|
| Engine | pipeline/engine/source/ | Dispatch, changeset, review stages, contracts, event store, providers |
| Registry | ~/.myteams/teams/teams.json | Which teams are installed, and which are enabled |
| Team | teams/<name>/ | team.json, team.md, specialists/, specialities/, evals/ |
| Specialist | specialists/<name>/specialist.md | One review lens, and the specialties it owns |
| Specialty | specialities/<area>/<name>.md | Worker Focus, Verify criteria, optional signal gating |
Three workflow engines, declared per command
A command names the engine it runs on. specialist-pipeline fans out to every relevant specialist in parallel, verifies, confidence-scores and merges — that is devteam's reviews, researchteam's research, storyteam's narration. authoring dispatches one dedicated agent to write one artifact against templates and instructions — cookbookteam, socialteam, most of teambuilder. roadmap walks a declared node graph, and is used today only by projectteam's schedule.
Which team runs on which engine
| specialist-pipeline | authoring | roadmap | |
|---|---|---|---|
| devteam | yes | no | no |
| researchteam | yes | no | no |
| storyteam | yes | no | no |
| cookbookteam | no | yes | no |
| socialteam | no | yes | no |
| teambuilder | no | yes | no |
| projectteam | no | no | yes |
| brainstormteam | no | no | no |
| teamtester | no | no | no |
Counted from the objective definitions: authoring carries ten objectives, specialist-pipeline five, roadmap exactly one. Nothing stops a team from spanning two engines — the declaration is per command, not per team — but none does today. The empty rows are not omissions: brainstormteam is interactive and declares no objective, and teamtester drives the other teams through builtins rather than running an engine of its own.
The roadmap engine is honestly v1
Its own source says gate nodes — the ones that would collect a human verdict mid-run — fail fast at plan time until an interactive runner exists. Projectteam's schedule does not use a gate node, so nothing shipping today is blocked by it, but it caps what any future roadmap-based command can do.
Teams ship no code
Every team's planner points at the same generic objective planner in the engine. A team may optionally ship a playbook for the roadmap runtime, discovered by convention and never imported by name. That is what makes a team something you can author, judge and improve as data — and it is why teambuilder can generate a working team end to end without writing Python.
Four layers, bottom to top
- The engine — generic Python. Dispatch, changesets, the review pipeline, the acceptance-contract kernel, the event store, the provider adapters.
- The registry — one JSON file listing installed teams, each with its identifier, blurb, command summary, attribution and enabled flag.
- A team — a self-contained directory: a spec, a roster of specialists, their specialties, prompts, and an eval fixture. Ships no Python.
- A specialist, and inside it a specialty — one narrow competence, carrying the focus a worker reviews against and the criteria a verifier checks it for.
Why "the engine names no team" is the load-bearing claim
It is stated as a design invariant, and it holds: every occurrence of a bundled team name inside the engine source is a comment, a docstring example, or a usage hint in an error message — never an import and never a dispatch branch. That is what makes a team droppable. Adding one is a directory plus a registry entry; deleting one touches no engine code and breaks no other team.