Decision 01
Don’t confuse agent failure with customer friction.
Agent constraint UX finding
An automated browser failing does not prove a human customer experiences the same problem.
UX Scout is an AI-powered customer journey tool that investigates how goals can be accomplished across the public web. Give Scout a goal, not a predefined path. It independently navigates the web and returns the journey, evidence, constraints, and defensible UX findings.
Product Strategy, UX, and Development
48-hour sprint · August 2026
React/Vite, Node/TypeScript, OpenAI Agents SDK, Playwright MCP
Opportunity
Product and UX teams evaluate the experiences they own. However, customer journeys extend far beyond them, revealing friction and decisions product analytics can’t see. What if AI could discover those paths autonomously?
Prototype
01
Describe what the customer is trying to accomplish.
02
Scout controls a real browser and independently determines how to pursue the goal.
03
Scout returns the path, evidence, constraints, and defensible UX findings.
System
Decision 01
Agent constraint UX finding
An automated browser failing does not prove a human customer experiences the same problem.
Decision 02
0 UX findings
Scout isn’t rewarded for manufacturing criticism when the evidence doesn’t support it.
Decision 03
Scout checks ambiguous qualifiers before claiming completion. If meaning can’t be verified, it returns a partial result instead.
Decision 04
Keep exploring? Stop with what’s verified?
Stopping rules and turn limits keep Scout from wandering indefinitely while preserving useful partial results.
User testing
Testing exposed problems I couldn’t anticipate from the initial prototype. Each failure became an input to the next iteration.
Iteration 01
An account-based journey with login.
2FA authentication introduced dependencies Scout couldn’t safely resolve.
Narrowed the prototype to public journeys.
Iteration 02
Letting Scout determine how long to explore.
More autonomy led to long, expensive wandering.
Added turn limits and bounded exploration.
Iteration 03
Verifying that Scout found the requested facts.
A fact could be correct while answering the wrong interpretation.
Required Scout to verify ambiguous qualifiers before claiming completion.
Iteration 04
Returning results only after Scout completed the journey.
An incomplete journey could still contain useful, verified information.
Preserved and returned verified partial results when Scout couldn’t complete the goal.
Metrics
| Journey | Result | Usable | Runtime | UX findings |
|---|---|---|---|---|
| Product information | Complete | Yes | 1:47 | 0 |
| Local service comparison | Partial | Yes | 2:18 | 1 |
| Airline policy: open start | Partial | No | 1:50 | 0 |
| Airline policy: supplied start | Partial | No | 2:10 | 0 |
| Entertainment / ticketing | Partial | Yes | 2:39 | 1 |
| Product recommendation | Partial | No | 2:05 | 0 |
Workflow
Technology
Outcome
What I learned
Scout worked when browser automation could access the experience. But real journeys crossed sites that blocked, challenged, or otherwise prevented automated navigation, leaving gaps Scout couldn’t resolve.
What that means
The original problem remains: product teams have limited visibility into customer journeys that extend beyond the experiences they own. UX Scout showed me that browser automation alone isn’t enough to document those journeys reliably. Solving that problem would require a different approach, or a combination of approaches.