The Tri-Agent Testing Pipeline: Planner, Generator, Healer (2026)

The tri-agent testing pipeline splits AI test automation into three specialized agents: a Planner that explores your app and writes a Markdown test plan, a Generator that turns that plan into Playwright spec files, and a Healer that fixes broken locators when tests fail. Each agent does one job, hands off one clean artifact, and passes through a human-review gate. This is not a research idea; Playwright ships official agentic Test Agents in exactly these three roles. This post shows the data flow, the handoffs, and where humans stay in the loop.

If you have not set up the underlying browser tooling yet, read the pillar on building a self-operating QA agent with Playwright MCP first, then come back for the architecture.

Why three agents instead of one?

The instinct is to build one big agent that does everything: explore, write tests, and fix failures in a single conversation. It works in a demo and falls apart in practice. A single mega-agent holds too much in one context, drifts as the task grows, and is nearly impossible to audit. When something goes wrong, you cannot tell whether the plan was bad, the code was wrong, or the fix masked a bug.

The tri-agent testing pipeline solves this with separation of concerns, the same principle you already apply to code. Three focused agents each have:

• One clear job. Plan, generate, or heal. Nothing else.
• One input and one output. A clean contract makes each agent testable on its own.
• A natural review gate. The handoff artifact between agents is exactly where a human can inspect and approve.

There are practical payoffs beyond tidiness. You can run each role with a different model or setting, for example a strong reasoning model for planning and a cheaper model for mechanical generation. You can swap one agent without touching the others. And when a test goes wrong, you know which stage to look at. This mirrors how a good human team already works: someone scopes the testing, someone writes the specs, and someone maintains them.

What does the Planner agent do?

The Planner agent is the explorer. You point it at an app, a feature, or a set of user stories, and it drives a live browser through Playwright MCP to discover the routes, states, and interactions that matter. Its output is not code. It is a human-readable Markdown test plan.

That choice of output is deliberate. A Markdown plan is:

• Reviewable by anyone, including product and QA leads who do not read TypeScript.
• Cheap to correct. Fixing a plan is a few edits; fixing generated code is a rework cycle.
• A stable contract the Generator can consume without re-exploring.

A Planner’s output might look like this:

# Test Plan: Checkout Flow

## Scope
Signed-in user completes a purchase with a saved card.

## Scenarios
1. Add a single item to the cart and verify the cart badge shows 1.
2. Proceed to checkout and confirm the saved card is preselected.
3. Place the order and verify an order-confirmation page with an order number.

## Edge cases
- Empty cart: checkout button is disabled.
- Expired saved card: user is prompted to add a new card.

## Notes
- Cart badge exposes role "status" with accessible name "Cart items".
- Confirmation number is in a heading, role "heading" level 1.

Because the Planner explored the real page, it can record the semantic details, roles and accessible names, that make the next stage produce resilient locators. That is a direct benefit of reasoning over the accessibility tree, which we cover in accessibility-tree locators for resilient Playwright AI tests. If your inputs are user stories rather than a live app, the same planning step is described in turning user stories into Playwright TypeScript specs with AI.

Human-review gate 1: approve the plan

This is the most valuable gate in the whole pipeline, and it is the cheapest. A person reads the Markdown plan and confirms it tests the right things, at the right priority, with the right edge cases. Catching a scope mistake here costs a comment. Catching it after generation costs a rewrite. Never let the Generator run on an unreviewed plan.

What does the Generator agent do?

The Generator agent takes the approved Markdown plan and produces Playwright spec files. Its job is mechanical and well-scoped: translate each scenario into a test, using the roles and accessible names the plan recorded, following your framework conventions for fixtures, page objects, and naming.

Given the plan above, the Generator would emit something like this:

import { test, expect } from '@playwright/test';

test.describe('Checkout flow', () => {
  test('signed-in user completes a purchase with a saved card', async ({ page }) => {
    await page.goto('/products');
    await page.getByRole('link', { name: 'Aurora Desk Lamp' }).click();
    await page.getByRole('button', { name: 'Add to cart' }).click();

    await expect(page.getByRole('status', { name: 'Cart items' })).toHaveText('1');

    await page.getByRole('link', { name: 'Checkout' }).click();
    await expect(page.getByRole('radio', { name: /Visa ending 4242/ })).toBeChecked();

    await page.getByRole('button', { name: 'Place order' }).click();
    await expect(page.getByRole('heading', { level: 1 })).toContainText('Order confirmed');
  });

  test('checkout button is disabled with an empty cart', async ({ page }) => {
    await page.goto('/checkout');
    await expect(page.getByRole('button', { name: 'Place order' })).toBeDisabled();
  });
});

Notice the specs use getByRole with accessible names throughout, not brittle CSS or XPath. Because the Generator inherits semantic locators from the plan, the tests are resilient by default. The Generator should also match your existing framework so the output drops straight into the repo, which is exactly the discipline covered in building a test automation framework with AI.

The key contract: the Generator does not explore and does not invent scenarios. It faithfully implements the approved plan. If it finds the plan ambiguous, it should flag the gap rather than guess, and that flag routes back to the Planner or a human.

Human-review gate 2: review the specs

Treat generated specs like a junior engineer’s pull request. A person reviews them for correctness, checks that assertions test the right thing, and confirms nothing was fabricated. AI generation is fast at first drafts and perfectly capable of writing a plausible test that asserts the wrong condition. Review before the specs land in the suite. Once approved, these committed specs run deterministically in CI, ideally via a stateless runner as explained in Playwright MCP vs Playwright CLI for AI agents.

What does the Healer agent do?

Tests break. A locator changes, a flow adds a step, an element moves. The Healer agent is the maintenance role: when a spec fails in CI, it inspects the failure and the current page, and proposes a repair, usually a corrected locator or a fixed wait.

The Healer works from real failure evidence. Playwright’s Trace Viewer and the trace.zip artifact give it the exact DOM snapshot, the failing step, and the network activity at the moment of failure. That grounding is what lets the Healer reason about what actually changed instead of guessing. The mechanics of building this into your fixtures are covered in dynamic self-healing locators with Playwright fixtures.

Here is the critical safety rule: a Healer must distinguish a moved element from a broken feature. If the Add to cart button was renamed to Add to bag, that is a locator fix. If the button vanished because the feature broke, that is a real bug, and healing it would hide a regression. A safe Healer:

• Only repairs locators and waits when the intended behavior clearly still exists.
• Never rewrites assertions to force a pass.
• Attaches its reasoning and the trace so a human can judge the fix.
• Routes suspected real bugs to a person instead of silently healing.

This is where an AI root-cause analysis pass on CI failures pairs naturally with the Healer: classify the failure first (real bug, moved element, or flake), then heal only the safe class. Flakes, in particular, should go to a burn-in and race-condition workflow rather than being papered over with a heal.

Human-review gate 3: approve the heal

Every heal is a code change, so it goes through review like any other. A person confirms the fix reflects an intended UI change, not a masked bug. This gate is what keeps self-healing from quietly eroding your suite’s ability to catch regressions, the single biggest risk of automated healing.

How the data flows end to end

Put together, the pipeline is a clean chain of artifacts with a gate at each handoff.

The flow is a loop, not a straight line. Healed specs feed back into the committed suite. New features send you back to the Planner. Real bugs the Healer surfaces go to engineering. The artifacts, Markdown plan, spec files, and trace, are the seams that make each stage independently reviewable and the whole system auditable.

How do Playwright’s official Test Agents fit?

You do not have to build this from scratch. Playwright ships official agentic Test Agents in Planner, Generator, and Healer roles, designed to plug into MCP-capable clients like Claude Code, Cursor, or VS Code. They map onto the architecture above: the Planner explores and writes a plan, the Generator produces spec files, and the Healer repairs failing tests using traces.

Adopting the official agents gives you a maintained implementation and sensible defaults. Building your own gives you control over models, prompts, and gates. Most teams start with the official Test Agents to learn the workflow, then customize the prompts and review gates to fit their framework and risk tolerance. Either way, the separation of concerns is the same, and it is the part that makes the system trustworthy. Check the current Playwright documentation for exact setup and naming before you wire them in [verify], since the agent tooling is evolving quickly.

Putting it into practice

Start small and prove the loop on one feature. Let the Planner explore a single flow, approve its Markdown plan, let the Generator write the specs, review them, and commit. Then break a locator on purpose and watch the Healer propose a fix you approve. Once that cycle feels safe, widen it.

Keep the gates. The temptation with a smooth pipeline is to remove the human checks for speed, and that is exactly when a fabricated assertion or a masking heal slips through. The tri-agent testing pipeline is fast because each agent is focused, not because it is unsupervised. Judgment stays with people; the typing moves to the agents.

To go deeper on the pieces, the pillar on building a self-operating QA agent with Playwright MCP covers the browser layer, Playwright MCP vs Playwright CLI for AI agents covers how to run each stage, and the AI-augmented test automation guide places the whole pipeline on the broader maturity ladder.