Building intent-driven UI testing with Amazon Nova Act
Epsilon uses Nova Act and managed browsers for plain-language UI tests alongside Playwright. Here is the workflow and what its reported results do—and do not—show.
- Epsilon's service turns plain-language steps into managed browser executions with per-step results.
- Its Playwright regression suite remains in use for deterministic checks.
- AWS-reported authoring gains come from Epsilon's internal benchmark, not a universal guarantee.
Direct answer
Epsilon's Agentic Platform team uses Amazon Nova Act with Amazon Bedrock AgentCore Browser to offer intent-driven UI tests to its product teams. Test steps are written as plain-language goals, executed in managed browser sessions, and returned with per-step results and screenshots. AWS presents this as a complement to Epsilon's existing Playwright regression suite, not a replacement for deterministic tests.
How Epsilon's service works
A team submits a target URL and a sequence of test steps through Epsilon's platform API. A background runner starts an isolated browser session, uses Nova Act to perform the steps, and records pass or fail results with screenshots. The platform manages access and execution across teams rather than asking each product group to operate its own browser infrastructure.
An example workflow covers sign-in, form entry, conditional onboarding prompts, scrolling, saving, and checking that a new agent appears. Those steps express user intent, while the existing Playwright suite continues to check predictable regressions.
What the reported results mean
AWS reports that Epsilon's internal benchmark found faster authoring for a representative 18-step workflow. This is Epsilon's comparison under its own conditions, not a general speed guarantee. The case also describes trajectory replay for repeated runs and an audit trail from managed browser sessions.
For a web application team, the useful design question is which journeys benefit from readable intent-based checks and which still require exact assertions. A sensible pilot would measure authoring time, failure investigation time, false alarms, and coverage on one real workflow before expanding. Security and account permissions for test environments also need review.
This is an interpretation of Epsilon's implementation, not a claim that MTREXA built or operated it.
Source and attribution
This briefing is based on AWS's October 29, 2026 Epsilon case study. Read the original for the architecture, benchmark context, and implementation details.
Evaluate Architecture Feasibility for Your Systems
MTREXA provides structured feasibility diagnostics and systems architecture advisory for engineering and operations leaders.