A connected product team already tests at several levels. There are unit tests on each module, full-system scenarios that walk a real device through a real flow, and a final quality assurance pass before a release reaches customers.
Each level answers a different question. Together, they are how a working product ships.
Now let AI agents write the changes. When an agent changes something across firmware, app, and cloud, that change needs an answer at each of those levels, and it needs the answer while the work is still fresh, not the next morning.
That is what an in-loop validator does: it runs the checks that verify a change from inside the loop where the agent works, from a single unit test up to a full-system scenario on the real device.
And here is the part that is easy to miss. Because the validator has to reach across that whole range, it ends up running the tests your team already owns. All of them, as the work lands.
Because the validator has to reach across that whole range, it ends up running the tests your team already owns, as the work lands.
What does an in-loop validator have to cover?
Everything, from the smallest unit test to a full flow on real hardware. A change that spans firmware, app, and cloud can break at any altitude: a helper function that now returns the wrong value, an interface between two modules, or the end-to-end flow where a customer pairs the device and watches it show up in their account.
The agent needs to know which level moved. So the validator has to exercise all of them.
That is why an in-loop validator covers the same ground your whole testing organization covers, from the unit tests a developer runs in seconds to the release scenarios QA walks by hand.
| What this level checks | In the agents' loop | |
|---|---|---|
| Unit tests | Each module behaves on its own | Run as you go, in seconds |
| Full-system scenarios | The whole flow works on real hardware | Run as you go, on the rig |
| QA release pass | The product is ready for customers | Opens from a verified baseline |
What does it do to the unit tests we already run?
Not much, and that is the point. Developers already run unit tests in the loop, as they work, and that habit is the model for the rest of the stack.
So the unit tests fire the way they always did, in the loop. What changes is what fires beside them: the integration checks and the full-system scenarios now run at the same moment, on real hardware.
The fast feedback a developer gets from a unit test becomes the feedback the agent gets at every level. And in the loop, that feedback does more than check the work.
It shapes where the agent goes next: run the flow, see where it broke, fix that, run it again. The test is how the agent steers, not a gate it clears at the end.
What happens to the full-system scenarios?
They stop being an occasional event. Full-system scenarios are the hardest tests to run, because they need real hardware, a real app build, and a live cloud. So most teams run them at a few points in a release, in a dedicated environment, and not much in between.
In the loop, those same scenarios run as the work lands, on the rig, against the current app and cloud. The onboarding flow, the over-the-air update, the recovery path: each one runs close to the change that touched it, while the agent is still on that part of the work.
The scenario your team built for the release now runs through the whole run-up to it, not just at the end.
What does QA do when the matrix is already green?
The interesting work. A release pass does two things: it re-runs the known matrix of flows and combinations, and it explores, poking at the new and the ambiguous the way a customer might.
The first part is scripted. The second part is judgment, and only a person can do it.
When in-loop validation has run the scripted matrix continuously since the last release, the final pass opens from a product that has already checked itself top to bottom. So the team's time goes to the exploratory work that finds what no script anticipated.
Conclusion
In-loop validation is usually sold as a way to keep agents fast, and it is: the does-it-work answer comes back in minutes, so the team ships at the pace the agents write.
But it earns its keep a second way. The same setup that keeps the agents fast runs every level of testing the team already relies on, continuously, through development.
The same setup that keeps the agents fast runs every level of testing the team already relies on, continuously, through development.
So the confidence in the product accumulates as you go, instead of getting assembled at release time. The unit tests confirm each module, the scenarios confirm the flows, and the QA pass opens from a product that has already demonstrated itself.
A product that checks itself at every level, as it is built, is a product you can hand more of to the agents.
None of it works without the placement. It only happens because the validation runs on real hardware, inside the loop where the agent works.
See how Groundrun runs every level of your testing from inside your agents' loop on the platform overview.