When the Machines Started Speaking the Same Language

In the 1990s, a consortium of equipment manufacturers and agricultural engineering bodies began working through a problem that was holding precision agriculture back. Every manufacturer ran their own communication protocol for implement-tractor data. A John Deere tractor and a Hardi sprayer could not share a data language without custom integration. Getting information to travel reliably between machines from different manufacturers was expensive, fragile, and beyond most operations to maintain.

The solution was ISO 11783, better known as ISOBUS: a shared communication standard that any compliant manufacturer could build to, regardless of brand. Once an implement and a tractor both meet the standard, the data flows between them. The operator works with the whole system rather than managing the translation between the parts.

ISOBUS did not make any individual machine smarter. It made the relationship between machines possible.

That distinction, between improving a component and enabling a relationship, is what I've been thinking about since 22 April.

What happened at Google Cloud Next in Las Vegas

On 22 April, Google released a protocol called A2A (Agent-to-Agent) alongside a reference implementation called the Agent Gateway. The Gateway is described by Google as the "air traffic controller" for multi-agent operations: a layer that inspects, governs, and routes communication between AI agents, third-party tools, and data sources.

A2A is not a product. It is a proposed standard for how AI agents communicate with each other.

It launched with commitments from more than 50 technology partners: Atlassian, Salesforce, SAP, ServiceNow, Workday, LinkedIn, PayPal, and others. These are not fringe participants, they are the enterprise software stack that runs HR, procurement, finance, and operations at large organisations globally. When that group endorses a communication standard on day one, the announcement moves from proposal to infrastructure decision.

Whether A2A becomes that inflection point for intelligence systems remains to be seen. But the conditions that made ISOBUS consequential are present: a structural problem, a proposed standard, and enough of the ecosystem committed to building to it on day one.

For turf and sports facility operations, the parallel lands closer than the enterprise software framing might suggest, not at the AI agent level, which this industry has not yet reached, but at the data layer, which it is working through right now.

A well-equipped golf course or sports facility in 2026 runs a weather station on its own platform, a robotic mower fleet on a second, soil sensors on a third, an irrigation controller on a fourth. Spray records live somewhere else: a spreadsheet, a standalone app, or a paper log in the maintenance shed. In principle, some of this data could flow between systems. In practice, connecting them requires custom integration work, ongoing maintenance, and depends on vendors who have limited commercial incentive to make their competitors' data more useful. The superintendent remains the integration layer, not between AI agents, but between data platforms.

This is not the AI agent problem. Turf management has not yet deployed AI agents in the way enterprise software has. The industry is working through an earlier and more immediate challenge: getting the IoT data layer to talk to itself. But the structural problem is identical to what A2A is designed to prevent at the agent level. Proprietary silos. Incompatible data formats. No agreed standard for how the parts communicate. The person standing between them doing the translation.

The production problem

Alongside the A2A announcement, Gartner published a figure that has been circulating in the AI industry: 86–89% of AI agent pilot programmes have not reached production at scale.

That number tends to be read as a commentary on AI readiness, as if the technology is not yet reliable enough. I think it describes something more structural: a fragmentation problem. Most enterprise AI pilots that fail in production do so not because the reasoning was wrong, but because the output of one system has no standard mechanism to hand off to the next. No shared protocol. No agreed format. Someone has to mediate the transfer manually, on a schedule, with the information arriving too late to be useful.

Turf operations will recognise the shape of this problem, even if the technology layer is different. A weather platform that cannot export directly into a nutrition planning tool. A soil sensor dashboard with no native connection to the irrigation controller. A spray log that exists in a separate environment from the disease risk model that should be reading it. The architecture problem is the same. The layer at which it appears is different.

The shape of this problem is familiar from precision agriculture's own experience a decade ago. The sensors worked. The machines worked. The data formats were incompatible. The operator was the integration layer.

The ISOBUS transition did not happen because the machines improved. It happened because the industry agreed on a grammar, and once that grammar existed, every new implement could participate in it without requiring a bespoke integration.

A2A is proposing the same grammar for AI agents. Not a shared model, not a shared platform, but a shared protocol. The distinction matters, because it means agents can come from different providers, run on different underlying models, and still communicate within a governed architecture.

The question this creates for operations

For a director of agronomy or a head of operations evaluating technology, the relevant version of the A2A question is not yet about AI agents. It is about data.

Does this platform connect to the other platforms in my operation, or does it create another silo? Does it export data in open formats, or does it lock my operational records (spray logs, soil readings, growth data) inside a proprietary environment? Can I move my data if I change vendors, or have I handed over control of it along with the contract?

These are the questions the turf industry is working through now, at the data and API layer. A2A is the same question being settled one level above in enterprise software: when AI agents become the primary interface, will they communicate via open standards, or will each vendor build walls around their agents the way equipment manufacturers once built walls around their implement protocols?

The two questions are related. The architecture decisions made at the data layer now will determine how easily an intelligence layer can be built on top later. A platform that locks your operational records into a proprietary database is creating, one layer up, the same constraint as a pre-ISOBUS implement manufacturer. The retrofitting cost arrives later, when switching has become expensive and the data is harder to move.

Pre-ISOBUS, equipment manufacturers had commercial reasons to keep their protocols proprietary. A locked communication standard meant locked customers. The move to open standards was resisted, then gradually adopted, then became the prerequisite for market participation. The same dynamic is running now in AI infrastructure, and in the agronomic data platforms that will sit beneath it.

The practical test applies at both layers: can the platforms you are running share data with each other without your team mediating the transfer? If not, if the superintendent is still the connection between the weather station, the soil sensor, and the spray record, you have capable components. You do not yet have a system. And you are building on foundations that will constrain every intelligence layer that follows.

Why this is worth paying attention to now

Protocol decisions rarely make headlines. They are settled in working groups and technical committees, announced in press releases that most practitioners never read. They are, consistently, the decisions that determine what the next decade of innovation makes possible.

But the lesson from ISOBUS, and from every comparable standards moment in precision agriculture, is that the protocol decision is the one that shapes everything built on top of it. The implements designed before ISOBUS required expensive retrofits or replacement. The implements designed after could participate in a connected ecosystem from day one.

The intelligence layer in your operation: the ability to connect a weather reading to a soil condition to a spray decision to an observed outcome. It will be built on infrastructure decisions being made now. Which platforms you commit to. Whether your operational data is yours to move or locked to a vendor. Whether the architecture you are building today leaves room for a connected intelligence layer, or forecloses it.

A2A will not land in the turf trade press. It does not describe where this industry currently is. But it describes, precisely, the architecture problem that every layer of operational technology eventually has to solve. It carries the lesson ISOBUS already delivered once: get the protocol right before the ecosystem locks in around the wrong one.

The question worth asking now is not "which tool gives the best data?" It is: when the intelligence layer arrives, will your operation be ready to participate in it, or will you be spending the next three years on retrofits?

Reference: The A2A Protocol and Agent Gateway were announced at Google Cloud Next '26, Las Vegas, 22 April 2026. Sources: Google Cloud Next '26 overview · [Kai Waehner, Enterprise Agentic AI Landscape 2026