Every change to a connected product has to answer one question: does the whole product still work? The firmware passes its tests, the app passes its own, the cloud deploys green. And the flow a customer actually walks through, unboxing the device, pairing it, watching it show up in their account, crosses all three and answers to none of them.
Where that question gets answered decides three things: how reliably the product ships, how fast the team moves, and how much anyone trusts the result.
In-loop validation puts the answer inside the loop where the work happens. The scenarios that verify a connected product's flows run from where each change is made: AI agents run them on real hardware, across firmware, app, and cloud, and read the results as they work. Engineers decide what has to be validated.
The scenarios are nothing new. The placement is the whole point.
What does in-loop validation mean for a connected product?
A cross-domain scenario can run in two places.
Run it after the work is finished, and it inspects a change whose author has already moved on. A failure opens an investigation.
Run it inside the loop, and the same scenario becomes part of how the change is made. An agent reworking the firmware's pairing flow flashes its build to a test device, walks the pairing scenario against the current app and a staging cloud, reads the failure at the step that caused it, and fixes it while the whole context is still in front of it.
Same scenario. Different position in the workflow. That position is the difference.
For connected products, the position carries more weight than it does anywhere else in software. The correctness of a change lives in what a physical device does next: whether the radio still advertises in a format the app recognizes, whether telemetry still lands in the customer's account, whether an update sent over the air leaves the device reachable. None of that shows up in the code the agent is editing. So the physical answer has to arrive inside the loop, not days downstream of it.
How does in-loop validation improve reliability?
Every failure surfaces at the step that produced it, while the cause is still on the workbench.
A change that spans firmware, app, and cloud takes shape over many steps. Validate each step as the agent works, and no step builds on an unverified base. The alternative arrives all at once: a finished change fails somewhere in a flow, and the failing step, the edit that caused it, and the author's context all have to be reassembled before the fix can start.
By the time a release goes out, the onboarding flow has already run hundreds of times that month, against every combination of changes the team produced.
The other reliability effect is sheer exercise. When agents run the critical flows as they work, the product's most important moments get rehearsed over and over, on real hardware. By the time a release goes out, the onboarding flow has already run hundreds of times that month, against every combination of changes the team produced.
A renamed cloud field, a reflowed app screen, a timing shift in the firmware: each one meets the flows it affects within minutes of existing. Reliability stops being something the team inspects for at the end. It accumulates from the way every change got made.
Why does development speed follow the placement?
Agents produce changes that span firmware, app, and cloud in minutes to hours, and every one of them needs the does-it-work answer before it can ship. Whatever produces that answer sets the team's speed.
When the answer comes from a pass scheduled after the work, shipping moves in days, however fast the code got written. Returned from inside the loop, the answer comes back in minutes, and the team's speed stays the agents' speed.
| Validation inside the loop | Validation after the work | |
|---|---|---|
| Feedback on a change | Minutes, in the working session | Days, in a queue |
| A failure lands | At the step that caused it, context fresh | As an investigation, context rebuilt |
| Review receives | A change already validated on the product | A change still waiting for validation |
| Confidence lives | Attached to every change | Reconstructed at release time |
The speed compounds through context. Feedback that arrives while the agent is still working gets acted on in the same session, at the cost of one more iteration. Teams that validate in the loop see most agent changes arrive verified on the first try, which turns agent output straight into shipped features instead of rework.
Why is confidence in the result the part that matters most?
Reliability can be measured and speed can be clocked. Confidence is the one people act on.
Release cadence, which changes go out this week, how much of the product's development the team hands to agents: every one of those is set by what the team trusts. A team ships at the speed it trusts, not the speed it can build at, and speed without confidence gets quietly surrendered, one deferred release at a time.
A team ships at the speed it trusts, not the speed it can build at, and speed without confidence gets quietly surrendered, one deferred release at a time.
For a connected product, trust in a change has one durable source: the product itself, running the flow, on real hardware, against the current app and cloud. In-loop validation attaches that answer to every change, so what reaches review has already demonstrated itself on the product. Confidence becomes something each change carries, not a judgment reconstructed at release time. When the question is "can we ship Thursday?", the answer is the record of every flow the changes ran through since the last release.
That confidence feeds back into the other two. Teams extend agents exactly as far as they trust the verification behind them, so every flow validated in the loop widens what the agents can be handed next.
None of it works without the placement. Validation against the real product, inside the loop, is what makes agent-driven development of connected products work: the product verifies itself as it is built, changes ship at the pace they are written, and the team trusts every release because every change arrived carrying its own proof.
Explore how Groundrun runs cross-domain scenarios from inside your agents' loop: platform overview.