Multi-Agent Systems for Code Review and Test Generation
A single coding agent can review a diff. Ask that same agent to also write the tests for what it just reviewed, and quality on both jobs tends to quietly drop — reviewing and test-writing are genuinely different tasks with different failure modes, and a generalist agent doing both at once tends to do each one a little worse.
A multi-agent system splits the work instead: a reviewer agent reads the diff and reasons about correctness, and a separate test-writer agent generates coverage for the code paths the diff touches each one specialized, coordinating through Google's Agent2Agent (A2A) protocol rather than one model context-switching between two different jobs.
The coordination is the part worth seeing concretely, not just describing. The rest of this post follows one real pull request through both agents what each one does, and the actual structured message that passes between them rather than staying at the level of "the agents talk to each other."
Evonence has built multi-agent code review pipelines for engineering teams whose test coverage had fallen behind their PR velocity, using the Agent Development Kit for each agent and A2A for the handoff between them.
One PR, Two Agents, Running in Parallel
Here's what actually happens when a pull request lands, broken out by which agent does what.
On this PR: calculateDiscount() updated to support bulk-order tiered pricing
Reviewer Agent
- 1. Reads the diff, grounded in the codebase via Gemini Enterprise Search, and identifies the three call sites affected by the change.
- 2. Checks the new logic against the team's style guide and flags one missing null check on the new tier-boundary parameter.
- 3. Posts review comments directly on the PR, same as a human reviewer would.
Test-Writer Agent
- 1. Receives the affected-function list from the reviewer agent over A2A it doesn't re-analyze the diff from scratch.
- 2. Generates edge-case tests for the new tier boundaries: zero-quantity, exact-boundary, and above-max-tier orders.
- 3. Runs the new tests against the branch via Cloud Build and reports pass/fail back before the PR is marked ready.
The Actual Handoff
This is the structured message the reviewer agent sends the test-writer agent over A2A for the PR above — simplified, but representative of the real exchange:
That failing test is the useful outcome, not a bug in the pipeline — the test-writer agent found a real edge case the null-check gap in the reviewer's flag predicted, and now there's a reproducible failing test attached to the PR before a human ever looks at it.
Who Owns What, Long-Term
Beyond this one example, here's how the division of labor holds up across a typical week of PRs:
| Reviewer Agent | Test-Writer Agent |
|---|---|
| Reads the diff and reasons about correctness | Generates tests for the code paths the diff touches |
| Flags style and convention deviations | Runs generated tests via Cloud Build and reports results |
| Posts review comments on the PR | Reports coverage delta against the pre-change baseline |
| Escalates security-sensitive changes for human review | Flags when it can't generate a meaningful test for a path |
Where This Still Needs a Human
— It doesn't replace judgment on architectural or security-sensitive changes — those still route to a human reviewer regardless of what either agent reports.
— Generated tests cover the paths the agents can reason about from the diff — they don't guarantee every edge case a senior engineer might think to ask about is covered.
— A developer still makes the merge decision. Both agents produce input to that decision; neither one merges anything on its own.
Where Evonence Has Done This Before
Evonence has taken projects like this from pilot to production for clients in several industries — reach out and we can share a reference that matches your situation.
What Engineering Leads Ask Before Rolling This Out
How long does it take to deploy a multi-agent review pipeline?
Do we need an existing coding agent before adding multi-agent test generation?
What's the difference between A2A and MCP in this context?
What happens if the two agents disagree — for example, the reviewer flags something the test-writer's tests don't catch?
Can this scale to more than two agents — say, adding a security-scanning agent?
How is this kept auditable for regulated codebases?
Ready to Close Your Test Coverage Gap?
Schedule a free 30-minute Engineering Workflow Assessment with one of Evonence's Google Cloud-certified architects. We'll scope where multi-agent review adds the most coverage fastest at no cost.
