Roles

Roles are templates. They seed an agent's soul, purpose, default folder scope, and guardrails, so most of the setup is done before you touch a field. You can always refine from there.

Built-in roles

Manager. Coordinates the team. Breaks a single ask into typed subtasks, assigns them, tracks blockers, and summarises progress. Default guardrails: can spawn other agents within the current map, cannot run shell or edit files directly.

Engineer. Reads the code, writes the code, runs tests. Default guardrails: write on its assigned folders, read on the rest; shell commands limited to the allowed folders; any git push requires approval.

Researcher. Digs through unfamiliar territory — docs, APIs, error logs — and writes notes. Default guardrails: read everywhere, write only to its scratch folder, no shell.

Reviewer. Critiques the work of other agents or of humans. Opens inline comments on the PR simulator, suggests edits, approves or requests changes. Default guardrails: read everywhere, write only to /reviews.

Ops. Infra and deployment. Default guardrails: write on /infra, shell restricted to explicit allow-list, every production command waits for approval.

Support. User-facing helper. Reads your knowledge base, drafts responses, never writes code without a review request. Default guardrails: read on docs and wiki folders, write on /drafts.

Teams vs. roles

Role is what an agent does; team is which agents share context. A team can have two Engineers, one Researcher, and a Reviewer — the roles stay distinct, but they all see each other's memory. You almost always want to combine them.