Your QA suite tests one thing: that the happy path works.
Give it valid input, expect the correct output. That’s the entire contract most test suites encode. Nobody writes the other suite — enumerate everything the system accepts, then check it against what the business actually wanted.
That gap stayed invisible for years, because nobody walked it. A human user, moving through a multi-step transactional flow — search, select, fill in data, confirm — would get bored, hesitate at an unfamiliar state, or just call someone instead of poking at the edges. The state space you never tested stayed unvisited by convention, not by design.
An agent doesn’t share that convention. It doesn’t get bored. It doesn’t feel like an intermediate state is odd and back away. It tries whatever the system allows, and when one of those paths resolves — a retry sequence nobody anticipated, a combination of steps nobody validated together — it completes the transaction. Not a failure. A success, at a destination nobody signed off on.
That’s the part that never shows up in an incident report, because nothing broke. The system did exactly what it was built to permit. It just permitted more than anyone specified.
The fix isn’t more test cases for scenarios you can already imagine. It’s a second question, asked of every flow you’ve already shipped: not “does the intended path work,” but “what else does this path allow, and would we stand behind it if it happened.”
Most companies have never run that second query, because until now nobody exhaustive enough existed to need the answer.
Pull up any multi-step flow you own. Ask an engineer what the state space actually permits, separate from what it was designed to do. If nobody can answer in a sentence, that’s the exact gap an agent will find first — and it won’t file a bug report when it does.