An agent UAT pass is a first round of user acceptance testing run by an AI agent before any human tester sees the build. The agent plays a first-time user, clicks through every acceptance criterion in a real browser, repeats the run on a phone-sized screen and reports back. It catches the obvious problems so your users can spend their time on the subtle ones.
We started doing this after a couple of UAT rounds went badly on our own projects. Ned Lowe, our Co-Founder and CTO, wrote up the approach for our developers and fractional leaders on 21 August 2026, with a prompt template for each kind of release. This is the longer version, with the template described in full and the reasoning behind each part of it.
Why UAT keeps finding obvious problems
User acceptance testing tends to fail in two predictable ways. Ned’s note described both. In one kind of case, UAT was delayed because the users who were meant to test simply were not available. In the other, the users turned up and found really obvious issues, which made the delivery team look careless.
Both failures waste the same scarce thing, which is a user’s attention. A business user who blocks out an afternoon for testing should be judging whether the feature solves their problem. If they spend that afternoon reporting a broken button on mobile or a form that throws an error, the round is gone and the real feedback waits for the next one. So the fix is to make sure the build that reaches them has already survived a first-time user.
How an agent UAT pass works for a UI
For a user interface, the agent pass is a single prompt that sets up a role and a goal, then adds some firm rules. You tell the agent who it is (a persona using the feature for the first time), where the feature lives, which test account to sign in with, and what the user is trying to achieve. Then you paste in the acceptance criteria.
The rules matter more than the setup. The agent drives a real browser with Playwright, the open-source browser automation library, and it is told to stay out of the source code. Reading the code lets an agent reason about what should happen, and a first-time user has no such luxury. So the agent clicks through and records what actually happens. It starts from a fresh browser context, so no cached login or saved state hides a problem, and then it repeats the whole run at a 390px mobile viewport. A lot of the obvious issues show up on phones.
At every step the agent captures a screenshot, any console errors and any network request that fails or comes back with a 4xx or 5xx status. The report it hands back has three headings: what is broken, what is confusing and what it could not complete. Each finding comes with repro steps and the screenshot. And the agent fixes nothing. Its job is to report, and keeping it out of the code keeps the findings honest.
There are two guardrails in the template as well. The agent stays inside the test account, and it takes no destructive action on shared data.
Running the same pass against a service
Services get a second version of the template, where the agent plays an integrating developer or a consuming system calling the service for the first time. Its only reference is the published contract, meaning the spec or the API docs. As with the UI version, it does not read our source to work out the intended behaviour, because the developer on the other side of an integration would never see it.
The agent calls the running service in a named test environment and completes the full sequence end to end. Then it goes after the unhappy paths:
- requests with missing fields
- fields with the wrong types
- expired or absent authentication
- calls made out of order
- a retry of a request that already succeeded
That last one is easy to forget and can expose duplicate records or double charges. The service report also has three headings, with one change: the middle one covers anything misleading or missing in the docs. Every finding includes the exact request and response, so a developer can reproduce it in seconds.
Where agentic UAT fits in ACDC
ACDC, our Agent Centric Development Cycle, is the method we use for agent-built software. As we set out in Uncomfortably Simple in the Age of AI, around half of an ACDC sprint goes on getting the specification right and a fifth goes on the build. The remaining 30 percent goes on validation.
An agent UAT pass sits naturally inside that validation time, and it depends on the specification work done earlier. The acceptance criteria you paste into the prompt are the same criteria the build was generated from. If they are vague, the agent has nothing firm to test against, which is one more reason to write them carefully. And when the pass turns up a real defect, the correction belongs in the spec before anyone regenerates, as we argued in Spec Drift: Fix the Spec, Fix It Once.
The limits of an agent UAT pass
An agent pass does not replace user acceptance testing, and we would be wary of anyone who says it does. Real users know things the acceptance criteria leave out, such as the workaround everyone relies on or the report finance actually opens every Monday. An agent cannot test for knowledge it was never given.
Still, the agent pass has two advantages over waiting for people. It is cheap, and it does not depend on anyone’s calendar, so it can run on every build. The template is also young. Ned’s note asked the developers already doing this to suggest improvements, and we are still changing it as more teams use it.
How to run your first agent UAT pass this week
Pick the next feature due for user testing and run one pass before you send the invitation. Write the persona and the goal in a sentence each, paste in the acceptance criteria as they stand, and give the agent a dedicated test account. Ask for the three-part report and nothing else.
Then read the report before your users see anything. If the broken list is empty and the confusing list is short, send the build. If the agent could not complete the main journey, you have saved your users an afternoon. Either way, keep the findings, because a pattern across a few runs usually points to a gap in how the acceptance criteria are written.
