Mapping Team Roles to Agent Roles: Planner, Reviewer, Tester

When you split a development workflow across multiple agents, mirror the human roles of planner, reviewer, and tester by giving each agent a single responsibility, clear inputs/outputs, and strict handoff rules. Below is a practical blueprint you can drop into a multi-agent workflow.

Role definitions & responsibilities

Planner agent: accepts a high-level request and produces a scoped implementation plan and checklist.

Responsibilities:

• Interpret requirements and constraints.
• Break work into independent tasks with clear interfaces (API shapes, file paths, acceptance criteria).
• Emit a prioritized task list and artifacts needed by implementers (spec fragments, mock data, wireframes).

Reviewer agent: inspects code or design artifacts and returns an actionable review.

Responsibilities:

• Validate correctness, style, security, and conformance to the planner’s acceptance criteria.
• Produce line-level comments, suggested fixes, and a pass/fail verdict per criterion.
• Classify issues by severity and produce minimal repro steps for any failing tests.

Tester agent: creates and runs tests (unit, integration, end-to-end) and summarizes results.

Responsibilities:

• Generate test cases from acceptance criteria and edge cases derived from the planner’s task description.
• Run or simulate tests (or produce runnable test code) and report status with logs and failing inputs.
• Recommend next actions: fix, retest, or escalate to human.

State, interfaces, and handoffs

Keep a tiny shared state object (workflow-state) with these keys: task_id, spec, artifacts, implementation, tests, review, status. Every handoff updates state and includes a one-line summary.

Handoff rules:

• Planner -> Implementer(s): attach task spec, acceptance criteria, and mock data; set status: ready-for-implementation.
• Implementer -> Reviewer: submit code + short changelog; set status: ready-for-review.
• Reviewer -> Tester or Implementer: on pass, set status: ready-for-testing; on fail, attach issues and set status: changes-requested.
• Tester -> Planner/Reviewer: attach test results and set status: tested (pass/fail).

Decision & retry logic

Use deterministic exit conditions:

• If reviewer severity = critical -> route back to implementer.
• If tests fail -> create a bug task linked to original task and return to implementer.
• Limit automated cycles (e.g., 3 auto-fix attempts) before escalating to a human.

Example concise prompts

Planner prompt (system): “You are the Planner agent. Given the user’s feature request and repository snapshot, produce a scoped implementation plan: tasks (title, files to change), acceptance criteria (pass/fail), mock inputs/outputs, estimated complexity (low/med/high), and a short config of tests needed. Output JSON with keys: tasks, acceptance_criteria, artifacts.”

Reviewer prompt (system): “You are the Reviewer agent. Given code diffs and the planner’s acceptance criteria, produce a JSON review: overall_verdict (pass/fail), issues (severity, location, suggestion), and a one-paragraph rationale. If pass, mark next_step: test; if fail, mark next_step: implementer.”

Tester prompt (system): “You are the Tester agent. Given tests to run and implementation artifacts, produce test code (or commands) and a JSON results object: tests_run, passed, failed (with logs and minimal repro input), and recommendation (fix/retest/escalate).”

Practical template: minimal JSON exchange

Planner -> {“tasks”: [{“id”:”T1″,”files”:[…],”acceptance”:”…”}], “artifacts”: {…}}

Implementer -> {“implementation”:”PR link or patch”,”notes”:”…”}

Reviewer -> {“overall_verdict”:”fail”,”issues”:[{…}],”next_step”:”implementer”}

Tester -> {“tests_run”:10,”passed”:8,”failed”:[…],”recommendation”:”fix”}

Quick deployment checklist

• Define the shared state schema and storage (file, DB, or vector store for context).
• Create the three system prompt templates above and pin strict output formats (JSON keys).
• Implement simple orchestration that enforces handoff rules and retry limits.
• Start with one implementer agent and iterate: add more implementers or specializations (security tester, performance tester) as needed.

Following this blueprint helps teams mirror familiar human workflows while preserving clear accountability, reproducible checks, and predictable handoffs between agents.

Sources

• Developer's guide to multi-agent patterns in ADK (Google Developers Blog; 2025-12-16; Official source)