Agentic quality assurance
Your agents write the code.
Who tests the app?
DeepQA boots the app behind your PR in a sandbox and puts an agent team on it in a real browser.
Evidence on every issue. An adversarial audit before anything ships.
Explore live resultsRequest early access#1 · Explore
47 pages · 18 forms mapped
#2 · Plan
36 scenarios · deterministic
#3 · Test
15 passed · 21 failed
#4 · Critique
46 findings · 5 withdrawn
Control
Spend stays under your control.
DeepQA checks whether your app is testable before it boots anything, hard-stops at the cap you set, and lets you end a Run while it is still going.
12 scenarios · 10 passed · 2 failed · 2 issues
Suitability Check refused it before boot, in 2 seconds
Stop after Explore, or Force-stop a running job
Recorded Run examples. Actual spend varies by app and Plan.
Checked before it costs you
The Suitability Check reads the repo first. An app DeepQA cannot boot is turned away in seconds, before any model is called.
A cap you set
Every Run carries a budget cap in dollars. The Run stops itself when it reaches that number.
Spend you can watch
Cost accrues live next to the stage timeline, so a Run is never a surprise on an invoice.
A way out, mid-Run
Stop ends the Run cleanly. Force-stop cancels the job outright when you need it gone now.
Why DeepQA
QA is not code review.
AI code review reads your diff and comments on your code. DeepQA uses the product your users get. They catch different failure modes, which is exactly why you want both on every pull request.
Code review tools
Read your code
DeepQA
Uses your app
The missing layer. Keep your review bot for the diff. DeepQA is what runs after the code looks right: the layer that checks the shipped product still works.
#1 Discover and replay
It learns your app, then keeps the plan.
Point DeepQA at a PR or commit. Agents browse the running app on their own, with no sitemap and no scripts, and turn what they find into a deterministic test Plan that the next Run can reuse.
Run #4 on this Plan: 10 passed · 2 failed · 2 issues · $0.36
Boots from any PR or commit
The Runner clones your repo and starts the app in a fresh sandbox, then destroys it when the Run ends.
Explores on its own
Agents browse pages, fill forms, and trigger actions with zero configuration, and the AppMap records everything they reach.
Deterministic by design
The Plan is prioritized scenarios you can read and diff like code, and the same Plan replays against any SHA.
Yours to choose, every Run
Reuse the latest Plan for comparable regression coverage, or write a new one when the app has moved on.
#2 Test and audit
A real browser, then an adversarial audit.
Scenarios fan out across parallel agents driving a real browser. Before anything reaches your report, a Critic re-runs every high-impact finding and tries to break it.
3 agents in parallel · every step screenshotted
Backup download returns HTTP 500, so no backup can ever be retrieved
reproduced twice on two separate backups · server log captured
Date-range filter is non-functional
the filter works with a complete range · kept visible in the report
On this Run the Critic reviewed 46 findings and withdrew 5.
Behaves like a user
Clicks, types, uploads, and navigates the real UI, not a simulated DOM.
Evidence on every issue
Screenshots of the moment it broke, console traces, and step-by-step reproduction.
Re-verified live
High-impact findings are re-run against the app before they ship as Issues.
Withdrawn stays visible
False positives are withdrawn on the record, never silently dropped, so you can check the audit instead of trusting it.
#3 Share and choose
Private until you publish.
Every Run finalizes into a private, evidence-backed report. Publish it and the full record goes live on Explore. The model behind it is your call.
screenshots are served through signed URLs while the Run is private
swap the model profile · the pipeline stays the same
Private by default
Finalized Runs are visible to you until you decide otherwise, with screenshots served through signed URLs.
Publish when you choose
One action puts the full record on the public Explore page, as a link anyone can read.
The whole record, verdicts included
Issues, screenshots, and the findings the Critic withdrew. Security issues publish as a summary, so a fix can land before the details do.
The model is your call
Gemini on Vertex AI by default, or bring your own key for OpenAI, Anthropic, OpenRouter, or any OpenAI-compatible endpoint. Keys are stored in Secret Manager.
Traceable numbers
QA runs executed across benchmark and platform campaigns
real applications put under test
confirmed defects in published runs alone
critical vulnerabilities uncovered, incl. auth bypasses
Outperforms the published state of the art on the WebTestBench benchmark: 36.7% vs 26.4% macro F1*
And calibrated, not trigger-happy: 6 criticals on a deliberately buggy app, 0 on a mature product, 2 real ones in between. The finding rate tracks reality.
FAQ
Questions, answered.
What does DeepQA test?+
The running application, not the code in isolation. Agents boot the app behind your PR or commit and test it through a real browser: flows, forms, edge cases, and regressions.
How do I trigger a Run?+
Like a GitHub Actions workflow: automatically on a pull request, or dispatched manually against any PR or any commit. Every Run records the exact SHA it tested and the PR when one exists.
What repos are supported?+
Node and Python fullstack apps that boot without external services. Connect a public GitHub repo and DeepQA takes it from PR to audited report.
Is my code kept?+
No. Each Run executes in an isolated sandbox that is destroyed when the Run finishes. Only the Run's artifacts (report, issues, screenshots) persist, and they stay private unless you publish them.
What if DeepQA cannot run our app?+
The Suitability Check reads the repository before anything boots. Stacks DeepQA cannot start, such as an app that needs external services it has no access to, are turned away in seconds, and a rejected Run costs nothing.
How is it priced?+
DeepQA is in early access, so we onboard teams directly with pricing matched to usage. Spend is not open-ended: every Run carries a budget cap you set, the Run hard-stops there, and live cost is visible while it runs.