Same engine, different context. Fundamentally different constraint.
A loose component sits on the bench with no machine around it. Connection is direct to the component's bus pins. The simulation makes the component believe a machine is there.
An assembled machine sits in the field. Connection is through the machine's existing diagnostic port. Access is to the machine's CAN network, not to the component directly.
The field tool is not a port of the bench tool. It is closer to what Jaltest AGV already does, plus the corpus. We position it that way, honestly, because the truth is better than the alternative: a bench technician using a field tool in the wrong context and trusting it.
A tablet that needs connectivity is useless in a field in Nebraska. That means a local model, a cached corpus subset relevant to the technician's expected work, and reconciliation with the command center when connectivity returns. This is an extra-large feature and it is not optional.
The moment a dealer's technician uses the tool, dealer data isolation, seat licensing, and entitlement enforcement all become required. These are not features to add later. Do not build them until the internal tool is proven and the commercial model is settled. Premature multi-tenancy is how simple tools become complicated products that nobody adopts.
You named this sequence yourself in our conversation. It is exactly right, and it shapes the build order.
Your own field teams use it first. The corpus is proven, the bench is running, and your technicians know the tool before anyone outside the company touches it.
Dealer technicians access the tool under existing dealer relationships. Data isolation per dealer organization. This is where licensing and metering become real requirements.
After dealer success is demonstrated and the commercial model is settled. Not before. A farmer who contacts your call center with a field problem is a different engagement than a trained dealer technician.
Jaltest AGV does multi-brand agricultural diagnostics well. It talks to assembled machines through the diagnostic port. Fault codes, live data, guided troubleshooting. It does this for dozens of ag brands.
It does not have 34 years of Ag Express failure knowledge behind it. It does not know how the Case IH FM-750 display fails at 8,000 hours in a wet season in Iowa. It does not know which failures look like a bad module but are actually a pinout issue on the harness connector. Jaltest knows the machine. Ag Express knows the failure.
The field tool with the corpus behind it is a different product from Jaltest with a better interface. The corpus is why it is different, and the corpus is why nobody else can build it.