A connected product team already tests at several levels. Developers keep thorough unit tests on each module, the team runs full-system scenarios that walk a real device through a real flow, and a quality assurance (QA) function does the final pass before a release reaches customers. Each level answers a different question, and together they are how a working product ships.
When AI agents produce changes across firmware, app, and cloud, every one of those changes needs an answer at each level, and it needs the answer as the change is made. An in-loop validator runs the checks that prove a change from inside the loop where the agent works: a single unit test, an integration test, a full-system scenario on real hardware. Because it has to reach across that whole range, the same setup that gives agents fast feedback runs the tests your team already owns, on every change.
To prove an agent's change in the loop, the validator reaches from a single unit test up to a full-system scenario on real hardware, because any of those levels can be where the change went wrong.
To prove an agent's change in the loop, the validator reaches from a single unit test up to a full-system scenario on real hardware, because any of those levels can be where the change went wrong.
What does an in-loop validator have to cover?
Everything from the smallest unit test to a full-system 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 appear in their account. The validator running in the agent's loop has to exercise all of it, because the agent needs to know which level moved. That breadth is why an in-loop validator spans the same ground your whole testing organization spans, from the unit tests developers run in seconds to the release scenarios QA walks by hand.
| What this level proves | In the agents' loop | |
|---|---|---|
| Unit tests | Each module behaves on its own | Run on every change, in seconds |
| Full-system scenarios | The whole flow works on real hardware | Run on every change, on the rig |
| QA release pass | The product is ready for customers | Opens from a verified baseline |
How does it strengthen the unit tests you already run?
The unit tests run continuously, as part of every change the agent makes. Developers already run these in the loop, and that habit is the model for the rest of the stack. In-loop validation extends the same immediacy upward: the unit tests fire on every change the way they always did, and the integration and full-system checks now fire beside them, 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.
What happens to your full-system scenario tests?
They move from an occasional event to something that runs on every change. Full-system scenarios are the hardest 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 and in a dedicated environment. In the loop, those same scenarios run on every change, on the rig, against the current app and cloud. The onboarding flow, the over-the-air (OTA) update, the recovery path: each one runs within minutes of the change that touched it, at the change that touched it. The scenario your team built for the release now works for every change in between.
What does your QA team do when the matrix is already proven?
The release pass starts from a product that has already proven every scripted flow, so QA's judgment reaches the questions only a person can answer. A release pass does two things: it re-runs the known matrix of flows and combinations, and it explores, probing the new and the ambiguous the way a customer might. When in-loop validation has run the scripted matrix continuously, on every change since the last release, the final pass opens from a verified baseline, and the team's expertise goes to the exploratory work that finds what no script anticipated.
Confidence that accumulates at every level
Adopting in-loop validation is usually framed as a way to keep agents fast, and it is: the does-it-work answer returns in minutes, so the team ships at the pace the agents write. It earns its keep a second way too. The same setup that keeps agents fast runs every level of testing your team already relies on, continuously, on every change.
The same setup that keeps agents fast runs every level of testing your team already relies on, continuously, on every change.
Confidence in the product accumulates at every level instead of getting assembled at release time. The unit tests confirm each module continuously, the full-system scenarios confirm the flows continuously, and the QA pass opens from a product that has already demonstrated itself top to bottom. When the question is whether to hand more of the work to agents, the answer rests on the same foundation: a product that proves itself, at every level, on every change.
The placement is what does the work: in-loop validation on real hardware is where the reliability, the speed, and the confidence come from.
Groundrun runs the cross-domain scenarios from inside your agents' loop, so every change arrives proven across firmware, app, and cloud. See the platform.