Agentic QA is a testing pattern where an agent runs an explicit loop: observe the product, reason about risk, act through tools, reflect on expected versus actual behavior, and adapt the next test. It differs structurally from scripted automation because the test is not only a fixed sequence of steps. The loop keeps planning, execution, evaluation, and adaptation connected.
Autonoma enables that agentic loop for a 3-engineer team that says "we don't have any QA" and cannot justify a dedicated QA hire yet. The product is open source in positioning and codebase-first in workflow, but the reason it matters here is operational: engineers get reviewable tests from a running loop, not another checklist they have to maintain.
If you want the adjacent category overview, start with what an AI QA agent actually does. If you are comparing browser-level AI execution patterns, the AI E2E testing guide covers that adjacent layer. This article is narrower. It defines agentic QA as loop mechanics, then maps those mechanics to the primitives engineers can inspect: DOM snapshots, LLM plans, browser tool calls, expected-actual diffs, and re-plans.
What agentic QA means
Agentic QA is not "AI wrote a Playwright file once." It is not a locator fallback that finds a renamed button. It is not an ML assertion that says a screen probably looks normal. Those can be useful features, but they are not the category definition.
The category definition is the loop. An agent observes the app state, reasons about the next useful check, acts through a browser or test runner, reflects on the result, and adapts the plan. In QA terms, the loop turns testing from a script artifact into an execution pattern. The useful output is still concrete: a plan, generated code or runnable steps, a replay log, and a review verdict.
That distinction matters for no-QA teams because the bottleneck is not only test authoring. It is test selection, state setup, execution, failure triage, and maintenance. A team that says "we don't have any QA" does not need a prettier recorder. It needs a loop that can decide what to test, run it, and hand back evidence an engineer can review.
The phrase agentic testing often gets used broadly. Agentic QA is the engineering operating model around it: what the loop observes, what it is allowed to do, how it evaluates output, and where a human still has to approve the result because the agent can be confidently wrong.
There is also a timing difference. In scripted automation, the author makes almost every important decision before execution: which selector to use, which path to follow, which assertion proves success, and what to do when the page does not match the script. In agentic QA, some of those decisions happen during execution. That does not remove engineering judgment. It moves judgment into the design of the loop and the review of its artifacts.
The agentic loop engineers can inspect
The diagram is the important part. Observe means the agent takes a structured reading of the current app state, not only a screenshot. Reason means it converts the goal into a testable path. Act means it uses a browser, a test runner, or a repo tool. Reflect means it compares expected behavior with actual behavior. Adapt means it changes the next step or test plan instead of repeating the same broken script.
That is why agentic QA is structurally different from scripted automation. In scripted automation, adaptation usually happens outside the test, when a human edits it. In agentic QA, adaptation is part of the runtime loop and still has to be reviewed.
The engineering primitive matters because it keeps the concept falsifiable. If a vendor says "agentic" but cannot show the observed state, the plan, the action taken, the expected-actual diff, or the re-plan, the claim is hard to inspect. You are left with a marketing word. A useful agentic QA system should leave behind enough evidence for an engineer to answer: what did it see, why did it choose this path, what did it do, what changed, and why should I trust the next step?
| Approach | Core unit | Adaptation | Best fit |
|---|---|---|---|
| Agentic QA | Loop plus artifacts | Plan changes after evidence | No-QA teams |
| Traditional AI testing | AI feature on a test | Locator or assertion help | Maintained suites |
| Scripted automation | Fixed test script | Human edits code | Stable flows |
What an OSS agentic QA stack looks like
A plausible OSS agentic QA stack is possible, but it is not one package. You would combine Playwright for browser control, a test runner for repeatability, an LLM provider or self-hosted model for reasoning, a DOM extraction layer, a state setup mechanism, a trace store, and a reviewer step that classifies failures. You would also need orchestration glue that decides when to re-plan and when to stop.
That stack can be honest and useful. It can cover a signup or checkout flow. It can generate a plan from a route map. It can run a browser and save logs. It can even be a no brainer for teams that want complete control and have the time to maintain the orchestration.
Where it differs from Autonoma is runtime ownership. Autonoma is not just a loose collection of libraries. It is the orchestration layer that keeps the loop running end to end, from planning through review, with product boundaries around what the agent is allowed to claim. Autonoma is also not an API testing tool, unit test runner, native iOS or Android E2E tool, scraping library, test management platform, request builder, click-and-record tool, plain-language test builder, or Sentry replacement.
The honest OSS path has a maintenance bill. Someone has to tune prompts, store traces, define stop conditions, seed accounts, rotate model credentials, classify false positives, and keep the browser runner current. Those are all solvable engineering problems. They are not free. If your team wants to own that stack, start small: one critical web flow, one state fixture, one trace format, one reviewer rubric. Do not call it an agentic QA platform until the loop can adapt and explain itself across repeated runs.
How Autonoma operates as an agentic QA platform
Autonoma maps the agentic loop to four reviewable stages: Planner, Generation, Replay, and Reviewer. Planner is observe plus reason. It reads the codebase, routes, components, and user-flow structure, then produces a test plan. Generation is act. It turns the plan into runnable browser coverage instead of asking an engineer to write every step.
Replay is reflect. It reruns the generated flow against the target app and records what happened, including the expected-actual diff. Reviewer is adapt with a safety check. It classifies the result, filters noise, and decides whether the next useful output is a confirmed bug, a repaired test path, or a rejected finding. The mapping is explicit: observe maps to Planner's code and app-state read, reason maps to Planner's test plan, act maps to Generation, reflect maps to Replay, and adapt maps to Reviewer.
This is why "tests write themselves" should not mean "trust the agent blindly." Review is part of safety. The agent can be confidently wrong about intent, state, or consequence. A good agentic QA platform makes the artifacts visible enough for an engineer to inspect: plan, generated steps, replay evidence, and reviewer verdict.
For a three-engineer team, the organizational change is concrete. The PR author no longer has to remember every flow to click. The founder no longer becomes the informal QA gate. The team can catch bugs before they reach production without hiring a QA function just to keep a brittle suite alive.
That is also where Autonoma differs from a one-off coding-agent prompt. A prompt can produce a useful test file, but the team still owns the loop around it. Autonoma's job is to keep Planner, Generation, Replay, and Reviewer connected so the output is not just a script. It is a pipeline-backed QA artifact. The broader autonomous testing platform architecture explains that runtime layer in more detail.
What changes for the engineering team
When tests write themselves, ownership moves earlier. QA is no longer a late manual phase. It becomes a PR-level loop that runs while the engineer still understands the change. That is especially valuable in a startup where "we hear about it real quick" usually means a customer, founder, or support channel found the regression first.
The team still needs judgment. Agentic QA does not replace product review, unit tests, incident response, or runtime monitoring. It replaces the repetitive gap where someone must translate obvious product flows into browser coverage and keep that coverage alive as the app changes.
The failure mode is over-trust. If the agent marks a flow as covered but seeded the wrong account state, the green check is misleading. If it finds a path that technically completes but violates product intent, the test is not good enough. The safety pattern is to review the artifact, not only the status. A reviewed loop is useful. An opaque loop is another dashboard.
The best organizational pattern is small and explicit. Pick the flows the business cannot afford to break: signup, login, invite, checkout, upgrade, file upload, export, and permissions. Let the agentic loop generate coverage there first. Review the artifacts in PRs until the team understands what good evidence looks like. Then expand coverage only where the loop keeps producing useful signal. The goal is not maximum test volume. It is fewer late surprises for the smallest possible team.
A worked example: one signup agent run
Take a tiny B2B app with a signup flow: email, password, workspace name, invite teammate, and dashboard landing. The goal is simple: prove a new user can create a workspace and invite a teammate.
Artifact one is the plan. Planner identifies the route /signup, the required fields, the workspace creation side effect, the invite form, and the success condition: the dashboard shows the workspace and pending invite. It also names setup: use a fresh email and no existing workspace.
Artifact two is generated code or runnable steps. Generation creates the browser path: open signup, fill email, fill password, submit, enter workspace name, invite teammate, and assert the dashboard state. The important part is not that the code exists. It is that the generated steps are derived from the app structure and can be replayed.
Artifact three is the replay log. Replay records: signup page loaded, account created, workspace created, invite submitted, dashboard loaded, expected invite badge missing. That last line is the expected-actual diff. The flow did not fully satisfy the goal.
Artifact four is the review verdict. Reviewer marks the run as a product bug if the invite request succeeded but the dashboard omitted the pending invite. It marks it as a test issue if the selector changed but the invite is visible under another stable label. It marks it as environment noise if email delivery was the only missing dependency and the product state was correct.
That is agentic QA in practice, and the four stages in that run are not a metaphor. Planner, Generation, Replay, and Reviewer are exactly how Autonoma operates. The value is not magic test generation. It is a closed loop that turns one signup flow into reviewable evidence fast enough for a no-QA team to act before users do, while the engineer keeps a narrow decision: fix the product if the dashboard should show the invite, update the expected outcome if the panel intentionally moved, or mark environment noise if only email delivery failed.
For a three-engineer team, the hard part was never writing one test. It is keeping that loop connected without hiring someone to babysit a brittle suite. Autonoma does the repetitive work of translating product flows into browser coverage and keeping it alive as the app changes, then hands back evidence an engineer can approve inside a PR instead of a green check nobody can trace. The agent absorbs the maintenance. The judgment that decides what a failure means stays with the team.
That is what changes when tests write themselves on a team that cannot afford to hear about a regression from a customer first. The work of testing moves off the engineer's plate, but the trust still has to be earned run by run, and the loop is what earns it.
FAQ
Agentic QA is a testing pattern where an agent observes the product, reasons about risk, acts through tools, reflects on expected versus actual behavior, and adapts the next test. The output should be reviewable artifacts, not only a green or red status.
No. AI testing can mean many things, including locator fallback, ML assertions, or AI-assisted script writing. Agentic QA is narrower: it requires a loop that connects planning, execution, evaluation, and adaptation.
The agentic loop is observe, reason, act, reflect, adapt. In QA, that maps to a DOM or app-state snapshot, an LLM plan, a browser or test-runner tool call, an expected-actual diff, and a re-plan.
Yes, if you assemble the browser runner, model layer, DOM extraction, state setup, trace storage, and review orchestration yourself. The hard part is not one library. It is keeping the loop reliable and reviewable.
Agentic QA can replace repetitive manual flow checks and some brittle hand-authored E2E test authoring. It does not replace unit tests, API tests, product review, runtime monitoring, incident response, or human review of ambiguous findings.
