How most teams hear about it
“Hi, the discount code said it was applied but I was charged the full price. Can someone look at this? I have had to cancel the order.”
Your team ships code faster than anyone can test it, and more of it is written with an agent every month. Sentiel is a QA agent that reads each change and the ticket behind it, tests it in a real browser, and checks the screen against the API and the database before it calls anything a pass. Every result comes with the evidence.
The way in is a bug hunt. Give us a staging URL and two test accounts, and read-only access to the repository if you can. Within a week you get every bug we found, each one read by an engineer before it reaches you. Nothing installed, nothing to write.
Two messages about the same broken release
“Hi, the discount code said it was applied but I was charged the full price. Can someone look at this? I have had to cancel the order.”
“Applying a discount code after changing the delivery address charges the original total. The screen shows the discount as applied; the order row in the database holds the full price. Found while testing the pull request that moved basket totals to the server. The steps, screenshots, the API response and the query result are attached.”
Writing code and reviewing pull requests are now largely automated. Checking that the product still works is the step that did not keep up, so it falls to whoever has time before a release, and to your customers after it.
Incidents per pull request, year on year.
Cortex · 2026 engineering benchmarkMore pull requests merged in teams using AI coding tools.
LinearB · 8.1M pull requestsOf developers name code that looks correct but is not reliable as a problem with AI output.
Sonar · State of Code 2026Your team merged a hundred and forty pull requests last month, most of them written partly by an agent. Somebody clicked through the app before each release. Your customers found the rest.
The bugs that reach users are rarely a typo a reviewer would spot. They are a logic error, an edge case nobody tried, two features that quietly stopped agreeing with each other. They show up when the software runs, not when someone reads the diff. That is where Sentiel looks.
Four steps. The third is the one that makes the rest worth reading.
Sentiel starts where a careful tester would: with what changed and why. It reads the pull request, the code it touches and the ticket behind it, works out what the change is meant to do and where it is most likely to break, and writes the test cases itself. Nobody on your team writes a test plan, a script or a list of flows.
## Case LC4: discount applied after the delivery address changes
- Preconditions: signed in as returning_customer, one item in the basket
- Verifier: mixed (browser, API, database)
- Risk: regression
- Steps:
1. Change the delivery address to a Highlands postcode
2. Apply code SAVE10 and continue to payment
3. Read the order row that was saved
- Expected result: the total on screen, in the API response and in
the saved order all include the discount and the new delivery fee
Status: pendingThe cases are plain text, so anyone on your team can read what was tested and correct one in a sentence. For each change it covers the intended path, the awkward inputs, the wrong user, and the neighbouring feature the change could have broken.
Sentiel runs the cases against your staging or preview environment in a real browser. It can stay signed in as several test accounts at once, so it checks what one customer can see of another's data as well as what each can do with their own. You start a run from a GitHub Action when a release is ready to be tested. If you want it tighter, a single feature can be tested as a step in your own pipeline, straight after it deploys.
It does not replace your unit tests or your code review. It covers the part neither of them sees: the product, running.
An agent that calls a green screen a pass, or raises every oddity as a bug, is worse than no agent. So a result only counts when there is a saved file that shows it, on the screen the case names, and the API and the database agree with what the screen said. Every case ends in one of three places.
Expected one thing, got another. Reported with the steps, the screenshot, the API response or the query result that shows the difference.
Every step done and every part of the expected result observed, with the evidence file named. A screen the database contradicts is a fail, not a pass.
Could not be tested, and why: a missing test account, a service that was down. Listed in the report, never counted as a pass.
If Sentiel cannot observe something, it says so and does not guess. While Sentiel is in pilot, a NodeNova engineer also reads every failure before it reaches your team.
Each run ends in a report: every case, its result, and the evidence behind it. Failures are filed as issues in Jira, Linear or the tracker your team already uses, written so a developer can start on the fix. The cases are kept and run again on later changes, so the same bug cannot come back quietly.
The same run can gate a release: your pipeline fails when a case fails or was never finished, and passes when all of them have evidence.
Every case kept at D runs again at C on later releases. Coverage grows from what your team actually changed, not from a guess about what might break.
A bug report is only useful if the person who picks it up can see the bug for themselves within a minute. This is what one holds. Every field is there because a developer needs it to start on the fix.
An example report. The fields are fixed. The values are whatever your release turned out to contain.
We do not claim to find every bug. Nobody testing a product from the outside can. We claim that every bug we report comes with the evidence, that you can follow the steps and see it yourself, and that we show you what we tested and what we could not.
Sentiel is new. We have no public benchmark to show you yet, and we will not quote a catch rate until we do. The numbers that matter first are the ones from your own app, and every bug hunt ends with them.
Test cases written and run across the areas we agreed to cover
IllustrativePassed, each with evidence on the screen, the API and the database
IllustrativeFailed: the bugs, each read by an engineer and reported
IllustrativeBlocked: what we could not test, and the reason for each
IllustrativeWhat comes next. Before we quote any rate, we will measure Sentiel on web applications with a history of real bugs, each replayed at the change that introduced it. The share of known bugs found and the share of reports that were real will be published here with the method, including the numbers that are not flattering.
Those need their own tools and people. Sentiel covers the gap between them: the product, running.
Sentiel is the verification stage of NodeNova's Agentic Pipeline, offered on its own. Start with testing alone: Sentiel only reads, and never changes your code or your data. When you are ready, the bugs it finds can go to the pipeline as tasks and come back as fixes that Sentiel tests again.
No integration, no procurement cycle, nothing installed.
You give us a staging URL and two test accounts. We propose the parts of the product worth testing first, you say yes or strike one out on a call, and Sentiel works through them for a week. You get a short report.
Sentiel on one application for six weeks: each release is tested when you say it is ready, failures are filed in your tracker with their evidence, and the cases build into a regression suite.
A staging URL and test accounts for the roles that matter. For the pilot, one GitHub Action added to your repository, which reads the code and starts a run when you ask, and read-only access to a staging database if you want stored data checked. That is the whole list: no SDK, no test scripts to write, no flows to document, and no write access to your code or your data. Setting it up is one call and about an hour of one engineer's time.
Monthly, with no annual contract: cancel when it stops paying for itself, and the test cases are yours to keep. Never priced per seat. Busier teams are priced on the call.
Sentiel is built by NodeNova, an engineering practice that delivers production systems for insurers, retailers and the UK public sector, self-hosted or air-gapped where the data requires it. NodeNova is the trading name of NOVA AI SW LIMITED, company number 16962401. ISO 27001:2022 aligned, Cyber Essentials certified.
Thirty minutes to walk through your product and how you release it, and to scope a bug hunt on your own staging environment.