MyLabelDesk, a B2B SaaS platform for record labels, had Sentry running in production. It was catching exceptions just fine. Meanwhile two critical bugs had been live for weeks without a single alert: one blocked every file upload, the other made the export buttons do nothing at all. This is how AI agents found them.
The setup
The platform is a workflow tool for the music industry. Its core flow spans 11 steps, from track upload through internal review, signing decisions, artist intake, contract management, and distribution to services like Spotify and Apple Music.
It is exactly the kind of app that is hard to test: multi-step workflows with role-based access, real-time updates, file uploads to cloud storage, and integrations with three external services. The team had Sentry set up and was catching runtime errors. They assumed their critical paths were covered.
What we ran
We ran 25 AI agent test sessions with Aiqaramba. Each agent received a plain-language description of a test scenario. No selectors, no scripts, no page objects. The agents navigated the app in real browsers, Chrome and Firefox, and made decisions the way a user would.
Six distinct journeys covered the full 11-step workflow end to end, with several agents per journey to cover both browsers and a few edge cases. Across those 25 sessions the agents reported 19 bugs. Two of them were blockers.
The two critical bugs Sentry could not see
Bug 1: CORS blocks every file upload after track creation
The first agent report on this one confused us. An agent had created a track, gone to the detail page to attach the audio file, and then reported that the upload "completed without visible result". We read that as the agent being lazy about verification and nearly marked it as a prompt problem. Then a second agent, in Firefox, reported the same thing. A third one had opened the browser console and pasted the actual error: the request to the upload endpoint was blocked by the browser's CORS policy.
That explained the silence. CORS is enforced by the browser, so the request never reached the server, so Sentry never saw an exception. From the user's side: click upload, nothing happens. No error message, no spinner, no feedback. Try again. Nothing. Eventually you assume the feature is broken and work around it, or you leave.
The agents caught it because they actually tried to upload a file, noticed that nothing changed on the page, looked at the console, and reported the exact endpoint and error message. The bug showed up in 4 of the 25 sessions.
Bug 2: Export buttons produce zero feedback
The distribution step has export buttons that send track packages to distributors. When agents clicked them: no download, no success message, no error, no loading indicator. The buttons accepted the click and did nothing.
Again there was no exception for Sentry to catch. The click handler ran, and whatever was supposed to happen downstream simply did not happen. This is a logic bug. Error monitoring tools are built to catch unhandled exceptions, and nothing in this flow threw one.
Why error monitoring has a blind spot
Sentry, Datadog and Bugsnag are all excellent at what they do. They share one limitation: they can only report errors that the code explicitly throws. That leaves a whole category of bugs invisible.
| Bug type | Sentry | AI agents |
|---|---|---|
| Unhandled exception or crash | Yes | Yes |
| Server 500 errors | Yes | Yes |
| Silent upload failures | No | Yes |
| Buttons that do nothing | No | Yes |
| Broken multi-step workflows | No | Yes |
| Missing form validation | No | Yes |
| Confusing or missing form feedback | No | Yes |
| State not updating after an action | No | Yes |
| Cross-browser inconsistencies | No | Yes |
Error monitoring catches what the code reports. Agents catch what users experience. The two are complementary, and most teams only have the first one.
The full breakdown: 19 bugs by severity
Beyond the two critical bugs, the agents found a layered set of issues across the whole workflow:
- 2 critical: the CORS upload blocker and the dead export buttons described above
- 1 major: zero user feedback when uploads fail silently
- 5 moderate: including persistent Supabase 406 errors across 10 sessions, a non-functional settings section, and review states that only updated after a manual page refresh
- 11 minor: confusing placeholder text in forms, inconsistent search results, and UI elements that did not respond on the first click
The Supabase 406 errors are a good example of the grey zone. They did appear in network requests, and Sentry could have caught them with the right instrumentation. Nobody had instrumented them. The app kept working with degraded data, and without someone clicking through the affected screens they went unnoticed.
What made the agents effective here
Three things made this work where manual testing and error monitoring fell short.
End-to-end workflow coverage. Each agent walked the full 11-step flow instead of isolated pages. A bug that only appears at step 7 after specific actions at step 3 is invisible to unit tests and unlikely to surface in ad-hoc manual testing.
Parallel cross-browser execution. Chrome and Firefox ran at the same time, so browser inconsistencies came out without doubling the time spent.
Console error analysis. The agents observe the UI and can also read the browser console, network responses and DOM state. That is how they caught the CORS block: the UI showed nothing, the console told the whole story.
The result
After the run, the team had a prioritised bug report covering every severity level, with reproduction steps, browser console output and screenshots for each issue.
The two critical bugs were fixed within days. Both had been live in production, invisible to Sentry, affecting real users who had quietly worked around them.
If your team has Sentry and a green dashboard, you know nothing is crashing. Whether the product works is a separate question, and it needs a separate answer.