Agent roles

Coroid does not use one general-purpose agent. Each stage of the path from description to pull request is handled by an agent with a narrow job and a deliberately restricted set of tools.

The restrictions are the point. An agent that cannot write code cannot accidentally write code.

The roles#

Role	Stage	Can modify your code
Architect	Specification and plan	No
Developer	Build	Yes
QA	Verify	No
Reviewer	Review	No
Web tester	Verify, browser flows	No
Explorer	Research, any stage	No
Dependency analyzer	Analysis	No

The first four are the pipeline you see on every task, in this order:

Architect → Developer → QA → Reviewer

Exactly one role — the developer — can change files in your repository. Every other agent reads, runs, reports, or creates follow-up work.

Architect#

Turns your description into a specification, and the specification into a plan. It reads the codebase to ground the plan in what is actually there, but it writes no code.

Its output is the thing you approve before the build starts.

Developer#

Does the work: reads the relevant code, makes the change, writes or updates tests, and runs them locally in the workspace until they pass.

When the Reviewer sends findings back, the Developer is the role that acts on them.

QA#

Runs verification independently of the agent that wrote the code — your test suite, the quality gates configured for the project, and the acceptance criteria from the specification.

QA reports a verdict. It does not fix what it finds; failures go back to the Developer as rework.

Reviewer#

Reads the finished diff and produces findings, applying any review rules your organization has configured. Findings are either routed back to the developer as rework or attached to the pull request for you.

Web tester#

Drives a real browser against a running preview of your application to check user flows end to end. It is used where an assertion about behaviour cannot be made from the code alone.

Explorer#

A read-only research role. Other agents use it to answer questions about a codebase without loading everything into their own context — "where is authentication handled", "what calls this function".

Dependency analyzer#

Examines dependencies and how changes ripple across a codebase, including across projects where cross-project dependencies are configured.

Why the separation matters#

Three properties follow from splitting the work this way:

1. Verification is independent. The agent that checks the work is not the agent that wrote it, so it has no stake in the result.
2. Blast radius is bounded. Only the developer role holds code-writing tools, so a failure in review or analysis cannot corrupt your repository.
3. Each role runs a model suited to it. Planning rewards breadth of world knowledge; writing code that compiles rewards something else again. An AI profile carries one model per role for exactly this reason.

Next#

Return to How a task becomes a pull request for the stages these roles map onto, or What is Coroid for the shorter overview.