Research guide

Agentic Testing vs Traditional E2E Testing: Goals vs Scripts

Software testing has always balanced two competing needs: repeatability and realism.

By CueTest QA Team · Published 2026-09-02

Traditional end-to-end automation favors repeatability. A test defines a known journey, performs a known set of interactions, and checks known assertions. When the application behaves differently, the test fails. That predictability is why browser frameworks such as Playwright, Cypress, and Selenium remain essential release infrastructure.

Agentic testing changes the unit of automation.

Instead of giving the system every step, you give it a goal. The agent observes the application, reasons about the current state, chooses an action, evaluates what happened, and continues toward the expected outcome.

A traditional test says:

click Sign in
fill Email
fill Password
click Continue
assert Dashboard is visible

An agentic test says:

Sign in with the test account and verify that the customer dashboard is available.

The difference looks small in a text box. Architecturally, it is enormous.

Slack Engineering summarized the distinction after running more than 200 agentic E2E workflows in 2026: tests enforce journeys; agents verify goals. In its experiments, the overall objective could remain consistent while the exact path varied. An agent might press Enter instead of clicking a suggestion, reopen a search instead of reusing an existing view, or take an extra interaction before reaching the same result.

That flexibility is why agentic testing is interesting. It is also why it should not simply replace every deterministic test you already have.

This guide explains the real differences, the trade-offs, and a practical architecture for using both.

What is traditional E2E testing?

Traditional end-to-end testing automates a predefined user journey across the application and verifies expected behavior at one or more checkpoints.

The test author controls:

• the starting state;
• the sequence of actions;
• the elements being targeted;
• the data used;
• the waiting behavior;
• the assertions;
• the stopping conditions.

A Playwright test is a good modern example. You can locate elements using accessible roles and labels, rely on automatic waiting, and write web-first assertions that retry until a condition is satisfied or times out.

The test remains explicit code.

That is valuable because a deterministic test is not merely trying to complete a task. It is enforcing a contract about how the application should behave.

If the product requirement says clicking “Confirm purchase” must transition directly to an order receipt, a deterministic test can fail if an unexpected interstitial appears. An adaptive agent might simply dismiss the interstitial and continue, which could hide the very regression you wanted to detect.

What is agentic testing?

Agentic testing uses an AI agent to make runtime decisions while attempting to achieve a testing goal.

The loop generally looks like this:

goal
  ↓
observe current application state
  ↓
reason about the next useful action
  ↓
act
  ↓
observe the result
  ↓
continue, recover, verify, or fail

The system may use multiple signals to understand the application: DOM content, accessibility information, screenshots, network requests, console logs, browser state, previous interactions, and application documentation.

Momentic describes agentic testing as software testing where an AI agent plans, runs, observes, and adapts tests. Its documentation recommends agentic steps for dynamic scenarios, exploratory coverage, high-level acceptance checks, and smoke tests where the precise path may change.

The agent's ability to choose the path is the core difference.

The simplest mental model: journey contracts vs outcome contracts

A deterministic test usually encodes a journey contract.

Given state A, when the user performs steps B, C, and D, the system must reach state E.

An agentic test is often closer to an outcome contract.

Given state A, a legitimate user should be able to reach state E.

Both are useful, but they catch different classes of failures.

Suppose your navigation changes from a sidebar to a top bar.

A journey contract may fail because the old sidebar control no longer exists. That failure tells you the implementation changed relative to the test.

An outcome contract may continue to pass because the agent discovers the new top navigation and reaches the same destination.

Which result is correct depends on what you intended to verify.

If the sidebar itself was part of the requirement, the deterministic failure is useful. If the only requirement was “customers can reach Billing,” the adaptive pass may be more meaningful.

Why agentic testing is growing now

Browser agents have existed conceptually for years, but three changes make the model more practical in 2026.

1. Language models can reason over richer application context

Modern models can interpret human instructions, inspect structured browser state, use tools, and revise a plan after an unexpected result.

That makes it possible to express tests in product language rather than only in selectors and API calls.

2. Browser automation infrastructure is mature

Agentic testing does not replace browser automation primitives. It builds on them.

Playwright's reliable browser control, accessibility-based locators, traces, and programmatic browser interfaces provide excellent machinery for an agent to use. Slack's study explicitly evaluated agent workflows using Playwright MCP and CLI approaches.

The AI is the planner; browser automation remains the actuator.

3. Software changes faster

AI coding tools have accelerated implementation. A developer can now make broad UI changes, generate entire features, and refactor flows in a fraction of the time it once took.

Testing becomes the bottleneck when regression automation still requires a human to manually update dozens of selectors and page objects after every large change.

Agentic testing is partly a response to that mismatch.

Where deterministic E2E tests are better

The rise of agents has produced exaggerated claims about “obsolete test scripts.” That is not a useful engineering position.

Deterministic E2E tests are still better in several important situations.

Fast, frequent regression

A known browser flow can execute quickly and cheaply. It does not need a model to reason through every step.

If you run 1,000 browser checks on every pull request, runtime predictability matters enormously.

Exact sequence requirements

Some behaviors should fail if the path changes.

Examples include:

• regulated approval sequences;
• security prompts;
• consent flows;
• financial confirmation steps;
• permission boundaries;
• required legal disclosures;
• workflow steps that must not be bypassed.

An agent finding “another way” to reach the result may defeat the purpose of the test.

Precise assertions

Traditional code is better when the assertion is highly specific: exact payload values, timestamps, accessibility attributes, network calls, redirect parameters, or data transformations.

Reproducibility

A deterministic script gives engineers a repeatable path to reproduce a failure. If a runtime agent takes a different route each attempt, diagnosis can become harder unless the platform captures detailed traces and decisions.

Low operational cost

Once a stable deterministic suite exists, replay can be extremely cheap relative to repeated model inference.

This is why Momentic's own documentation recommends step-based tests for core critical paths where speed and repeatability matter, and why Slack frames agentic testing as an additional layer rather than a replacement for the rest of the testing stack.

Where agentic E2E testing is better

Agentic testing earns its place where adaptability creates more value than strict path enforcement.

Dynamic interfaces

Feature flags, role-based menus, A/B tests, responsive layouts, optional onboarding states, and personalized content can make the exact route difficult to predict.

An agent can reason from the current state rather than expecting one fixed DOM structure.

Fast-changing product areas

A test for “user can upgrade their subscription” should not necessarily break every time the billing layout is redesigned.

If the business outcome is stable while the UI moves frequently, an agentic test can reduce accidental maintenance.

Exploratory testing

A deterministic script checks what somebody already thought to encode.

An agent can be given a bounded objective such as:

Explore the new workspace invitation flow as an account administrator.
Attempt normal invitation, duplicate invitation, and removal paths.
Report any state where the visible UI contradicts the expected permissions.

This is not a substitute for a professional exploratory tester, but it can increase coverage around known risk areas.

Bug reproduction

Production reports often contain incomplete steps. Agents can try variations while collecting evidence, potentially turning a vague report into a reproducible path.

Manual-only workflows

Some journeys remain manual for years because the maintenance cost of coding them never feels justified. Agentic testing can lower the threshold for automation.

Reliability: what does “passing” mean for an agent?

This is the most important question in agentic testing.

A conventional assertion is usually explicit:

await expect(page.getByText('Order confirmed')).toBeVisible();

An agent might reason:

I reached a confirmation page, therefore checkout succeeded.

That is dangerous if the same model both performs the task and decides that it succeeded based only on its own interpretation.

A better architecture separates execution from verification.

For example:

1. The agent attempts the journey.
2. The platform captures the final browser state.
3. An independent verifier checks explicit postconditions.
4. The system retains screenshots, DOM state, logs, or traces.
5. The run reports pass/fail based on evidence rather than the actor's confidence.

CueTest's current product positioning follows this idea: each natural-language step has an expected result that is checked against the live page, while execution can use a learned path and AI-assisted resolution when needed.

The broader principle matters regardless of vendor: the agent should not grade its own homework without evidence.

The self-healing trap

Self-healing is related to agentic testing but is not the same thing.

A self-healing test usually keeps a scripted journey but attempts to recover when a selector changes. BrowserStack, for example, documents AI self-healing that can find an alternative element when a Playwright or Selenium locator no longer works.

This is useful when:

#submit-order

becomes:

[data-testid="place-order"]

but the semantic control is still the same.

It is dangerous when the application has genuinely changed in a way the test should notice.

Imagine a checkout page where “Place order” has accidentally been replaced by “Save quote.” An overly permissive healer might find the nearest prominent button and continue.

Good healing therefore requires:

• semantic confidence;
• bounded adaptation;
• postcondition verification;
• audit logs;
• a clear distinction between recoverable test drift and product change.

Agentic testing has the same problem at a larger scale.

Cost and speed: the uncomfortable trade-off

Runtime reasoning costs more than deterministic replay.

Slack's agentic testing research raised this directly, noting that early agent-driven workflows could take many minutes and incur meaningful model cost per run. The exact numbers in any platform change rapidly, but the economic principle remains.

If an agent spends ten minutes reasoning through a workflow that Playwright can replay in 20 seconds, you should have a reason for paying that difference.

The reason might be:

• the deterministic test would require two hours of maintenance every sprint;
• nobody has automated the workflow otherwise;
• the agent is performing exploratory work rather than regression replay;
• the test runs once after a deployment instead of hundreds of times per day;
• the agent collects diagnostic value that a simple script does not.

A mature agentic testing architecture should minimize unnecessary reasoning.

A sensible pattern is:

known path exists?
   ├─ yes → replay deterministically
   │          └─ outcome verified? → pass
   │          └─ path broken? → invoke AI recovery
   └─ no → invoke agent to resolve the journey
                └─ save reusable knowledge where appropriate

That hybrid design preserves adaptability without paying for full autonomy on every execution.

A hybrid testing pyramid for 2026

The testing pyramid does not disappear because agents exist. It gains another layer.

Layer 1: unit tests

Use for business logic, validation, state transitions, edge cases, and functions. Maximum speed and precision.

Layer 2: integration/API tests

Use for service contracts, persistence, authorization, backend behavior, and external integrations.

Layer 3: deterministic E2E

Use for stable critical journeys that should behave the same way repeatedly.

Examples:

• authentication;
• permission boundaries;
• payment confirmation;
• known regression cases;
• core release gates.

Layer 4: agentic E2E

Use for:

• dynamic journeys;
• adaptive smoke testing;
• high-maintenance product areas;
• exploratory coverage;
• bug reproduction;
• workflows not worth maintaining as rigid code.

Parallel layer: visual regression

Functional success does not prove visual correctness. Maintain screenshot-based checks for surfaces where layout or appearance is part of the product contract.

Designing good agentic tests

Agentic testing still requires test design. The syntax is easier; the thinking is not.

Give the agent a constrained goal

Bad:

Test our app.

Better:

Using the administrator test account, invite a new member to the workspace and verify that the member appears in the active-member list with the Member role.

State the starting conditions

Specify whether the account should be new, authenticated, empty, subscribed, or already populated with data.

Define what success looks like

Do not make “task completed” the assertion. Define observable postconditions.

Restrict destructive behavior

Agents should operate against controlled environments, test accounts, and allowed actions. Avoid open-ended instructions on production systems.

Decide which variation is acceptable

If the agent can choose another navigation path, say so implicitly through an outcome-oriented goal. If exact steps matter, use a more constrained test.

Capture the path taken

A run should preserve enough evidence to reproduce or understand the interaction: screenshots, trace, actions, relevant DOM state, logs, and failure context.

Example: testing subscription upgrade both ways

Suppose the requirement is:

A Starter customer can upgrade to Launch and see the new plan reflected before payment.

A deterministic test might encode:

open /settings/billing
click plan card Launch
click Upgrade
assert invoice modal visible
assert plan name = Launch

This is ideal if the billing UI is stable.

An agentic test might encode:

As the Starter test customer, upgrade the account to the Launch plan.
Do not submit payment.
Verify that the final invoice preview identifies the Launch plan and displays the expected recurring amount.

This test can survive navigation changes while preserving the business outcome.

Now imagine the application accidentally removes the invoice preview entirely and sends the user directly to payment.

The agent should fail because the expected postcondition was not satisfied—even if it could technically continue the purchase.

That example shows why agentic testing works best when the goal is adaptive but the verification is strict.

When to convert an agentic test into a deterministic test

Agentic tests are useful during discovery. But once a path becomes extremely stable and executes frequently, deterministic automation may be more efficient.

Consider promotion when:

• the workflow runs on every commit;
• the path has not changed in months;
• precise ordering matters;
• runtime cost is noticeable;
• the test has become a critical release gate;
• a fixed script can reproduce the same signal more cheaply.

The reverse is also true. A deterministic test that constantly breaks due to harmless UI changes is a candidate for a more intent-driven layer.

Think of test type as an engineering optimization, not a permanent identity.

How to introduce agentic testing safely

Do not begin by deleting existing coverage.

Start with three categories:

1. Unautomated critical flows

Choose workflows currently checked manually before releases.

2. High-maintenance scripted tests

Look for tests with frequent selector or navigation updates.

3. Exploratory smoke checks

Choose outcomes where flexible navigation is acceptable.

Run the new tests alongside your current suite for several releases.

Compare:

• bugs caught;
• false positives;
• false negatives discovered manually;
• authoring time;
• maintenance effort;
• runtime;
• cost;
• diagnosis time;
• developer trust.

Do not optimize for the number of automated tests. Optimize for trusted release signal per unit of engineering effort.

Where CueTest fits

CueTest is designed for teams that want natural-language journeys with adaptive browser execution and inspectable evidence.

The current product supports natural-language E2E tests, reusable environment variables, execution hooks, run history, failure evidence, visual regression, schedules, API keys, and CI integration. Its public positioning explicitly targets teams that already value coded browser tests but want adaptive coverage where product changes outrun selector maintenance.

That makes CueTest a complement to deterministic automation rather than a philosophical replacement for it.

A sensible stack might be:

unit + integration tests
        ↓
Playwright for stable critical regression
        ↓
CueTest for adaptive product journeys and smoke coverage
        ↓
visual regression for layout-sensitive surfaces

If that matches your testing pain, run a CueTest journey against a public site and compare the evidence with what your current E2E suite gives you.

Frequently asked questions

What is agentic testing?

Agentic testing uses an AI agent that can observe an application, reason about the current state, choose actions, and adapt while pursuing a testing goal. The test is defined more by the desired outcome than by a fixed sequence of browser commands.

Is agentic testing the same as AI-generated Playwright tests?

No. AI-generated Playwright tests use AI during authoring, then execute as deterministic scripts. Agentic tests make decisions during execution.

Should agentic testing replace deterministic E2E tests?

Usually no. Deterministic tests remain better for fast, repeatable, precise regression checks. Agentic testing adds value for dynamic, exploratory, high-maintenance, or outcome-oriented workflows.

Is agentic testing reliable enough for CI?

It can be, but teams should use it selectively. Keep CI suites focused, constrain agent behavior, verify explicit postconditions, and retain evidence. For high-frequency stable paths, deterministic tests may remain more efficient.

What is the difference between self-healing and agentic testing?

Self-healing usually repairs a broken locator or test step while keeping the original scripted journey. Agentic testing can re-plan broader portions of the journey dynamically.

What is the biggest risk of agentic testing?

Silent adaptation. If an agent finds a different route and the system treats that as success without validating the intended product contract, a real regression can be hidden. Strong postcondition verification and audit evidence are essential.

Sources and further reading

• Slack Engineering — Agentic Testing: Where Agents Fit in the E2E Testing Stack
• Momentic — Agentic Testing for Engineering Teams
• Momentic — Agentic Testing Documentation
• Playwright — Locators
• Playwright — Best Practices
• BrowserStack — AI Self-Heal for Playwright
• CueTest Documentation