Agent roles

The nine AI roles, what each one does, and when it runs.

A run uses nine agent roles. Each role has its own provider, model and output-token budget, which you set on New Run → Configuration → Agent Roles. The collapsed role cards use short names (for example PM and Integration); the full names are below.

The nine roles#

Analyst

Short name: Analyst
Phase: Requirements
Runs: Iteration 1, and again after you add a note
What it does: Analyzes your requirements and produces a structured plan with acceptance criteria. Also the agent you chat with under Discuss.

Test Author

Short name: Test Author
Phase: Requirements
Runs: With the Analyst
What it does: Writes executable JavaScript acceptance tests from the functional acceptance criteria. A deterministic runner executes them against the app.

Project Manager

Short name: PM
Phase: Planning
Runs: Every iteration
What it does: Distributes the work: which files exist, and which developer owns each one.

Developer

Short name: Developer
Phase: Development
Runs: Every iteration, in parallel
What it does: Writes and edits code for its assigned files. Several run at once.

Integration Architect

Short name: Integration
Phase: Integration
Runs: Every iteration
What it does: Checks cross-file consistency (CSS↔HTML, JavaScript↔HTML, imports and exports) and fixes mismatches.

Short name: QA
Phase: QA Review
Runs: Every iteration, in parallel
What it does: Independently reviews all files for bugs and for how well they meet the requirements.

Visual QA

Short name: Visual QA
Phase: QA Review
Runs: Every iteration, only in Visual or Interactive QA mode
What it does: Reviews screenshots and the rendered page of the running app for broken layouts, missing features and accessibility problems.

Feedback Coordinator

Short name: Feedback
Phase: Feedback
Runs: Every iteration
What it does: Aggregates and de-duplicates the QA findings and produces the score.

Summary Generator

Short name: Summary
Phase: Summary
Runs: Once, at the end
What it does: Writes the final markdown README of what was built.

Role	Short name	Phase	Runs	What it does
Analyst	Analyst	Requirements	Iteration 1, and again after you add a note	Analyzes your requirements and produces a structured plan with acceptance criteria. Also the agent you chat with under Discuss.
Test Author	Test Author	Requirements	With the Analyst	Writes executable JavaScript acceptance tests from the functional acceptance criteria. A deterministic runner executes them against the app.
Project Manager	PM	Planning	Every iteration	Distributes the work: which files exist, and which developer owns each one.
Developer	Developer	Development	Every iteration, in parallel	Writes and edits code for its assigned files. Several run at once.
Integration Architect	Integration	Integration	Every iteration	Checks cross-file consistency (CSS↔HTML, JavaScript↔HTML, imports and exports) and fixes mismatches.
QA	QA	QA Review	Every iteration, in parallel	Independently reviews all files for bugs and for how well they meet the requirements.
Visual QA	Visual QA	QA Review	Every iteration, only in Visual or Interactive QA mode	Reviews screenshots and the rendered page of the running app for broken layouts, missing features and accessibility problems.
Feedback Coordinator	Feedback	Feedback	Every iteration	Aggregates and de-duplicates the QA findings and produces the score.
Summary Generator	Summary	Summary	Once, at the end	Writes the final markdown README of what was built.

Developers and QA reviewers are the only roles with more than one agent. You set how many under Dev Mode and Orchestration → QA agents. All the developers share the Developer role's model, and all the reviewers share the QA role's model.

Choosing models for each role#

Every role works with any model in the catalog, but the roles don't need the same things.

Project Manager: must plan the whole build and return it as structured output. It benefits most from a strong model, and a reasoning model here is a common choice.
Developer: does most of the writing and runs several copies in parallel, so its price multiplies. A capable, low-cost coding model is usually the best value.
QA: needs careful reading more than creativity. A model from a different family than your developers tends to catch more.
Visual QA: needs a model that accepts images, because it reads screenshots. It only runs in Visual or Interactive QA mode. In the default Code mode its assignment doesn't matter, and the run won't ask for its provider's key.
Analyst, Feedback Coordinator, Summary Generator: short, structured tasks. Low-cost models do these well.

Output-token budgets#

Each role has a Max output tokens value, which caps how long each response from that role can be.

When you pick a model, the budget is set to that model's maximum output from the catalog. You rarely need to touch it.
Reasoning models count their hidden thinking against the output limit. If you set a reasoning model's budget too low, the app shows a note on the role card and raises it at request time, so the model doesn't spend its whole budget thinking and return nothing.
If you set a budget above what the model allows, the role card is flagged and Start run stays disabled until you lower it.

How roles get their first assignment#

Your first key assigns all nine roles to that provider, using its lowest-cost capable model. After that, only you change the assignment: adding or removing another key never moves a role. See Configure a run.