Why Agriculture Needs Shared Infrastructure, Not Just More Digital Tools

There is no shortage of digital tools in agriculture. The challenge is that most were built for specific workflows, mandates, and markets, without enough shared standards to help them coordinate.

That fragmentation was central to Speedykom’s work with GIZ around AgStack, a Linux Foundation project linked to DIASCA’s work on digital integration in agricultural supply chains. What stood out in the work was how often people agreed on the problem, even when they came at it from different parts of the sector.

The pattern is easy to see in coffee supply chains. A farm boundary may be captured for certification, checked again for buyer due diligence, and requested again for regulatory due diligence. Same land, same people, different systems. In the first mile, this is even harder because coffee may pass through intermediaries before it reaches an exporter or formal aggregation point.

This isn’t just a technical integration problem. Farms, plots, and supply-chain relationships are not abstract data points. They are physical, changing, and often sensitive. Any shared digital foundation has to work with that reality if it is going to be trusted and used.

An economist would call this inefficiency. That is true, but it misses the point. The cost of all this duplication often falls hardest on the farmer, because access to markets and services depends on data they are asked to hand over but do not control.

The Missing Layer Is Underneath

Agriculture already has platforms, registries, buyer systems, certification tools, and farm-management software. What is missing is the layer underneath: shared infrastructure that helps existing systems refer to the same farms, plots, and evidence without forcing everyone into one application or one owner model.

Just as DNS helped the internet scale through shared rules for naming and resolution, AgStack’s Asset Registry applies a similar pattern to farms, plots, and other agricultural spatial assets. The aim is to let different systems coordinate around the same farm or plot reference, while governance and permissions define what can be seen, shared, or used.

This is where federation becomes important. A single global database of farms would be impractical, difficult to govern, and unlikely to fit the way agricultural data is actually held. Different countries, implementers, and trusted operators will not all play the same role. Some may host data, verify records, manage access, or set rules. They still need enough common standards for the wider system to work.

This is also the basic logic behind data spaces: not one database where everyone gives up control, but a shared set of rules that makes controlled exchange possible between actors who hold different responsibilities, permissions, and pieces of evidence.

The Asset Registry is one part of that wider picture. AgStack is broader: its role is to support open building blocks, specifications, reference implementations, and governance patterns that others can use in real agricultural workflows. For that role to work, the shared layer has to be trusted by actors who do not all share the same incentives.

Why Neutrality Matters

A shared layer only works if different actors are willing to depend on it. Buyers can keep their own systems. Governments can keep their own rules. Technology providers can build services. But the common infrastructure underneath has to remain neutral.

If it looks captured by one actor, others will hesitate. A rival buyer will not want to build on infrastructure owned by a competitor. A government will not want another country setting the terms for agricultural data. A software company will not want to build around a base that could later become closed. Farmers also need confidence about how their data is governed and who benefits from it.

That is the practical case for neutrality. It keeps the shared foundation from becoming a control point.

It also makes the commercial case clearer. Open source is not anti-commercial. Mature open-source infrastructure is often supported by companies that benefit from a common base. They do not need to own that base to build profitable services from it. They can make money by implementing it, hosting it, supporting users, building applications on top of it, or helping organisations use it well.

This is where AgStack’s place under the Linux Foundation matters. A shared agricultural layer needs to be trusted as neutral infrastructure, not seen as one company’s product or one actor’s control point. Linux is a useful example because most people never see it directly, but still rely on it through phones, cloud services, servers, and public systems. It became valuable because others could inspect it, trust it, and build on it.

AgStack’s role is similar: not to become the next platform in agriculture, but to make the neutral foundation strong enough for the platforms already there to work together.

Regulation Opens the Door

Regulation is one reason this now feels urgent. EU Deforestation Regulation (EUDR) has made plot-level geolocation, traceability, and due diligence a practical problem for supply chains. Carbon Removals and Carbon Farming Regulation (CRCF) points in a similar direction for carbon farming and removals, where claims need trusted data, monitoring, and verification.

But framing AgStack as a compliance tool is too limiting. The stronger point is that the same foundation the sector needs for today’s regulations can also help it absorb the ones coming next.

That matters because regulation can create pressure, but it rarely creates lasting adoption on its own. People stay involved when the shared layer helps with something they already care about:

• Lower risk
• Lower cost
• Better evidence
• Faster service delivery
• A clearer route to market

Who Pays, and What Keeps Working

The sustainability question should follow the value, not only the origin of the data.

Farmers may not pay for each system directly. But the cost still reaches them through repeated data collection, paperwork, delays, or reduced access to markets and services when the evidence attached to their farm is fragmented or hard to reuse.

That means being specific about who benefits. In one workflow, the saving may sit with a buyer reducing duplicate mapping. In another, it may sit with a lender using trusted consented data, a public programme lowering delivery friction, or a certifier improving assurance.

The business model should not quietly land on the farmer just because the data begins at farm level.

There is also a continuity question. If a node, implementer, funder, or service provider changes, a farm reference should still resolve, permissions should still be understood, and the system should not depend on one project team staying in place.

Identifiers, permissions, versioning, handover, and governance cannot be afterthoughts. They are part of what makes shared infrastructure dependable.

Proof Has to Work in a Real Workflow

This is why proof matters more than a feature list.

A useful proof point does not need to prove everything at once. It should take one workflow people already care about and show where the shared layer reduces friction.

A coffee sourcing workflow, for example, could show whether the same farm reference can support buyer due diligence, certification evidence, and regulatory checks without asking everyone to start again.

The test is practical:

• Can the same farm or plot be referenced across systems without exposing more data than needed?
• Can existing registries, buyer systems, and service tools connect through clear interfaces?
• Can local rules and permissions carry through?
• Is the value visible to someone beyond the project team?

Once those answers are clear, the story becomes easier to tell. It is no longer abstract digital public infrastructure. It is a specific problem, a shared foundation, a working example, and a reason for each actor to participate.

The Lesson

Agriculture already has many digital systems, and AI is likely to make that grow faster as software becomes easier to build. The harder problem is coordination: helping those systems recognise the same farms, plots, evidence, and permissions without forcing the sector into one platform or one owner model.

That is why AgStack is interesting.

Open source, federation, and controlled exchange are not three separate preferences. They are one answer to the same problem: how to let fragmented systems coordinate in a way people can trust.

The test now is whether that foundation can become clear enough, trusted enough, and useful enough for real workflows.

The harder work is not building another system. It is making the ones we already have work together under shared rules.

That is the kind of problem Speedykom works on: turning fragmented data, governed exchange, and coordination across institutions into practical implementation, in agriculture and other sectors.