Put the hardware in the loop and development moves at the speed the agent works. It flashes the build, walks the flow, reads what the product did, and goes again. That's the case for putting the real device inside the agent's loop.
It has a second half. A rig walks the flows it's handed, so what comes back is as good as what was asked for, and naming those flows, writing what walks them, and keeping them current as the product moves is a job of its own.
Call it flow validation.
So: why the flows, why every flow, and why the agents are the ones holding them.
Why the flows? A rig answers the question it was asked
A run answers one question: did this do what was expected of it. Ask about onboarding and the answer is about onboarding.
A rig is faithful that way. Hand it the onboarding flow and it walks onboarding, with the app on a real phone and the test cloud behind it, and it reports how the product behaved. Ask it nothing about what happens when a device is handed on to a second owner, and it stays quiet on that.
Speed makes the map worth more. An agent puts more product on the rig in a day than used to arrive there in a month, and each of those runs reports against the map it was given.
Why every flow? Writing them all down used to cost too much
Writing down what a product can be asked to do is the expensive part. Reading the product to enumerate its flows, writing the code that walks each one, and keeping all of it current as the product changes is a large and permanent job.
So teams did as much of it as they could afford, starting with what customers touch every day. Coverage stopped where the budget for it stopped.
The same bound applied to code people wrote by hand. Before anything can walk a flow, somebody has to write down what the flow is, and that step costs the same whoever wrote the code underneath it.
The price of that step is what changed. Enumerating what a product can be asked to do, writing what walks each flow, and keeping the whole set current is a large volume of careful, repetitive work against a system already written down in the code, which is the shape of work agents are good at. So the blank spots in a product that has been shipping for years are as reachable as the ones in code written this morning.
So the blank spots in a product that has been shipping for years are as reachable as the ones in code written this morning.
Take handing a device on to somebody else. The first owner removes it from their account and factory resets it while it's off the network, then the new owner opens the app and starts setup. Each part behaves the way it was built to: the device comes up advertising itself as new, the app runs the setup it runs for a fresh unit, and the cloud still holds the claim the first owner made. The new owner reaches the last screen and the device belongs to somebody else. Nothing was written to walk that, because walking it takes two accounts, a reset, and somebody's time on a flow most devices never go through.
What a product's coverage reached was set by what writing the flows down cost.
What a product's coverage reached was set by what writing the flows down cost.
The flow map is a specification agents can build against
A written-down flow states, in the team's own words, what the product owes the person using it. Unbox this one, and by the end it's on the network, in the account, and doing what it was bought for.
An agent reads the flow before it touches the code that serves it, and walks the flow as the change takes shape. The same document says what to build and says whether it works.
Agents do the enumerating and the writing. Which flows the coverage starts with, what the product should do at each step, and what a failing flow means for a release are calls the team makes, out of what customers ask for and where the bar sits.
How Groundrun runs the flows in the agents' loop
Groundrun puts the product on a rig and runs its flows from inside the loop where the agents work.
The devices you ship sit on a rig built around your product, with your app on real phones and your test cloud behind them, so a flow runs the way a customer's would. The flows come from the team: we map how your product is used, agree together where coverage starts, and grow it from there toward every flow your product runs.
The agents invoke a run through a command-line tool and read back what the run reported, in the session where the change is being written.
Every flow the team writes down is a flow the agents run.