Epsilon automates UI testing with Nova Act in AWS-managed browsers

What changes in Epsilon’s UI testing

AWS presents Epsilon’s Agentic Platform as a managed user-interface testing service. Teams describe tests in natural language, and those tests run in browsers managed by AWS. The proposal aims to reduce the infrastructure each team would otherwise need to set up and maintain separately, while making tests express the intent of the flow they are meant to check.

The practical change is not that test design becomes unnecessary. Rather, some execution is handed to a system that interprets instructions and operates a browser. In the approach AWS describes, Nova Act helps automate UI actions, while Bedrock AgentCore Browser Tool provides the browser environment. AWS’s post describes this combination but does not present an independent report that would make it possible to measure performance in production.

“Intent-driven” refers to writing down the result a team wants to check rather than limiting a test to a fixed sequence of technical steps. This can be useful when an application’s user journey changes frequently. But a more flexible instruction does not guarantee that an agent will correctly understand every variation or detect every relevant failure.

The available information establishes the broad technical and operational approach: a managed service, product teams as users, and browsers managed by AWS. It does not establish how many teams use it, what types of applications the specific implementation covers, or what share of tests runs without intervention.

How Nova Act and the managed browser fit together

A browser test usually combines an intent—for example, checking whether an operation can be completed—with concrete actions: opening a page, selecting controls, entering data, and reviewing the result. In the system AWS describes, instructions are written in everyday language and Nova Act is used to automate interactions with the UI. AgentCore Browser Tool supplies the managed browser in which those interactions take place.

This division helps clarify each component’s role without overstating its capabilities. Nova Act is the model-based automation component; the managed browser is the environment in which the application is observed and operated. The available information does not explain how each instruction is translated into steps, which deterministic mechanisms validate the result, or how errors are handled when the UI does not match expectations.

Model-based automation can interpret an instruction and choose likely actions, but that is not a guarantee that a flow will complete correctly. Explicit checks—such as validating expected text, a state, or a structured response—are different from the probabilistic decision about where to click or what to do next. Assessing a test requires understanding both how the instruction is interpreted and what criteria determine whether it passes.

Nor should a browser being managed by AWS be taken to mean that every aspect of security or session isolation is documented. The description says the browser is managed by AWS, but the available evidence does not specify how sessions, credentials, temporary data, or logs are separated between customer teams.

What the QA automation example shows

An AWS example repository shows another way to organize quality tests with the Nova Act SDK and pytest. The project combines browser tests, parallel execution, and HTML reporting that can include results, duration, failures, screenshots, and logs. It also illustrates assertions for checking Boolean values, text, or data structures.

The example is useful as an engineering reference: it shows how an agent can be integrated with familiar testing tools and how reports can be organized. It is not an evaluation of Epsilon’s platform, and it does not demonstrate that any natural-language test will be stable or valid elsewhere. A code sample shows that a reference implementation exists; by itself, it does not establish a success rate or production behavior.

The repository lists environment requirements, configures pytest-xdist for parallel execution, and allows tests that need to run sequentially to be grouped. That setup addresses a common need: some tests are independent, while others share data or depend on the result of an earlier test. Running tests in parallel can save time for certain workloads, but it does not remove dependencies or guarantee reproducible results.

The project also provides for storing logs and browser data by test and generating an execution report. For a team assessing this kind of solution, those artifacts may help with failure analysis. Even so, having logs or screenshots does not demonstrate that the system will catch every error, nor does it by itself define how long they should be retained or who can access them.

What a managed, multi-tenant service means

AWS describes Epsilon’s platform as a managed, multi-tenant service that runs in managed browsers. Operationally, this suggests that product teams can use shared infrastructure rather than each maintaining its own browser environment. AWS presents avoiding per-team infrastructure as a goal; it does not provide a breakdown of costs, staffing needs, or measured savings.

The multi-tenant label alone does not establish which resources are shared or how they are separated. Components may be shared while session- or customer-level isolation controls are also in place, but the information reviewed does not specify that design. The description does not let us infer what protections apply to cookies, credentials, browser profiles, screenshots, logs, or data extracted during a test.

These distinctions matter to organizations assessing such a service because tests may access accounts, test data, or environments containing sensitive information. The public information available here does not confirm retention policies, access controls, data location, or mechanisms for separation between customers. The lack of detail does not show that these controls do not exist; it means they are not established by the evidence reviewed.

Centralized management may also reduce local installation and maintenance work, but it shifts some operational questions to the provider and the service configuration. The convenience of not managing local browsers should be distinguished from evidence about security, continuity, isolation, and recovery from failures.

Reliability, oversight, and limits of the evidence

The available evidence describes Epsilon’s approach but offers no reproducible, implementation-specific metrics for accuracy, coverage, intermittent failures, or time savings. It also does not explain which tasks run autonomously, which results require human approval, or what happens if the agent misinterprets an instruction.

Amazon has announced general reliability figures for Nova Act in early-customer workflows. That corporate claim has a different scope: it is not an independent measurement of Epsilon’s platform and does not establish that Epsilon achieves the same success rate. An aggregate figure also depends on the tasks, environments, and reliability criteria used; without those details, it is not a guarantee for a particular application.

UI automation must contend with design changes, variable elements, loading times, and unexpected results. A system may complete one journey correctly and fail on a similar one. Tests therefore need to be assessed against representative scenarios, observable acceptance criteria, and a review of failed cases. Writing an instruction in natural language does not make a test inherently robust.

The evidence supports a limited conclusion: AWS describes an architecture that combines natural-language instructions, Nova Act, and managed browsers so Epsilon can offer UI testing as a service. The QA example provides a practical reference for the SDK, pytest, and reporting. The evidence reviewed does not establish a specific Epsilon reliability rate, a defined level of coverage, freedom from human intervention, or particular multi-tenant isolation properties.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.