The Age of Autonomous Automation: The Combination of Agentic Testing and Multi-Agent Architecture
The software quality industry is currently facing the most significant technological earthquake since the transition
From UI-driven testing tools to advanced code writing. The deterministic model, which was the mainstay of
Test automation in the last decade – where engineers meticulously code every interaction with the browser
Using libraries like Playwright, Cypress or Selenium begins to reveal its deep limitations in the present
Today's pace of development. The last few weeks in the industry, as reflected in the lively discourse in professional communities,
Pointing to the crossing of a watershed: the transition from writing and maintaining rigid scripts to orchestrating and managing
Independent artificial intelligence agents, a practice known as Agentic Testing.

The combination of this hot trend with the emerging insights and architectures at the forefront of AI research and development in
QA creates a clear roadmap for the next generation of testing. It is no longer about tools that generate test code for us.
Initial (Code Generation) that we will have to maintain, but in completely autonomous software entities. These agents
Able (up the road) to accept a test hypothesis or business requirement in natural language, navigate a complex system
In real time, draw conclusions, deal with unexpected obstacles, and perform precise Selfhealing without any
Human intervention. This article breaks down this paradigm shift, examining the technical architecture
behind it, and highlights the engineering challenges organizations face in implementing this model within CI/CD
.modern pipelines
Anatomy of a Paradigm Shift: From Hard Code to Intent-Driven Testing
For years, automation engineers have struggled with one major chronic disease: code maintenance. Every little change
In the DOM, updating a CSS class or refactoring a front-end component triggered a wave of Flaky tests.
and Pipeline breakage. The deterministic work model required the tester to explicitly define each step:
Locate the element by XPath or CSS Selector, wait until it is visible, click, and verify the result.
This approach, while providing complete control, can produce very brittle code that is intolerant of changes.
The vision of Agentic Testing takes us into the world of Intent-Driven Testing. Instead of telling a machine “how” to perform a task at the pixel or locator level, we tell it the “what” – the business intent. When we instruct an autonomous agent with a sentence like “Add item to cart, proceed to checkout, and ensure VAT calculation is accurate for a European address,” the agent takes full responsibility for breaking down that request into a set of technical actions.
The agent analyzes the screen, identifying semantic elements (such as purchase buttons or payment forms) even if the identifiers
Their internals have completely changed and are navigating their way to the goal. This fundamental change frees up the development teams
From micromanaging element identifiers and allowing them to focus on covering business logic and edge cases
The critical ones of the system.
The Inference Engine: The Internal Architecture of an Autonomous Testing Agent
To understand how this magic actually happens, you need to dive into the internal architecture of Agentic Testing engines. Unlike a linear script, an AI agent is based on a constant feedback and processing loop, known as a Reasoning Loop, which consists of four key layers of action that work in synergy:
Perception: The agent must “see” and understand the application under test. Advanced engines do not rely solely on scanning the DOM, which is often littered with meaningless Divs in React or Angular applications, but use a combination of Accessibility Tree data and Vision Models. The agent analyzes screenshots in real time, identifies elements based on their visual appearance and semantic context, and generates a perceptual map of the current state of the application. This is the basis for true self-healing capability, as the agent is not blind to visual or hierarchical changes in the page structure.
Context-based planning (Planning & Reasoning): This is where the central LLM engine comes into play. Given the current picture of the system and the test goal (Intent), the agent must make a decision about the next step. This step requires careful management of the Context Window. The agent maintains a short historical memory of the actions it has already performed in order to avoid entering infinite loops or repeating errors. It evaluates alternatives, performs Chain-of-Thought reasoning, and plans the logical sequence that will lead it to the desired result.
Action Execution: Once the decision is made, the agent translates it into execution commands against a headless browser using common protocols such as CDP or existing drivers such as Playwright. The physical actions – typing, complex clicks, navigation, and interaction with Shadow DOM elements – are performed instantly while listening for network requests confirming that the action was completed successfully.
Oracle & Evaluation: The most important link in the loop. In traditional automation systems, Assertions are rigid and binary. In an autonomous agent architecture, the Test Oracle is flexible and intelligent. The agent is able to read the results of the operation, compare them to the business expectation, and understand whether the test passed or failed even if the exact text on the screen is not exactly the same as the expectation, but its meaning is the same. This capability dramatically reduces the amount of False Negatives in the system.
Orchestration of Multi-Agent Arrays in Complex Applications
One of the weaknesses of using a single LLM to perform complex tasks is its tendency to lose context as the process gets longer, a phenomenon that often leads to hallucinations and incorrect execution of the script. To solve this, the natural evolution of Agentic Testing is the move to Multi-Agent Architectures.
In such an environment, an organization does not rely on a single AI entity to do everything, but rather establishes an ecosystem of agents.
Internists working collaboratively, just like a "human" team of developers and testers:
The Planner Agent - This agent operates at the top layer. It feeds it with architecture documents, user stories, or Swagger/OpenAPI files and generates a holistic work plan and smart coverage strategy from them. It does not run actual tests, but rather breaks down the tasks to execution agents.
The Explorer Agent - An agent programmed to perform exploratory testing. Its purpose is not to test a specific script, but to roam the application, locate new user paths that have been added, attempt to crash forms using input exceptions (fuzzing), and continuously map the system.
The Executor Agent - The tactical building worker. Receives a specific test script from the Planner, takes the helm of the Playwright, and carefully navigates the application to perform the required process from end to end.
The Oracle Agent - An agent whose sole purpose is objective, cold validation. It receives the output from the Executor against business expectations, and its job is to determine whether the test passed. It is completely isolated from the navigation process, which prevents confirmation bias in which the executing agent "convinces" itself that the action was successful.
The Self-Healing Agent - Serves as a rapid response team in the event of a failure. When a test fails, this agent analyzes the stack trace, network logs, and visual context of the moment of failure. It deduces whether it is a real bug or a legitimate UI change, and generates a real-time correction to the navigation strategy for subsequent runs, all while updating the relevant function or prompt in the repository without human interaction.
The engineering challenges and technical obstacles on the way to full implementation
Despite the promising picture painted by industry leaders, the transition to using autonomous agents in large-scale agile development environments is not without engineering complexities. Test architects attempting to implement agentic testing within existing pipelines encounter a number of technological obstacles that require a precise architectural solution.
The problem of non-determinism: Modern CI/CD infrastructures are based on the fundamental principle of absolute repeatability: the same code run against the same environment must yield exactly the same result. Language models, by their probabilistic nature, may make slightly different decisions on each run, even if the model is configured with zero Temperature. A slight change in the order of operations, clicking on an alternative component, or a slightly different interpretation of the existing state may create a completely new type of flaky tests – ones that do not result from instability of the application or server, but from excessive flexibility of the agent. To deal with this, engineering teams are required to define Structured Outputs (such as a rigid JSON Schema) and enforce strict rules on the agent's actions.
Response times, throughput, and token costs: Traditional automated tests in Playwright are performed at lightning speed, with a click or navigation action measured in milliseconds. In contrast, an autonomous agent required to decode a complex screen image (Multimodal Vision), send it against the DOM to a language model API, wait for the Reasoning process, and generate a prompt for execution, slows down the global execution rate significantly. Each step in the test can take several seconds. When these times are multiplied by hundreds of test scripts, the execution time in the Pipeline jumps from a few minutes to hours. In addition, the economic costs of repeated calls to advanced models against large test volumes can reach high amounts, requiring optimization of the prompt size and the use of small, local models (On-premise/Edge LLMs) for simple tasks.
Context Window and State Management Limitations in Complex Sessions: Many enterprise applications involve long and complex workflows, such as ERP system management or financial underwriting processes, that require dozens of sequential steps. As the agent progresses through the testing process, the amount of data entering the model's Context Window increases. This phenomenon not only increases costs and slows down the response, but can also cause the agent to "lose memory" about actions performed at the beginning of the process, or hallucinations in which the agent confirms a step that did not actually occur. Proper memory management using RAG techniques and dividing the test into defined state chunks are a prerequisite for system stabilization.
Integration into CI/CD Pipelines: The Proposed Hybrid Model
To bridge the gap between the non-determinism and slowness of AI agents and the requirement for a fast and stable pipeline, many QA leaders do not recommend replacing the entire testing infrastructure with agents immediately. The most effective solution today is to adopt a
In the hybrid model, the system is divided into two parallel pathways that operate in complementary dynamics:
Fast Execution Track: The core regression tests that run on each Pull Request in CI/CD remain based on classic, fast code (like Playwright or Cypress). These tests provide the fastest feedback loop to developers and are not dependent on the availability or cost of external APIs.
Asynchronous Discovery Track: Autonomous AI agents are run asynchronously, outside the blocking path of CI/CD, for example in nightly runs, staging environments, or in the background of Continuous Deployment systems. The agents perform exploratory testing, monitor UI changes, and validate end-to-end scenarios.
The added value of the hybrid model lies in the ability of AI agents to generate and update the classic scripts. When the autonomous agent detects a new test script or a change in the page structure, it successfully navigates, saturates the business logic, and then exports clean, deterministic, and validated Playwright code. This code is added directly to the project repository. In this way, the organization benefits from the flexibility and autonomy of the agent during the discovery and maintenance phase, along with the speed and reliability of classic code during the CI/CD phase.
The shift in quality engineering skills: from Automation Engineer to Context & Evaluation Architect
The development of Agentic Testing does not eliminate the need for testing professionals, but it does change the work output and skills required of the modern automation engineer.
While in the past most of the engineer's time was devoted to writing Sisyphean test scripts, identifying CSS Selectors, and maintaining broken code, the new era shifts the focus to three key roles:
Context & Guardrails Engineering: The engineer becomes the one who defines for the agent the "world" in which it operates. This involves writing complex prompts, defining business rules, managing OpenAPI documents, and placing safety restrictions (Guardrails) that will prevent the agent from performing destructive actions in the test environments (such as deleting databases or sending real emails to users).
Building Evaluation Systems (Evals & Test Oracles): Testing the quality of the test itself. Because the agent operates independently, the engineer is required to build Eval systems that assess the reliability of the agent, measure its accuracy, and ensure that it does not miss critical bugs or produce false positives.
Risk Analysis and Coverage Strategy: Moving from tactical automation to strategic quality management, engineers focus on analyzing system architecture, understanding business risks, and directing test agents to the most sensitive areas of the application.
The return on investment (ROI) in this model is not measured only in the number of tests written per hour, but in the dramatic reduction in maintenance hours and the team's ability to achieve much broader test coverage in a short time, without increasing the workforce.
The Age of Autonomous Automation: The Combination of Agentic Testing and Multi-Agent Architecture - Summary and Strategic Roadmap for QA Leaders
The combination of the expanding practices of Agentic Testing and the emerging architectural insights in the field marks the beginning of a new chapter in software engineering. The move from running rigid scripts to managing autonomous agents is no longer a passing trend, but a necessary response to the increasing complexity of modern software systems and the rapid pace of deployment.
For QA managers and technology leaders seeking to prepare their organization for this revolution, it is recommended to follow the following roadmap:
Infrastructure Readiness Assessment: Examine the quality of your app's DOM and Accessibility Tree. AI agents ultimately rely on readability semantics; an accessible app is one that is easy for autonomous testers to navigate.
Adopting hybrid tools in stages: We start by implementing existing AI components in current test engines (self-healing mechanisms in Playwright or LLM-based tools for generating test data) before moving to a full deployment of Multi-Agent Architectures.
Focused Pilot (POC): Choose one defined, complex, and change-intensive business process (Checkout or Form Onboarding) and create an autonomous agent for it that runs asynchronously in parallel with existing tests.
Investing in team training: Shifting the focus of automation engineers from just learning coding libraries to understanding AI architecture, engineering prompts, building test oracles, and managing evals.
Organizations that know how to intelligently combine the accuracy and speed of classic testing with the flexibility and inference of autonomous AI agents will achieve a distinct competitive advantage: higher software quality, significantly shorter time to market, and development teams freed from the burden of Sisyphean maintenance in favor of true innovation.
Alongside the theoretical developments in the field, in the practical arena, one can also see organizations already moving in this direction: Verisoft (www.verisoft.ai) is currently assisting several clients in establishing test systems of this type, and would be happy to share the experience gained with anyone interested in delving deeper into the subject.



Comments