Four agents. One pipeline that doesn't improvise.
This page describes the agentic layer, which is not built yet. It is the design we are working to, and the reasoning behind it — useful if you are deciding whether to bet on the direction. The test-management platform underneath it is working today.
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 resumes rather than restarts.
Author
Inspects the app or API surface to decide what is worth testing, writes the cases, and derives the data each one needs to run realistically. Steps 01 to 03 are all the same agent.
Executor
Runs the cases against real browsers and APIs, evaluates each oracle, and captures the evidence — traces, HAR, console logs, screenshots, video.
Healer & Reporter
The Healer re-authors broken locators and queues them for your review. The Reporter separates flaky from broken and computes the delta against the previous run of the same cell.
Healing is re-authoring, not retry
A retry runs the same broken locator again and hopes the timing was unlucky. That is why retries hide real regressions: eventually one passes.
The Healer does something different. It rebuilds the locator from what is actually on the page, re-checks that the case still tests its original intent, and patches it with a confidence score — flagged for a human to confirm. It is the Author engine doing authoring again, not the same failing step repeated.
- Re-authors from observed state, not a selector guess
- Re-validates the original oracle before patching
- Low-confidence heals never land silently
- Every heal recorded: before, after, confidence, approver
The Orchestrator is deterministic — not an LLM
The agents are non-deterministic by nature. The thing that runs them is deliberately not.
The Orchestrator is a plain workflow engine. It fixes the order, applies retry, timeout and budget policy, and checkpoints state. No model call decides control flow — which is the whole reason the same inputs drive the same pipeline, and why an agentic run can be something you gate a build on rather than a coin flip.
- Fixed, auditable agent order
- Retries, timeouts and per-run budgets
- State checkpointed, so a run resumes not restarts
- Model routing enforced per tenant
The ones worth asking early
How much of this actually exists?
None of the agentic pipeline on this page. What exists and works today is the test-management platform beneath it: the repository, the suite × config × target matrix, runs, defects and reports. We are building the agents on top of that foundation, in the order shown above.
Is it just auto-retry with extra steps?
No. A retry re-runs the same broken locator. Healing re-authors it from the page's observed state, re-validates that the case still checks its original intent, and patches it with a confidence score. It is 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 rather than silently overwriting your case, and each one is recorded with the locator before and after and who approved it. You judge whether healing is trustworthy from its own track record.
How good is the healing?
We do not know yet, and we are not going to invent a number. Heal quality will be reported as precision, recall, flake rate and false-heal rate, measured against a real baseline once healing exists. Any vendor quoting you a healing accuracy figure today is quoting you a guess.
Which models and engines will it use?
The design is model-agnostic and cross-engine, with agents calling a model abstraction rather than a vendor SDK, and a driver layer between the cases and whatever executes them. Which specific engines and models ship first is not settled — and nothing is wired up yet.
The pipeline is ahead. The platform under it isn't.
Bring a real suite and we will show you what works today, and where this pipeline plugs into it.