Test your product with your own agents, and keep what they found
Evidence status: Capability pattern grounded in current Oddlynew types, documents, files, Loops and organizations. It is not presented as a customer testimonial.
Who this is for
Teams whose coding agents build their product and who want it used and checked the way real people would use it, by agents they already run, without handing the test to someone else.
Outcome
Your agents use your product like people do: they sign up, try the main journeys, and note what breaks or confuses. What matters is what comes out of each run, and that lands in your organization: a Test run document per run, and a Finding per problem with the steps, the evidence and what was expected. Your coding agent reads the open findings, fixes them, and a test agent runs the journey again before a finding is closed.
The working pattern
Choose where the runs go. Your product's own organization, so findings sit next to the product's other knowledge; or a throwaway organization for an experiment, deleted when you are done.
Make two types. Test run (journey, persona, build or commit, result) and Finding (severity, steps, evidence, expected, actual, status, fixed in) (When a kind gets its own type).
Write who tests and what they try. A short document per persona (who they are, what they know, what they want) and per journey (the steps a person takes to reach a result). Different agents, and agents from different makers, playing different people find different problems.
Run the test agents against a test build. Each uses your product with its own browser tools, records one Test run, and files a Finding per problem, with screenshots uploaded as files.
Fix and check again. Your coding agent takes open findings, fixes them, and links the change. A test agent runs the journey again and closes the finding or reopens it with what it saw.
Make it recurring. A Loop runs the main journeys on every new build or every night (Your agents run your Loops); judge results against principles you trust, such as UX and UI Principles for Websites.
Useful connections and plugins
Browser tools in your agents: to open the product, click, type and take screenshots.
A test environment: a staging build with test accounts and test payment modes.
Your CI system: to start a run on every build with an organization key kept as a secret.
Code tools in your coding agent: to read findings, fix and link the change.
A good first task
Ask your agent: "Create Test run and Finding types in our organization. Write one persona and one journey for signing up and doing the first useful thing in our product. Then use our staging site as that person, record the run, and file a Finding for each problem with steps and a screenshot. Show me the three most important findings."
Boundaries
Test builds and test data only. Agents that click everything also submit forms and pay; point them at staging, test accounts and test payment modes, never at real customers' data.
Screenshots can show data. Keep test accounts free of real people's details before evidence is stored.
Agents are not your users. Agent runs find breakage and confusion fast; what real people feel still needs real people.
Why it compounds
Every run leaves findings tied to a build, and every fix is checked by the same journey that found it. Personas and journeys improve as they catch things, and the next run, the next agent and the next teammate start from what was already learned. It is the same idea as Review every change with several agents, applied to the product as people experience it.