AI Agent Roles Glossary: Coder, Reviewer, Planner, and the Rest of the Roster

Three weeks ago I watched someone assign a Planner agent to a bug fix ticket. It spent 40 minutes writing a detailed architectural analysis of the bug — root cause hypothesis, three remediation approaches, estimated story points for each. Zero lines of code. The engineer was furious. But honestly? The agent did exactly what Planner agents do. The bug should have gone to a Developer agent.

I've made this mistake myself. More than once, if I'm being honest.

That's the thing about AI agent roles. They're not interchangeable. A Planner agent and a Developer agent are as different as a PM and a senior engineer. Same underlying model, maybe. Completely different job. And mixing them up doesn't just waste time — it makes you look like you don't understand the tools you're using. (We've seen this pattern across our VDL product portfolio — role clarity matters everywhere, from click fraud detection agents to deployment automation.)

We already wrote a general AI agent glossary covering 40 terms — agentic, orchestration, tool use, all that vocabulary. This is different. This glossary focuses on the roster: the distinct roles agents play on a team. Planner. Developer. QA. DevOps. Reviewer. What each one does, when to use it, and how they fit together inside a sprint.

If you're building with agents — or evaluating platforms like DevOS that staff sprints with agent employees — knowing the roster matters more than knowing the terminology.

The Core Roster

1. Planner Agent

What it does: Architecture, task decomposition, sprint scoping. The Planner agent reads a feature request, epic, or vague Slack message and turns it into structured work. Breaks features into tickets. Defines acceptance criteria. Sequences tasks so dependencies get handled first — the kind of grunt work that makes PMs valuable but that nobody wants to do manually at 9am on a Monday.

What it doesn't do: Write code. A Planner agent should never produce implementation code. If it's writing code, it's misconfigured or you've got the wrong agent type.

When to use it: Early in a sprint cycle, when you're turning product requirements into engineering tickets. When you need to estimate complexity before committing. When a feature is big enough that "just start coding" will create rework.

Example workflow: A Planner agent receives "add Stripe billing to the app." It outputs: five tickets (integrate Stripe SDK, create subscription model, build checkout UI, add webhook handlers, write billing tests), acceptance criteria for each, suggested order of implementation, and estimated story points based on codebase complexity.

DevOS's built-in Planner agent handles PRD-style scoping and sprint planning. It doesn't touch your repo's code — just your backlog.

2. Developer Agent

What it does: Writes implementation code. The Developer agent takes a ticket with clear requirements and produces a working feature branch. It reads the codebase, writes the code, runs local tests, handles linting, and opens a PR.

What it doesn't do: Decide what to build (that's Planner), validate the implementation works correctly (that's QA), or deploy it (that's DevOps). A Developer agent implements — one ticket at a time.

When to use it: When you have a well-scoped ticket with clear acceptance criteria and you need working code. Bug fixes. Feature implementations. Refactors with a defined scope.

Example workflow: Developer agent receives "add retry logic to the payment service with exponential backoff." It reads the payment service code, identifies where retries belong, writes the implementation, adds unit tests for the retry behavior, and opens a PR against main.

The Developer agent is what most people think of when they say "AI coding agent." Cursor, GitHub Copilot, Devin — these are all Developer-role tools (though some blur boundaries). The difference is whether the agent owns the full ticket lifecycle or just assists while you drive.

Look, I'll be honest: most single-agent tools plateau at prototypes. They're great for "build me a todo app" demos. They struggle when your codebase has 50,000 lines, eight services, and authentication flows that evolved organically over three years. That's not a knock on the tools — it's a scope mismatch. We explored this in depth in our why single-agent coding tools plateau analysis.

3. QA Agent

What it does: Writes tests, reviews code for defects, catches regressions, validates edge cases. The QA agent receives completed work and pressure-tests it. It writes test cases the Developer agent missed. It flags code that will break under load. It checks that acceptance criteria are actually met — not just technically passing.

What it doesn't do: Write the implementation. Fix the bugs it finds (that goes back to Developer). Deploy anything.

When to use it: After Developer work is done, before merge. When test coverage is below threshold. When a ticket touches critical paths. When you've been burned by regressions before.

Example workflow: QA agent receives a PR from the Developer agent adding retry logic. It reviews the code for edge cases (what happens at max retries? what if the error type changes mid-retry?). It writes parametrized tests covering those cases. It flags that the timeout constant should be configurable. It approves the PR — or sends it back with specific requested changes.

QA agents work best with clear acceptance criteria. Vague specs produce vague tests. Garbage in, garbage out. We've written more about AI agents for QA teams if you're building out this role.

4. DevOps Agent

What it does: Infrastructure, deployment, operations. The DevOps agent provisions databases, configures CI/CD pipelines, manages environment variables, handles deploys, monitors deployment health, and runs rollbacks.

What it doesn't do: Write application code. Design infrastructure (that's more Planner territory). Fix application bugs that cause deployment failures.

When to use it: When you need infrastructure provisioned. When a feature is ready to deploy. When environments need updating. When the pipeline breaks and someone needs to debug it.

Example workflow: DevOps agent receives "deploy v1.3.2 to production." It verifies tests passed in CI. It checks the Railway deployment config. It triggers the production deploy. It monitors health checks for 5 minutes. It reports deployment success — or rolls back and escalates if health checks fail. For a deep dive on infrastructure choices, see our Railway vs Vercel vs Fly.io comparison.

DevOS's built-in DevOps agent handles Railway deployments, Postgres/Redis provisioning, environment management, and one-click rollbacks. The agent executes; you approve the production actions.

5. Reviewer Agent

What it does: Code review. The Reviewer agent reads PRs and provides structured feedback on code quality, architecture, security, performance, and maintainability. It catches issues before they hit the main branch.

What it doesn't do: Write the fix. Approve PRs without human oversight (in most safe configurations). Make judgment calls on product trade-offs.

When to use it: Every PR. Seriously. Reviewer agents catch things humans miss — especially when humans are reviewing 10 PRs in a row and getting tired. They're consistent where humans get sloppy.

Example workflow: Reviewer agent receives a PR adding user authentication. It checks for SQL injection vectors. It flags that the session timeout is hardcoded (should be configurable). It notes that the password hashing uses an outdated algorithm. It requests changes with specific line-number comments.

Here's a hot take: Reviewer agents aren't replacing human code review. They're pre-filtering it. The Reviewer agent catches the obvious stuff — style violations, security anti-patterns, missing edge cases — so the human reviewer can focus on architecture and design decisions the agent can't evaluate.

Another hot take? Most teams skip code review entirely under deadline pressure. A Reviewer agent that runs automatically on every PR is infinitely better than a human review process that exists in theory but never happens in practice. I'd rather have imperfect automated review than perfect review that nobody does.

6. Research Agent

What it does: Gathers information before execution. The Research agent reads documentation, explores codebases, synthesizes external sources, and produces context that other agents need to do their jobs well.

What it doesn't do: Execute tasks. Write production code. Make implementation decisions.

When to use it: When an agent needs context it doesn't have. When integrating with an unfamiliar API. When the codebase is large enough that agents can't hold it all in context.

Example workflow: Research agent receives "understand how our auth system works." It reads the auth modules, traces the login flow, documents the token refresh logic, and produces a summary other agents can reference when working on auth-adjacent features.

Research agents are often the first step in a pipeline. The Planner reads Research output to scope accurately. The Developer reads it to implement correctly. Without Research, other agents guess — and guessing causes rework.

(I skipped Research agents on a recent project because "we don't have time." We absolutely had time. We just spent it on three rounds of rewrites because the Developer agent hallucinated an API endpoint that didn't exist. More on hallucination patterns in our AI coding agents hallucinate infrastructure guide.)

Supporting Roles

7. Documentation Agent

Writes docs, READMEs, inline comments, API references. Takes code the Developer agent wrote and produces human-readable explanations. Useful for teams that always say "we'll document this later" and never do.

8. Migration Agent

Handles database migrations, schema changes, data transformations. A specialized form of DevOps agent focused on data layer changes. Particularly useful for Rails/Django teams with complex migration histories.

9. On-Call Agent

Monitors production, triages alerts, runs incident response playbooks. When PagerDuty fires at 3am, the On-Call agent investigates before waking a human. It can restart services, scale resources, and gather diagnostic info. More on this in our incident response with AI agents guide.

10. Dependency Agent

Handles package updates, security patches, version bumps. Takes "update all dependencies to latest secure versions" and produces a series of PRs with tested upgrades. Unglamorous but essential — the stuff that rots if nobody owns it.

This is the kind of work humans procrastinate on for months. "We'll update dependencies after the launch." Sure you will.

How Roles Coordinate

Here's where it gets interesting. Individual roles are useful. A roster working together is powerful.

The typical flow:

1. Planner scopes the work into tickets
2. Developer implements each ticket
3. QA validates the implementation
4. Reviewer reviews the PR
5. DevOps deploys to staging, then production

Each handoff carries context. The Planner's ticket includes acceptance criteria the QA agent will validate against. The Developer's PR includes implementation notes the Reviewer agent reads. The QA agent's test report tells DevOps whether deployment is safe.

Without explicit handoff protocols, context drops. The Developer doesn't know what the Planner considered and rejected. The QA agent doesn't know which edge cases the Developer already handled. Agents redo work or miss obvious issues.

DevOS uses what we call the Super Orchestrator to manage these handoffs. It's the PM for your AI roster — tracking who's working on what, routing completed work to the next role, and ensuring no context gets lost in transitions. We covered orchestration architecture in our agent coordination guide.

Common Mistakes

Mistake 1: Using a generalist agent for specialized work. A single agent CAN attempt all roles. It will do each one poorly. The system prompt that makes a great QA agent makes a mediocre Developer agent. Specialized tools and guardrails make agents safer and more effective.

Mistake 2: Skipping the Planner. Throwing tickets directly at Developer agents without planning creates chaos. You get inconsistent architecture, duplicated work, and dependencies handled out of order. Ten minutes of Planner time saves hours of rework.

Mistake 3: Making QA and Developer the same agent. "Write the code and the tests" sounds efficient. In practice, the same blind spots that produce buggy code produce incomplete tests. Separation of concerns applies to agents too.

Mistake 4: Deploying without DevOps agent guardrails. A Developer agent that can push to production is a Developer agent that will push a broken migration to production at 11pm on Friday. Role separation is also permission separation. For CI/CD integration patterns, see our AI agent CI/CD pipeline guide.

Ask me how I know.

Honorable Mentions

Triage Agent: Receives incoming issues (from users, from monitoring, from support tickets) and routes them to the appropriate role. Useful when your backlog is chaotic.

Compliance Agent: Continuously validates code and infrastructure against compliance requirements. SOC 2 checks, HIPAA audits, security scans. See the compliance sections in our agentic DevOps glossary.

Refactor Agent: Specialized Developer agent focused on cleanup — removing dead code, improving performance, paying down tech debt. Doesn't add features, just improves what exists.

Quick Verdict

If you're adding agent roles to your team, start with Developer and QA. Those two handle the bulk of sprint work: writing code and validating it. Add Planner when your tickets are vague or your architecture decisions are inconsistent. Add DevOps when deployment becomes a bottleneck.

Don't try to build the perfect roster on day one. You'll overthink it.

The roster model — specialized agents coordinated by an orchestrator — beats generalist agents doing everything. It's how DevOS approaches agents-as-employees: not one magical agent, but a team of specialists with clear roles. Pre-launch, waitlist open.

For the full vocabulary beyond roles, see our AI agent glossary for software teams. For DevOps-specific terms, the agentic DevOps glossary goes deep on orchestrators, dry-run gates, and blast radius.

Frequently Asked Questions

What is a Planner agent and when should I use one?

A Planner agent handles architecture, task decomposition, and sprint scoping. It reads feature requests, breaks them into implementation tickets, defines acceptance criteria, and sequences work across other agents. Use a Planner when you need to turn a vague idea into a structured backlog — not when you need code written. Planner agents don't code. They plan.

What's the difference between a Developer agent and a QA agent?

Developer agents write implementation code. QA agents write tests and review code for defects. A Developer takes a ticket and produces a working feature branch. A QA agent takes that branch and produces test coverage, catches edge cases, and flags regressions. They're sequential in most workflows — Developer ships, QA validates. Merging them into one role usually means worse tests.

Can one general-purpose agent handle all roles?

Technically yes, practically no. A single generalist agent can attempt planning, coding, testing, and deployment — but it won't do any of them as well as a specialist. Specialized agents have tighter system prompts, focused tool access, and role-specific guardrails. A QA agent that never touches production databases is safer than a generalist that might.

How do agent roles coordinate during a sprint?

Through an orchestrator. The Planner scopes work and creates tickets. The Developer picks up implementation tickets. The QA agent receives completed work for test coverage. The DevOps agent handles deployment. Handoffs include context — what was built, what decisions were made, what to watch for. Without explicit handoff protocols, agents drop context and redo work.

---

Join the DevOS Waitlist

AI agents that work as employees inside your sprints, standups, and tickets — not single-task copilots. Planner / Developer / QA / DevOps agents pick up work from the backlog, ship in branches, request review. Linear-shaped backlog UI with AI underneath. Pre-launch.

Join the waitlist → · How agents-as-employees works