ProductHow it worksWhy Testaumate PricingAboutBook a demo
How it works

Six agents. One deterministic pipeline.

The intelligence lives in the agents; the control lives in the Orchestrator — a deterministic workflow engine, not an LLM. It sequences the agents, manages retries, timeouts and budgets, and enforces which models run for which tenant, so runs stay repeatable.

The pipeline

From a target to a triaged report, one pass

Each step is owned by a named agent. The Orchestrator runs them in order, retries within budget, and persists state so a run can be resumed rather than restarted.

STEP 01

Plan & explore

The Author agent inspects your app or API surface to decide what to test.

Author agent
STEP 02

Author

Generates cases from a spec, URL, or story — with intent-rich locators, not brittle selectors.

Author agent
STEP 03

Generate test data

Derives the fixtures and data each case needs to run realistically.

Author agent
STEP 04

Execute

Runs cases against real browsers and APIs, evaluates oracles, and captures full evidence.

Executor agent
STEP 05

Heal

On a broken locator, re-authors it from observed state, re-validates intent, and patches — flagged for review.

Healer agent
STEP 06

Report

Triages flaky-vs-real, surfaces root-cause hypotheses, and computes regression deltas.

Reporter agent
The moat

Healing is re-authoring, not retry

A retry runs the same broken locator again and hopes. The Healer does something different: it re-authors the locator from the page's observed state, re-validates that the case still checks the original intent, and patches the case with a confidence score — flagged for a human to confirm.

  • Re-authors from observed DOM/state, not a hard-coded selector guess
  • Re-validates the original oracle — the case still tests what it meant to
  • Patches with a confidence score, never landing a low-confidence heal silently
  • Flagged for review so the QA Lead owns whether a heal is trustworthy
  • Every heal is measured — precision, recall, flake and false-heal rate
The control plane

The Orchestrator is deterministic — not an LLM

The agents are non-deterministic by nature; the thing that runs them is not. The Orchestrator is a deterministic workflow engine. It decides the order, enforces the rules, and persists the state — which is what makes an agentic run something you can gate CI on.

  • Sequences the agents in a fixed, auditable order
  • Manages retries, timeouts and per-run budgets
  • Enforces governance — which models run for which tenant
  • Persists state so a run resumes rather than restarts
  • No model call decides control flow — the pipeline stays repeatable
Questions

How the pipeline actually behaves

Is it just auto-retry with extra steps?
No. A retry re-runs the same broken locator. Healing re-authors the locator from the page's observed state, re-validates that the case still checks its original intent, and patches it with a confidence score. It's the Author engine doing authoring again — not the same failing step repeated.
What if it heals wrong?
Every heal carries a confidence score and is flagged for review — it does not silently overwrite your case. The QA Lead confirms or rejects the patch, and heal quality is measured on precision, recall and false-heal rate, so you can see how trustworthy healing is before you rely on it.
How do you keep runs repeatable?
The Orchestrator is deterministic — no model call decides control flow. It sequences agents in a fixed order, applies fixed retry, timeout and budget policies, and persists state at checkpoints, so the same inputs drive the same pipeline and a run can resume rather than restart.
Which models and engines does it use?
The platform is model-agnostic (Claude, GPT or open-source) and cross-engine (Playwright, Selenium, Appium and a proprietary API engine). The Orchestrator enforces which models are allowed to run for which tenant, so governance is a control-plane rule, not a per-run choice.
Where does the evidence come from?
The Executor runs each case against real browsers and APIs and captures traces, HAR, console logs, screenshots and video. The Reporter then uses that evidence to triage flaky-vs-real, propose a root-cause hypothesis, and compute the regression delta against the prior run.
See the pipeline run

Describe the flaky suite. We'll show the agents fix it.

Bring a real spec or a URL. In a short session we'll author cases, break a locator, and let it heal — live.