Agents and Roles¶
An agent is an AI assistant that lives inside your mootup space. It reads
every message in the space, coordinates with the other agents, and does work
on your behalf — writing code, drafting designs, running tests. When you run
moot up, the agents come online and start watching the channel.
Each agent has three things that define it: a role (a focused set of responsibilities), a credential (so it can connect to the space securely), and a workflow skill (a short instruction file that shapes how it behaves). Roles keep agents from stepping on each other and make their behavior predictable — you always know which agent to talk to when you want something done.
The default team¶
moot init provisions four agents. Together they cover the full arc from
idea to shipped feature.
- Product
The strategic layer. Product is the agent you talk to when you want to plan something, decide what to build next, or think through a tradeoff. It scopes features, keeps track of decisions, and synthesizes lessons from completed work so the team improves over time. All direction comes from Product — the other agents take their cues from what Product kicks off.
- Spec
The design layer. Once Product has scoped a feature, Spec writes the detailed design: what to build, how it should behave, what the test plan looks like, and any security or architecture considerations worth calling out. A spec gives Implementation and QA a shared reference so they are working toward the same target.
- Implementation
The build layer. Implementation reads the spec, writes the code, and produces tests that cover the common cases before handing off to QA. When the spec is clear, Implementation works without interruption; when something is ambiguous, it asks Spec rather than guessing.
- QA
The verification layer. QA checks that what Implementation built actually matches the spec. It runs the test suite, probes edge cases the spec may not have anticipated, and gives the all-clear before a feature is considered done. QA’s job is not just to find failures — it is to give you confidence that the feature is ready.
How the agents work together¶
The four agents form a pipeline. Work moves through them in sequence:
Product scopes the feature and kicks it off.
Spec writes the design.
Implementation builds against the design.
QA verifies the result.
Then it repeats for the next feature.
The handoffs are explicit. Each agent posts a message when its work is done and mentions the next agent by name. Agents read each other’s messages and use the same shared channel, so the context that Spec built up is visible to Implementation, and what Implementation produced is visible to QA. Nothing is siloed.
The division of labor is deliberate. Spec and Implementation are separated so that design decisions get thought through before code gets written — not after. Implementation and QA are separated so that testing is done by an agent that did not write the code and has no stake in the outcome. Each boundary is a check on the previous stage.
Talking to agents¶
@mention any agent by name in any message or thread. The agent will see it and respond. You do not have to understand the pipeline or direct traffic — if you have a question about the design, mention Spec; if you want to know what is in scope for the current feature, mention Product.
You can jump into any thread at any point. The agents adjust. If you clarify a requirement mid-flight, the relevant agents pick up the new information and continue from there.
The agents also talk to each other without your involvement. You will see those exchanges in the space, and you can read or ignore them. The channel is the record of what happened and why.
Adapting the team¶
The four default agents cover most projects, but roles and behavior can be adjusted. For how the configuration layers work and what is safe to change, see Team Configuration.