What Are Agentic Workflows in Test Automation

Test automation stalled out years ago, capped at roughly a quarter of coverage no matter how much a team invested in it. Agentic workflows are what QA teams are now calling the thing meant to break that ceiling: AI systems that reason about a goal, plan their own steps, execute them, and adjust when something breaks. A script written six months ago just keeps running unchanged until someone notices it's wrong, and that gap between what a script does and what it should do is exactly where these systems are supposed to step in. This piece walks through where that actually holds up in practice and where it's still mostly a slide in a vendor's deck.

What makes a workflow "agentic," and how it differs from a script or a GenAI plugin

Forrester has tracked the same plateau for years. Companies build out automation frameworks, hire engineers to maintain them, and coverage still tops out around 25%. That ceiling shows up too consistently, across too many organizations with wildly different budgets, to read as a story about any one team not trying hard enough. It's structural.

Here's why. Traditional automation runs on scripts, and scripts are brittle. A locator points to a button by its CSS selector or its spot in the DOM, and the moment a developer redesigns that page, the script fails. The feature itself didn't break; the test simply can no longer find what it's looking for. Someone on QA has to notice the failure, figure out it's a maintenance issue rather than an actual bug, and rewrite the locator by hand. Do that across a suite with a few thousand cases and the maintenance tax eats the exact engineering time that was supposed to go toward new coverage. Delayed releases, code paths nobody got around to, engineers spending afternoons patching old locators instead of thinking about what might actually break next.

So when Forrester renamed its category from "Continuous Automation Testing Platforms" to "Autonomous Testing Platforms" in Q3 2025, that wasn't a branding refresh. Analyst firms don't rename entire market categories for sport. The rename signals that the underlying technology moved enough to need new words for it, which raises a fair question: if rule-based automation genuinely can't clear a quarter of coverage regardless of resourcing, what actually has to change to break through?

A three-level way of thinking about testing maturity helps here, since the terms get thrown around loosely otherwise. Level one is scripted, deterministic automation. It does exactly what it's told and fails on anything outside that. Level two is what most people mean today when they say "GenAI testing tool": you prompt it, it generates a test case or fills a form field, and it stops there. No chaining that output into a sequence, no checking whether the output was even right. Level three is agentic: the system reasons about a goal, plans a sequence of steps toward it, executes, observes what happened, and re-plans if reality didn't match the plan, without anyone standing over it directing each move.

The gap between level two and level three is the one people blur most, and it's worth pulling apart. A GenAI tool writes a test script when asked. An agent notices, unprompted, that a test has been failing intermittently, digs into why, fixes the assertion that was wrong, re-runs to confirm the fix held, and logs what it did. That's a different category of behavior, not merely a faster version of the same task.

Four ingredients make something agentic rather than just AI-flavored: a goal instead of a script, a reasoning loop that cycles through plan, act, observe, re-plan, access to real tools (browsers, APIs, databases, CI systems) so it can actually act rather than just describe an action, and memory, at minimum within a session, sometimes persisting across runs. Agentic is a capability level, not a product category you buy off a shelf. The same underlying language model can sit inside a non-agentic tool or a fully agentic one; the difference comes down to how someone wires the orchestration around it.

What agentic workflows actually do across the QA lifecycle

Walk a QA lifecycle stage by stage and agents show up differently than traditional automation at nearly every point, not just when tests run.

In planning, an agent reads requirements, user stories, or a code diff and drafts a test plan straight from that material, saving an engineer from starting on a blank doc. In generation, it writes scripts that include edge cases it infers from context, not just the happy path someone happened to remember. During execution, it handles dynamic UI elements, retries on transient failures, and tries to tell flakiness apart from an actual defect instead of just reporting red and moving on. In triage, it classifies failures, links them to a likely root cause, and writes a plain-language summary rather than handing back a pass/fail log someone still has to decode.

Self-healing gets most of the commercial attention, and it earns it, because it goes straight at the maintenance burden capping traditional automation at that 25% ceiling. A locator breaks because a UI element moved or got restyled; the agent finds the new element and updates the test itself, with no ticket and no two-week wait in someone's backlog.

Does that actually produce more stable suites, or is it just a nicer story? A 2025 study found flaky test rates in agentic QA systems as low as 8.3%, well below what conventional automation setups typically run. That number matters, because "more stable testing" is empty until someone attaches a rate to it.

Larger deployments tend to split the work across several specialized agents rather than asking one system to do everything. One agent generates tests, another executes them, a third checks coverage against the original requirements. The result looks like an orchestrated pipeline of specialists, which tracks with how human QA teams already divide labor.

How agentic systems make decisions: the reasoning and memory underneath

A language model sits at the center of this, but in a role most people aren't used to picturing. It plans a sequence of tool calls and checks, at every step, whether the last one worked, well beyond simply generating text.

Take a concrete goal: verify checkout still works after a code change. The agent breaks that down. What does the checkout flow actually consist of? What scenarios are worth testing? Which are already covered, and which are missing? Then it acts, calling browser automation tools, sending API requests, reading through response payloads. Then it observes, comparing what happened against what it expected, flagging the gap. If something fails in a way it didn't anticipate, it re-plans instead of halting and waiting for a rescue.

Memory does real work here, and splits into two kinds. In-context memory is everything the agent knows within a single run: test results so far, errors it's already hit. External or persistent memory is longer-lived: past runs, known flaky tests, historical failure patterns. It's what stops an agent from re-flagging the exact false positive it already chased down last week.

Here's a detail that tends to surprise people who assume "agentic" means "unsupervised." A 2025 study of 306 practitioners found that 68% of production agents execute at most 10 steps before needing human intervention. Autonomy in production is real, but deliberately short-leashed; nobody serious lets agents run for hours without a checkpoint. That same study found 70% of production agents relied on prompting off-the-shelf models rather than fine-tuning anything custom, which matters if a team is worried agentic QA requires an in-house ML group just to get started. Mostly, it doesn't.

The infrastructure question underneath all of this, and why it isn't just a software problem

Something gets underweighted in most conversations about agentic testing: these workflows are distributed systems, full stop, and distributed systems come with infrastructure problems that don't disappear because an LLM handles the reasoning.

An agent calling a browser, then an API, then a database, then a CI pipeline, then a cloud environment, builds a chain where every hop adds latency, a chance of failure, and a security surface someone has to account for. That's the ground everything else stands on.

Compute is the first place this bites. Agentic workflows aren't quick request-response cycles; they're multi-step processes that sometimes sit idle mid-run waiting on a CI signal or an API call to return. Infrastructure that bills for idle time, or charges a cold-start penalty every time a new step spins up, compounds that cost across a long chain of tool calls. That's a real constraint on how ambitious a team can afford to be with agent autonomy, and it's far cheaper to think through before scaling than after.

Geography matters more than people expect, too. Test an application deployed across multiple regions from a single distant test runner, and the latency you introduce has nothing to do with the application's real performance and everything to do with where the runner sits. That produces misleading results, and it's why teams need execution points physically close to whatever they're testing.

Security is another factor, and agentic pipelines sharpen it rather than soften it. Agents calling external APIs need controlled, auditable paths out; open internet access where anything could happen unnoticed is a liability. Agents touching staging or production need their identity checked on every request, rather than relying on a shared service account that blurs who, or what, actually did something. Once multiple agents start handing off work to each other, that verification has to happen at every handoff. It's the same Zero Trust logic that already governs how human employees get access to systems, just applied to non-human actors moving through a pipeline instead.

Edge compute networks that place execution points close to the system under test and enforce per-request identity checks matter here in one specific way: they reduce the infrastructure instability that otherwise makes agentic pipelines unreliable. A 2025 study of production agents found reliability was the top development challenge practitioners named, and a good chunk of that unreliability traces back to infrastructure instability rather than anything wrong with how the agent reasons.

Where human oversight still belongs in an agentic QA pipeline

Reading any of this as autonomy replacing people misses what the data actually shows.

The same 2025 study of 306 practitioners found 74% of production agents still depend primarily on human evaluation. Autonomy and oversight coexist here by design, because certain judgments aren't the kind of thing you hand to a reasoning loop, no matter how good the loop gets.

Someone has to decide what "correct" behavior actually looks like for a new feature. An agent can check that a system matches a spec, but it can't write the spec out of nothing; that takes understanding intent, business context, what the product is supposed to do for an actual person using it. Changes an agent makes to production test suites, especially self-healing edits that quietly modify assertions, deserve a look before they propagate further. An agent that "fixes" a failing test by loosening the assertion has technically solved the problem while making the test worthless. And ambiguous failures, a visual regression that might be an intentional redesign or might be a genuine accident, need business context that lives in someone's head, not in the test framework.

This is where the evaluation gap becomes the real engineering problem, arguably harder than building the agent in the first place. As teams move from a demo that works great in a conference room to something running in production daily, building infrastructure that can reliably evaluate what the agent is actually doing becomes the dominant challenge. Every current approach has real weaknesses. End-to-end outcome metrics can mask a failure happening in the middle of a workflow, manual inspection catches things but doesn't scale past a handful of agents, and static benchmarks drift away from the actual constraints of a live deployment, latency, cost, the stuff that only shows up once something's running for real.

Practically, this means agentic QA pipelines need deliberate checkpoints: moments where a human, or a separate evaluation agent built specifically for the job, reviews what the primary agent did before the next stage proceeds. Gartner projects a substantial share of agentic AI projects will get canceled by 2027, and a meaningful chunk of that traces directly back to teams' inability to systematically check what their deployed agents are doing. That's a practical downside underneath a lot of the current enthusiasm, not a risk sitting off in the future somewhere.

The tools and frameworks QA teams are actually reaching for right now

Two distinct paths exist for teams building this today, and which one fits depends heavily on the team.

Path one is open-source orchestration: LangChain for building customized LLM agents, LangGraph, CrewAI for coordinating multiple agents at once, AutoGen, SWE-Agent. These hand a team full control over agent behavior and evaluation logic, but the control comes with a real engineering bill attached. Somebody has to build and maintain the orchestration layer, and that somebody needs to actually know what they're doing.

Path two is commercial autonomous testing platforms: Tricentis Tosca, Perfecto AI, Test IO, and EPAM's agentic QA offering, all of which showed up in Forrester's Q4 2025 Autonomous Testing Platforms Wave. These are more opinionated by design and faster to stand up, trading flexibility for a shorter runway to a working pipeline.

One capability deserves calling out on its own: vision-driven UI automation, which AskUI represents well. Rather than relying on DOM selectors that snap the moment a page's underlying structure shifts, these agents look at the screen roughly the way a human tester does, which makes them meaningfully more resilient to exactly the kind of UI churn that breaks traditional automation most often.

Cloud providers are moving in too. Amazon's Bedrock AgentCore Browser and Amazon Nova Act signal that the big cloud platforms are building agentic test infrastructure directly into their own ecosystems, which matters for a team already deep in AWS that would rather extend what it has than bolt something separate onto the side.

So how does a team actually choose? Engineering-heavy teams tend to get more out of open-source frameworks, since they want direct control over behavior and evaluation logic. QA-led teams without deep ML expertise on staff generally do better starting with a commercial platform that abstracts the orchestration layer away entirely. And on the model side, recall that 70% figure from earlier: most production agents run on off-the-shelf models via prompting, nothing fine-tuned, so the barrier to entry is lower than it looks from outside.

This landscape moves fast, faster than most infrastructure decisions teams are used to living with. Of 30 agents reviewed in a 2025 AI Agent Index, 24 were either released or got major agentic feature updates within the 2024 to 2025 window alone. Whatever a team picks today is worth assuming it gets revisited within a year, not because the original call was wrong, but because the tooling underneath simply won't sit still.

What adoption actually looks like right now, and what a realistic path forward involves

Where does this actually stand, separate from wherever the vendors say it's headed? As of the 2025 Test Guild report, over 72% of QA teams were actively exploring or planning to adopt AI-driven testing workflows. That's a lot of exploring, and production tells a narrower story.

There's a real gap by company size, though smaller than conventional wisdom would guess. Per the LangChain State of Agent Engineering survey from December 2025, based on 1,340 respondents, 67% of organizations with 10,000 or more employees had agents running in production. For organizations under 100 employees, that figure sat at 50%. Smaller teams aren't nearly as far behind the enterprise as the usual AI-adoption narrative suggests.

Most agentic QA running in production right now is bounded and task-specific, well short of anything resembling fully autonomous end-to-end operation. The realistic near-term pattern looks like agents taking over specific, high-maintenance jobs, self-healing broken locators, triaging regression failures, while humans keep ownership of overall test strategy and the calls that require actual business judgment.

For a team trying to actually start, a few entry points make sense. Look first at the highest-maintenance part of the current suite; self-healing tends to be the best return on investment because it attacks directly the cost that's been capping traditional automation the whole time. Build evaluation infrastructure before scaling up agent autonomy; the teams that run into trouble are, with some consistency, the ones that skipped this step to move faster. Design agent identity and access control in from day one, rather than bolting it on after an incident forces the issue.

The infrastructure layer isn't something that only matters once a team scales; it shapes the economics from the very first pipeline a team stands up. Teams building agentic workflows on compute that penalizes long-running or idle processes will find the math turning against them as agents get more complex and take on longer chains of steps. Consumption-based, globally distributed compute changes that math, and it's worth factoring in at the design stage, not after costs become a problem nobody budgeted for.

Forrester's category rename, the pace new frameworks keep shipping at, the production numbers coming out of both enterprise and smaller organizations: the trajectory reads fairly clearly even with the current state still partial and uneven. Agentic workflows are on track to become the baseline expectation for QA teams, a capability broadly available rather than something reserved for whoever has the deepest engineering bench.