Epsilon adopts Amazon Nova Act for intent-driven UI testing

Introduction – why intent‑driven UI testing matters

Epsilon has adopted Amazon Nova Act and Amazon Bedrock AgentCore Browser to offer intent-driven UI testing through its shared agent platform. Product teams describe test steps in natural language, execute them in managed browser sessions, and retrieve structured results through an existing platform API. According to an AWS account of the implementation, Epsilon’s internal benchmarks show test authoring is 4–6 times faster than writing equivalent Playwright scripts.

The change adds a testing capability to an established practice. Epsilon continues to use Playwright as its regression backbone. The new service addresses a complementary problem: letting teams express what an application should do without specifying every selector, wait, and conditional branch themselves, while removing the need to operate browser infrastructure separately for each team.

That distinction matters when assessing the results. The evidence describes an internal deployment and company benchmarks reported by AWS. It supports a concrete account of faster authoring and shared operations at Epsilon, but does not establish that agent-driven testing universally outperforms scripted regression testing. The useful question is where intent-based execution fits alongside deterministic checks, and what platform engineering is needed to make it usable across teams.

Epsilon’s challenge and the decision to adopt Amazon Nova Act

Epsilon, a data, technology, and marketing-services company within Publicis Groupe, needed testing that could keep pace with application changes across its product teams. Its Playwright suite already validated web application functionality successfully. However, tests tied to selectors and page structure could require maintenance after cosmetic changes, even when application behavior remained sound.

There was also a shared infrastructure problem. Giving each product team its own browser environment, dependencies, and identity integration duplicated work. Epsilon wanted teams to consume testing through the same interface used for other agent capabilities, rather than requiring each team to operate a separate testing toolchain.

Its Agentic Platform team, comprising 50 engineers, already built shared infrastructure for creating, deploying, governing, and running agents. The platform provided a skills-based agent builder, federated identity, authorization checks, Model Context Protocol integration, and cross-account provisioning. UI testing could therefore become another managed capability within an existing operating model.

Epsilon evaluated the approach against two requirements: natural-language authoring to complement selector-based tests, and managed browser infrastructure suitable for its multi-tenant platform. Nova Act supplied execution of instructions expressed in plain English. AgentCore Browser supplied isolated, temporary browser sessions and managed their lifecycle.

Identity was part of that fit. Nova Act could use the standard AWS credential chain through the task role, avoiding separate API-key distribution. Cross-account access used AWS Security Token Service AssumeRole provisioning, allowing each team’s tests to run in its own AWS account under a scoped role. In this implementation, testing was integrated with the platform’s existing access model rather than introduced as an independently configured service for every team.

How Nova Act and Bedrock AgentCore Browser work together

The service has three principal components: an API for creating workflows, a background runner for executing them, and the integration between Nova Act and AgentCore Browser. Their responsibilities separate the test definition, execution scheduling, and browser interaction.

A user creates a workflow by supplying a target_url and natural-language steps through the platform API. The platform registers a Nova Act workflow definition on AWS. When execution begins, a background task runner using Celery opens an AgentCore Browser session and connects Nova Act through a Chrome DevTools Protocol WebSocket, the browser-control interface described in the source.

Nova Act then executes the instructions, including conditional actions such as dismissing an onboarding tour when one appears. The platform captures a screenshot for each step, records step-level pass or fail outcomes, calculates an overall pass rate, and stores execution artifacts, including results JSON and screenshots in Amazon S3. A completion hook records the outcome back into the platform.

The broader architecture uses an authenticated API gateway, a Django REST API, workflow and execution coordination, Amazon Simple Queue Service for queued jobs, and a runner service on Amazon Elastic Container Service. These layers matter because natural-language browser control alone does not provide workflow management, access checks, or results retrieval for multiple teams. Epsilon supplies that surrounding platform.

Teams access the capability through ui-test-agent, which exposes two skills. ui-test-recorder supports interactive exploration and recording of natural-language steps; ui-test-executor runs recorded steps and returns structured results. Onboarding involves provisioning a cross-account IAM role, registering application URLs, and granting access through the existing API.

Epsilon also isolates its Nova Act runtime in a dedicated FastAPI sidecar, pinning nova-act 3.x and the browser client separately from the main backend’s Strands agent stack. The source reports a region-related integration detail: the Nova Act signing endpoint targets us-east-1 regardless of the browser session’s region. Dependency isolation and a separate lockfile are part of Epsilon’s operational guidance, showing that managed browsers still require careful integration at the platform level.

Key benefits: natural‑language steps, speed, zero infrastructure

Natural-language authoring changes what a test author must specify. A step can describe the expected result, such as verifying that a rewards balance is visible, rather than naming the exact page element that contains it. AWS describes this approach as resilient to cosmetic UI changes and readable by people who do not write test code. That is a narrower claim than immunity to all application changes: the evidence does not show that instructions remain valid when the intended behavior itself changes.

Epsilon’s example workflow illustrates where the approach is useful. It covers login, agent creation, form completion, scrolling, and verification. Conditional instructions handle an optional onboarding tour and bring a skills search field into view before using it. In a conventional script, those conditions require explicit branching; here, they are expressed within the instructions Nova Act executes.

This readability also changes who can participate in test review. The source reports that people beyond core test engineers can read, review, and propose tests. It does not establish that all test design becomes automatic. Someone still has to define the intended behavior and decide whether the resulting workflow checks it adequately.

The infrastructure benefit is similarly specific. AgentCore Browser removes per-team responsibility for browser binaries, display servers, and browser-session lifecycle management. It provides live observation or takeover, including for situations involving CAPTCHAs or multi-factor authentication, along with session recording and AWS CloudTrail integration. These capabilities give teams ways to observe and investigate execution without building separate browser observability systems.

“Zero per-team infrastructure overhead” is Epsilon’s reported outcome for consuming this capability. The scope is important: the central platform still contains APIs, queues, runtime services, permissions, storage, and onboarding work. The architectural benefit is to concentrate that work in a shared service and use managed browser sessions, freeing individual product teams from recreating it.

Performance results: authoring time, pass rate, multi‑tenant rollout

AWS reports that Epsilon’s service is operational across multiple teams and that its multi-tenant architecture is in production. The source does not give the number of teams, execution volume, or concurrency levels. Its most concrete measurements concern authoring a representative workflow and replaying successful trajectories.

Epsilon summarizes its internal benchmark as 4–6 times faster authoring. That reported ratio should be kept distinct from the broad time ranges in the table: the source does not provide paired measurements or enough methodology to reconstruct the aggregate comparison. It also does not establish a corresponding improvement in execution speed, total testing cost, or defect detection.

The reported authoring advantage has a concrete explanation. For the Playwright equivalent, interactive steps require inspecting the document structure, selecting stable locators, and writing waits, assertions, and conditional branches. Nova Act expresses the workflow through instructions instead. This reduces the scripting work described in the comparison; it does not measure every part of testing or maintaining a suite.

The second prominent result is a 100 percent pass rate on saved trajectory replay, again based on Epsilon’s internal benchmarks. The qualification is essential. A workflow first goes through an exploration phase, typically requiring 4–5 prompt iterations before it passes. Epsilon saves the successful trajectory and then replays it deterministically. The perfect pass rate applies to those saved trajectories across the repeated runs reported, rather than to every newly authored instruction or first attempt.

The source does not disclose the number of replays or the extent of application changes during those runs. It therefore supports repeatability under the reported conditions, without establishing guaranteed success across future UI changes. Epsilon also reports that replay skips redundant model reasoning, reducing latency and cost, but supplies no numerical savings.

Per-step screenshots and outcomes provide another practical result: visibility into where a workflow failed. Epsilon reports easier diagnosis and useful audit records, although the package contains no quantified reduction in diagnostic time. Those operational benefits should remain separate from the measured authoring comparison.

Implications for AI‑agent driven QA across the industry

Epsilon’s deployment illustrates an agentic QA pattern that combines language-based exploration with reuse of successful execution trajectories. Exploration allows instructions to accommodate conditional situations; saved replay then limits repeated model reasoning for recurring workflows. The distinction helps explain how a service can offer flexible authoring while pursuing repeatable execution.

The case also makes platform integration central to the assessment. Epsilon’s product teams receive more than access to a browser agent: they receive identity integration, scoped account access, execution scheduling, results capture, and familiar APIs. For organizations considering a similar design, the relevant comparison is therefore broader than the syntax of a test step. It includes who owns the runtime, how tenants are separated, and how results are inspected.

The evidence favors coexistence with established test suites. Epsilon retained Playwright and added intent-based testing on top. That provides a documented adoption path, but no evidence here supports replacing every scripted check or declaring one approach superior for all workloads. The reported gains concern Epsilon’s workflow and operating model.

Several questions remain open for evaluating wider applicability: how much maintenance saved trajectories require as applications evolve, how reliably tests detect actual defects, and what total execution costs look like. The supplied results do not answer those questions. They do show why authoring time, replay conditions, and platform overhead should be assessed separately rather than compressed into a single claim about testing performance.

Conclusion – future outlook for agentic testing platforms

Epsilon has demonstrated an internal service in which product teams author tests in natural language, run them through managed browser sessions, and retrieve results through a shared agent platform. Its reported gains are meaningful within their stated scope: faster authoring, successful replay of saved trajectories, and removal of browser infrastructure work from individual teams.

The strongest implication is architectural. Agentic testing can be introduced as a managed complement to an existing regression suite, with central ownership of execution and access controls. Whether that pattern delivers similar results elsewhere remains an evaluation question. Epsilon’s experience supplies a concrete implementation and useful internal measurements; broader claims will require evidence about maintenance, defect detection, cost, and replay behavior under changing applications.