Inside the Farm Agent
What is actually running next to the phones?
Three independent loops, one wire protocol, and a single interface that separates "what to do in an app" from "how to press a button".
Drag to pan, scroll to zoom, click an element to trace it.
Open full screenWhat to look for
- The three loops leaving FarmAgent, and the fact that they are drawn as separate paths.
- The three driver implementations: one shipping today, two named as work to come.
- The tag "no coordinates" on the scenario engine — that is a design rule, not a description.
Read the full explanation
The agent keeps three loops running at once and they do not block each other: a heartbeat every twenty seconds so the Control Plane knows it is alive, a device sync every thirty seconds so the fleet list stays current, and a lease poll every five seconds asking for work. A slow device sync can never stall job pickup.
Everything the agent says or hears goes through one ContractClient, which validates the message in both directions against the contract schema. A malformed response from the server fails immediately and loudly at the boundary instead of corrupting state three layers deeper.
When a job is leased, the JobRunner owns it from start to finish, and there is a rule it never breaks: every exit path ends in exactly one terminal call — succeeded, failed, needs-attention, or released. The Control Plane is therefore never left holding a lease on a job the agent quietly abandoned.
The line marked "the seam" is the most important thing in this diagram. Above it, scenarios describe work in semantic steps — open the app, enter a caption, select media, publish. Below it, a driver knows about coordinates, selectors and ADB. Adding real Android support means writing one class beneath that line; nothing above it changes.
Anyone who will extend the agent, or wants to know what real-device support costs.