Skip to content

TECHNICAL PREVIEW · IN ACTIVE DEVELOPMENT

ALL NOTES

DEPLOYMENTS

Seasonal fleets and the field boundary

Agriculture breaks two assumptions the other environments share. The work happens in a short annual window rather than shift after shift, and the boundary that compute is supposed to stay inside is a field rather than a building.

· 8 min read

Agriculture inverts two assumptions that every other robotics environment quietly shares. The first is that the work is continuous — that there is a shift today, another tomorrow, and a floor that runs most weeks of the year. The second is that the site has an inside. Both are false here, and each one alone would be enough to change the architecture.

A field operation runs against a window. Ground opens, a crop reaches a stage, weather cooperates, and for a stretch the fleet works as hard as it can. Then the window closes and the machines sit. Everything an operator will learn about whether a system was worth having is learned in that stretch, and the stretch does not come back for a year.

Meanwhile the place the work happens has no walls. There are property lines, some of them around ground that is rented and may belong to someone else's operation next year. There is a home place with a shop and a shed. Between them is acreage. Any statement about compute staying inside a boundary has to survive the fact that the boundary here is a legal and operational idea rather than a physical one.

A season is not a shift

The overnight rhythm that suits an industrial site — work the shift, adapt on the day's data, start tomorrow better — assumes there is a tomorrow. In a seasonal operation there may not be one for most of the year, and the calendar rearranges what adaptation has to mean.

Start with the deadline, because it is unlike the deadlines elsewhere. A production line stops against a contract, and a contract can in principle be renegotiated or made up with an added shift. A crop does not wait. A window missed because a system was still learning is not recoverable later in the year. That turns tolerance for a slow start from a commercial preference into a hard requirement: a system that needs a long history of local data before it works well is not slow, it is useless in an operation that gets a few weeks a year to prove itself.

Then there is drift inside the window. Conditions at the beginning and the end of a working period differ materially — crop stage, canopy density, ground condition, day length, and the machine's own configuration as the operation moves between blocks. Data gathered in the first days is partly stale by the last. Adaptation has to run on a cycle short enough to track that, which is a different design point from adapting to a building whose long-run behavior is roughly stable.

Across years the picture is looser still. The same window returns with different varieties, different weather, and sometimes different equipment, so last season's local data is relevant only uncertainly. A system that treats site-specific learning as a monotonic accumulation is modelling the wrong process.

There is no building

The absence of a structure changes the practical questions immediately. Where does a plane physically live? The candidates are a shed or shop at the home place, which has real power and a roof and is often a long way from where the machines are working, or something that moves with the operation — compute in a trailer or on a support vehicle, staged near the block being worked and relocated as the operation moves.

Both are defensible and neither resembles a facility. A shop is not conditioned space, and a trailer parked at a field edge overnight is a weaker position than any locked room. The physical-security argument here has to rest on the node proving what it is rather than on where it was parked.

Connectivity across acreage deserves plain language: it is not patchy, it is frequently absent. Cellular coverage follows population, and fields do not have any. Terrain, tree lines, and distance take care of the rest. Satellite service exists and is useful for moving small things on a slow schedule, but nothing about it makes a link a machine can depend on.

That produces a consequence specific to this archetype. In a warehouse or a plant, a machine and its plane are on the same local network, and coordination in local time is available by construction. Here, a machine working a distant block may be out of contact with the operation's own compute for the length of a pass. The plane is less a live coordinator than a base the fleet reconciles with when it comes back — which means autonomy on the machine is not a fallback mode, it is the normal condition, and anything the plane does has to be useful on that cadence.

An enclosure problem before a compute problem

The environment attacks hardware in ways that decide the design before any question about accelerators comes up. Dust is pervasive, fine, and abrasive, and it becomes conductive when damp. Filters clog, and a machine whose cooling depends on airflow through a filter has a performance curve that tracks how dirty the air is. Sealed, conduction-cooled construction is the right instinct here, and it fights sustained inference load. That tension is not resolved.

Mud and washdown follow. Equipment gets pressure washed, sometimes with the compute still mounted. Vibration is continuous and severe on rough ground, and vibration takes out connectors, storage, and thermal interfaces long before it troubles silicon. Temperature swings run from a closed cab in direct sun to freezing nights at the shoulders of a season, and every swing is an opportunity for condensation inside an enclosure.

Power is the constraint that catches people last. When the compute rides a vehicle, its budget comes out of the machine's electrical system, and that system was sized for the machine's job. On a combustion platform, running an engine to feed compute burns fuel; on a battery-electric platform, every watt spent on inference is a watt not spent on working time. The perception budget is therefore set by the machine's power economy rather than by what hardware is available, which is a different sizing exercise from the one a facility does.

The subject is alive and the light is the sky

Perception in agriculture is harder than in most industrial settings for reasons that do not go away with better models. The subject is biological. Every instance of it differs, it changes appearance week over week as it grows, it occludes itself, and it moves in the wind. There is no part number and no nominal geometry to compare against — only a distribution that shifts through the season.

The illumination is the sky, and nobody controls it. Direct sun, overcast, dust plumes behind a machine, long shadows at the ends of the day, and headlights at night are all working conditions rather than exceptions. Localization is harder too: no walls, no fiducials, no fixed floor plan, and a landscape whose visual features are the crop and therefore change as the crop does.

The variance a model has to cover here is unusually wide, and much of it is specific to this ground, these varieties, and this operation's practices. That is precisely the data that exists nowhere else, and it is generated in a short window by machines that may be out of contact while they generate it.

Whose data the yield map is

Agronomic data is commercially sensitive in a direct way. Yield by location, input rates and timing, ground that underperforms, practices that work — this is the operating record of the business, and it bears on land values, rent negotiations, input purchasing, and marketing decisions. An operator who would not hand a competitor the field notebook has a clear view of what the equivalent digital record is worth.

What makes this archetype different from the others is that the ownership question has already been fought over publicly. Agricultural operators have spent years arguing with platform providers about who owns machine-generated agronomic data, what a provider may do with it in aggregate, and whether the aggregate can be sold back to the people who produced it. Whatever one thinks of the merits, the effect is that operators read data terms carefully and start from suspicion. Assurances about access controls do not settle it, because the question is not who may look but who holds the copy.

That is an argument for architecture over policy. A system with no path for operational data to leave does not require the operator to trust a clause, and it does not become a different system when the vendor's terms change.

What the window demands

The design consequence for this archetype is a fleet whose intelligence is genuinely self-contained. Edge nodes carry full autonomy for the length of a pass, with contact treated as an occasional benefit rather than an assumption. The plane lives where the operation does — a shop, a shed, a trailer that moves with the work — and does the heavy inference, the reconciliation, and the adaptation that machines cannot do while working. The operator's agronomic record stays with the operator, because the system was not built with anywhere to send it.

The honest difficulty is the first season. A short window puts unusual pressure on how much site-specific adaptation a system needs before it earns its place, and the answer cannot be a season of local data. How much capability can arrive as a signed prior that generalizes across ground, and how much has to be learned on this operation's own dirt, is an open question, for us and for everyone else building this kind of system. It is the question that decides whether a system like this is useful in its first window or only in its second.

DESIGN PARTNER PROGRAM

Build this with us.

We are working with a small number of teams operating real fleets in constrained environments. If the cloud is not an option where your machines work, we want to talk.