Choosing the right agent type
Every agent is the same binary. What differs is the kind of jobs you dispatch to it. This page is the decision guide: based on your situation, which job kind should you start with, and how should you mix them as you grow.
Decision matrix
| If your priority is… | Start with | Add next |
|---|---|---|
| Ship features faster | coder | reviewer, then tester |
| Cut PR-review backlog | reviewer | tester |
| Catch regressions before they ship | tester | ui-tester |
| Make your codebase searchable to other agents | indexer | any other persona |
| Plan + decompose work automatically | planner | coder fleet |
| Browser-driven QA (forms, flows, visual) | ui-tester | tester |
Per-persona detail
coder
Reads a work-item, plans the change, writes the diff, runs the test suite, opens a PR. Best for backend feature work where the test suite is the source of truth.
Good first dispatch: a small, well-scoped bug fix with a failing test attached. The agent has the simplest possible feedback signal.
Bad first dispatch: "refactor the auth module." No test signal, no clear stopping condition, no way to evaluate the output. Save this kind of work for after you trust the agent.
reviewer
Reads diffs, requests revisions, approves when standards are met. Catches the common mistakes (missing tests, unhandled errors, accidentally-committed secrets) before a human reviewer spends time on them.
Good first dispatch: point it at an open PR with at least one objective standard you care about (e.g. "all new functions need a docstring"). See if it catches the violation.
tester
Writes test cases for new code, runs the suite, isolates regressions, files reproduction bugs.
Good first dispatch: a freshly-written function with no tests yet. Ask the tester to add test coverage. Evaluate by inspecting the produced tests.
planner
Decomposes feature requests into work items with dependencies. Maintains the sprint board. Often paired with a coder fleet — planner produces the work, coders pick it up.
Don't start here. Planner output is hardest to evaluate without a coder fleet that's already trusted. Earn that trust with coder first, then add planner.
ui-tester
Drives a real browser via Playwright. Verifies visual + interaction behavior, screenshots regressions, runs against the URL you ship to it.
Good first dispatch: a known-broken flow on a staging URL. See if the agent reproduces the issue + writes a regression test.
indexer
Maintains an embedding index of your repos so other agents find context fast. Tree-sitter chunking, incremental updates, no full re-index on every commit.
You probably want this running before anything else. Other agents produce better output when they have context. The indexer is a force multiplier; run it on day one and forget it.
Mixing personas — patterns that work
Pattern 1: indexer + coder (smallest useful fleet)
One indexer running over your main repo, one coder picking up bug-fix work items. Gets you a real productivity win on day one without much operator overhead.
Pattern 2: planner → coder → reviewer → tester (full pipeline)
A request lands, planner decomposes, coders implement, reviewer gates, tester verifies. Each persona handles its own queue; humans only get involved when an agent escalates.
This is the destination, not the starting line. Get to it by adding personas one at a time and waiting until each one is trusted before adding the next.
Anti-patterns
- Running everything at once on day one. You won't know which persona is producing bad output. Start with one. Trust it. Add the next.
- Treating planner as a creative co-founder. Planner decomposes; it doesn't invent. Feed it scoped feature requests, not "build me a startup."
- No indexer. Every other persona produces worse output without one. Add it before you wonder why coder keeps missing context.
Next: Scaling to a fleet.