Geospatial Foundation Models for Agricultural Machine Learning

How Prithvi, Clay, and AlphaEarth Are Rewriting the Labeled-Data Economics of Precision Agriculture


The first article in this series argued that the engineering of an agricultural ML stack is dominated by data scarcity at the labeled end: yield monitors are noisy, on-farm trials are slow, hand-annotated weed masks cost $5–15 per image, and a single field-year produces one yield observation that won’t be ground-truthed for another six months. Every architectural choice — feature engineering, spatial-temporal cross-validation, hierarchical Bayesian pooling — exists in some form to do more with less.

Foundation models change the economics of that constraint. The premise is straightforward: pretrain a large vision transformer on hundreds of millions of unlabeled satellite chips, then fine-tune on the (small) labeled agricultural dataset that’s actually available. The expensive labeled-data step shrinks, sometimes by an order of magnitude, and the resulting model often outperforms specialized architectures trained from scratch.

That’s the marketing claim. The reality in 2026 is more nuanced — and more interesting. This piece walks through the three production-ready geospatial foundation models that matter (Prithvi-EO-2.0, Clay v1.5, AlphaEarth Foundations), the two deployment patterns they enable, the actual numbers from published agricultural benchmarks, working code for fine-tuning and embedding extraction, and the honest set of cases where these models still don’t help.

1. What a Geospatial Foundation Model Actually Is

The geospatial foundation model (GFM) lineage descends from masked autoencoder (MAE) pretraining of vision transformers, adapted to satellite imagery’s quirks — many spectral bands, multiple sensors, irregular temporal cadence, georeferenced inputs.

The pretraining objective is reconstruction. A satellite image cube is split into 3D patches (time × height × width), a large fraction of patches is masked, and the model is trained to reconstruct the missing pixels. Formally:

Pretraining loss (MAE-style):

L = (1 / |M|) * sum_{p in M}  || x_p  -  decoder( encoder( x_visible ) )_p ||^2

where:
  x           = input image cube (T x H x W x C), surface reflectance
  M           = set of masked patch indices (typically 50-75% of patches)
  x_visible   = the unmasked patches fed to the encoder
  encoder     = ViT that produces patch embeddings
  decoder     = lightweight ViT that reconstructs masked pixels

After pretraining, the decoder is typically discarded and the encoder is used as a feature extractor: feed in a satellite image cube, get out a sequence of patch embeddings that can be pooled or decoded for a downstream task. The objective forces the encoder to learn rich representations of land surface, phenology, and texture without any labels.

Three modifications distinguish geospatial MAEs from their natural-image ancestors (MAE, SimMIM):

3D patch embeddings for spatiotemporal inputs. A standard ViT splits an image into 2D patches; a GFM splits a temporal stack of multispectral images into 3D patches of size (t, h, w). Prithvi-EO-2.0 uses 3D convolutional patch projection followed by 3D sin/cos positional encoding. This lets the encoder attend across time directly — important because phenology (the seasonal trajectory of NDVI, biomass, canopy structure) is the single most informative signal for most crop tasks.

Multi-sensor band handling. Different satellite sensors have different band counts and wavelengths. Sentinel-2 has 13 bands; Landsat has 11; Sentinel-1 SAR has 2 polarizations. Clay v1.5’s “dynamic embedding block” generates patch tokens conditioned on each band’s wavelength, allowing one model to accept any sensor’s spectral profile at inference time. Prithvi-EO-2.0 trains on six harmonized HLS bands and is sensor-specific by design — a different trade-off.

Location and time conditioning. Prithvi-EO-2.0’s “TL” variants ingest center latitude/longitude and acquisition day-of-year as additional embeddings concatenated to the patch tokens. Clay v1.5 similarly encodes lat/lon and time. The conditioning is not just metadata: a green pixel in February in Iowa means something very different than the same green pixel in February in Argentina, and the encoder learns to use the location/time signal to disambiguate.

2. The Models That Matter in 2026

Three open-weight or open-data models dominate practical work. Each represents a different design philosophy.

2.1 Prithvi-EO-2.0 (NASA / IBM / Jülich, Dec 2024)

A 300M and 600M parameter ViT-based MAE jointly developed by NASA, IBM Research, and Jülich Supercomputing Centre, with contributions from 42 researchers across 12 institutions. Pretrained on 4.2 million globally sampled time series chips from NASA’s Harmonized Landsat and Sentinel-2 (HLS) archive at 30-meter resolution, covering roughly seven years of observations and sampled across all major land cover classes and more than 800 ecoregions. Released on Hugging Face under permissive licensing alongside IBM’s TerraTorch fine-tuning toolkit.

On the GEO-Bench evaluation, Prithvi-EO-2.0–600M outperforms its predecessor by 8% and beats six other geospatial foundation models on benchmarks spanning resolutions from 0.1 m to 15 m. The architecture supports inputs of T=4 timesteps and 224×224 spatial extent by default, with patch size (1, 16, 16). Output is a sequence of patch tokens of dimension 1024 (300M) or 1280 (600M).

2.2 Clay v1.5 (Clay Foundation, Sep 2024)

A multi-sensor MAE trained on 70 million globally distributed image chips from Sentinel-1, Sentinel-2, Landsat 8/9, NAIP, LINZ, and MODIS. The dynamic embedding block lets one model handle any subset of sensors and bands at inference time — a major operational advantage when farmers’ workflows mix free public data with paid high-resolution feeds. Trained for roughly 6400 H100-GPU-hours and distributed under Apache 2.0.

A key architectural detail: Clay v1.5 uses a DINOv2 teacher model alongside the MAE objective. The student encoder matches both reconstruction targets (MAE pixel-level) and teacher embeddings (DINOv2 contrastive), which empirically produces embeddings that cluster more cleanly for semantic retrieval. Output dimension is 768 by default.

In the recent flood inundation mapping benchmark, Clay v1.5 leads on PlanetScope (0.79 mIoU) and Sentinel-2 (0.70), while Prithvi leads on Sentinel-1. The variance between top GFMs on most benchmarks is now small (2–5%), which suggests the practical choice is driven more by sensor compatibility and toolchain than by raw accuracy.

2.3 AlphaEarth Foundations (Google DeepMind, July 2025)

A different architectural philosophy. Rather than releasing a model that practitioners fine-tune, Google DeepMind released precomputed embeddings — annual, 64-dimensional vectors at 10-meter resolution covering Earth’s terrestrial surface from 2017 onward, hosted natively in Google Earth Engine as the Satellite Embedding dataset.

The underlying model fuses optical and thermal imagery from Sentinel-2 and Landsat, Sentinel-1 SAR, 3D surface measurements, elevation, climate reanalysis, and descriptive text into a unified embedding field. The 64-dim output is dramatically more compact than Prithvi or Clay’s hidden states, and is designed to be consumed by classical ML — random forests, gradient-boosted trees, simple MLPs — running inside Earth Engine or BigQuery.

For agricultural users, the practical implication is that AlphaEarth eliminates the GPU inference step entirely. A practitioner extracts pre-computed embeddings for their field polygons and trains a downstream model in CPU minutes. The recent Stanford/Corteva benchmark “Harvesting AlphaEarth” (Ma et al., arXiv:2601.00857) evaluates this pattern across crop yield prediction, tillage mapping, and cover crop mapping — making it the first head-to-head comparison of AEF against traditional remote sensing features for production-relevant ag tasks.

2.4 Honorable Mentions

TerraMind (IBM/ESA, 2025) extends the multi-modal angle further, jointly training on optical, SAR, DEM, and other modalities. DOFA (2024) uses a frequency-aware architecture for cross-sensor generalization. SpectralEarth is the leader on hyperspectral crop classification benchmarks, achieving 93.5% overall accuracy on cross-region cereal mapping versus 62.6% for DOFA and 34.5% for HyperSigma in recent comparisons. For most practitioners, Prithvi, Clay, and AlphaEarth cover the working set; the others are specialist tools.

3. The Two Deployment Patterns

Practical use of GFMs splits cleanly into two patterns with very different engineering profiles. Pick the wrong one and the model adds cost without value.

3.1 Pattern A: Fine-Tune the Encoder

For pixel-level tasks (segmentation, dense regression) or when you have enough labeled data to actually move the encoder, fine-tuning is the right pattern. Examples:

  • Yield regression at sub-field (10–30m) resolution with thousands of labeled pixels per field
  • Crop type classification at pixel level
  • Damage assessment after hail/wind
  • Tile/field-level disease mapping

This is what FARM (Khoshdel et al., arXiv:2510.26609, Oct 2025) does for canola yield prediction in the Canadian Prairies: fine-tune Prithvi-EO-2.0–600M with a regression decoder, achieving RMSE of 0.44 t/ha and R² of 0.81 at 30m resolution. The paper reports that fine-tuning Prithvi outperforms training the same ViT architecture from scratch on the same labels — confirming the data-efficiency claim for this setting.

3.2 Pattern B: Use Pre-Computed Embeddings as Tabular Features

For sparse, field-level (not pixel-level) tasks — county yield forecasts, on-farm trial analysis, supply-chain risk scoring — pre-computed embeddings consumed by tabular ML are typically the right pattern. Examples:

  • Mid-season county yield prediction with ~3000 county-years of data
  • Cover crop adoption mapping from sparse ground truth
  • Tillage classification (no-till vs. conventional)
  • Crop type mapping where regional training sets are small

AlphaEarth was designed for this pattern; Clay and Prithvi can be used this way too (extract patch tokens, mean-pool, treat as features) but it’s an off-label use.

3.3 Choosing Between Them

The decision rules in practice:

|  Pattern A (fine-tune)  |  Pattern B (embeddings)
----------------------------+-------------------------+--------------------------
Output granularity needed   |  pixel-level            |  zone or field-level
Labeled samples available   |  >5,000                 |  <5,000
Iteration speed needed      |  days OK                |  minutes
GPU access                  |  required               |  none needed
Best base model             |  Prithvi-EO-2.0, Clay   |  AlphaEarth (preferred)
Typical R^2 gain vs scratch |  +0.05 to +0.15         |  +0.03 to +0.10
Inference cost per field    |  $0.01-0.10 GPU         |  $0.0001 lookup

The cost asymmetry is real. A single Prithvi-EO-2.0–600M inference pass on a 224×224×4-timestep cube takes roughly 80–150 ms on an A100; running it over 10 million field polygons annually is non-trivial compute. AlphaEarth pre-computed embeddings cost essentially nothing per polygon to read — at the cost of locking in a snapshot of the model and giving up the ability to fine-tune.

4. Working Code: Fine-Tuning Prithvi-EO-2.0 for Yield Regression

The cleanest entry point is IBM’s TerraTorch library, which wraps Prithvi (and a growing set of other GFMs) in a PyTorch Lightning interface. The pattern below adapts the encoder to a dense regression task — yield prediction at 30m resolution from a 4-timestep HLS cube.

# pip install terratorch torch torchvision pytorch-lightning rasterio
import torch
import torch.nn as nn
import pytorch_lightning as pl
from terratorch.models import PrithviModelFactory
from terratorch.datasets import GenericNonGeoPixelwiseRegressionDataModule

# 1) Build the model: pretrained Prithvi-EO-2.0 encoder + UperNet decoder
factory = PrithviModelFactory()
model = factory.build_model(
    task="regression",
    backbone="prithvi_eo_v2_600",          # or prithvi_eo_v2_300
    backbone_pretrained=True,
    backbone_bands=["BLUE", "GREEN", "RED", "NIR_NARROW", "SWIR_1", "SWIR_2"],
    backbone_num_frames=4,                 # 4 timesteps across the growing season
    decoder="UperNetDecoder",
    decoder_channels=256,
    head_dropout=0.1,
    head_final_act=nn.ReLU,                # yield is non-negative
    necks=[
        {"name": "SelectIndices", "indices": [5, 11, 17, 23]},  # multi-scale
        {"name": "ReshapeTokensToImage", "effective_time_dim": 4},
        {"name": "LearnedInterpolateToPyramidal"},
    ],
)

# 2) Freeze the backbone for the first phase; train only the decoder
for p in model.encoder.parameters():
    p.requires_grad = False

The two-phase training schedule matters. Cold-start fine-tuning of the entire 600M-parameter model on a few thousand labeled tiles overfits aggressively; the encoder forgets the broad representations it learned during pretraining. The pattern that empirically works:

class YieldRegressionModule(pl.LightningModule):
    def __init__(self, model, lr_decoder=1e-3, lr_encoder=1e-5):
        super().__init__()
        self.model = model
        self.lr_decoder = lr_decoder
        self.lr_encoder = lr_encoder
        self.loss_fn = nn.HuberLoss(delta=1.0)   # robust to yield-monitor noise

    def training_step(self, batch, batch_idx):
        x, y, mask = batch["image"], batch["mask"], batch["valid_mask"]
        pred = self.model(x)
        # Mask out cloud-contaminated and field-boundary pixels
        loss = self.loss_fn(pred[mask], y[mask])
        self.log("train/loss", loss, on_step=True, on_epoch=True)
        return loss

    def configure_optimizers(self):
        decoder_params = [p for n, p in self.named_parameters()
                          if "encoder" not in n and p.requires_grad]
        encoder_params = [p for n, p in self.named_parameters()
                          if "encoder" in n and p.requires_grad]
        param_groups = [
            {"params": decoder_params, "lr": self.lr_decoder},
            {"params": encoder_params, "lr": self.lr_encoder},  # 100x smaller
        ]
        opt = torch.optim.AdamW(param_groups, weight_decay=0.05)
        sched = torch.optim.lr_scheduler.CosineAnnealingLR(opt, T_max=50)
        return {"optimizer": opt, "lr_scheduler": sched}

# Phase 1: decoder only (10 epochs)
module = YieldRegressionModule(model, lr_decoder=1e-3, lr_encoder=0.0)
trainer = pl.Trainer(max_epochs=10, precision="bf16-mixed", accelerator="gpu")
trainer.fit(module, datamodule=dm)

# Phase 2: unfreeze encoder with discriminative LR (30-50 epochs)
for p in model.encoder.parameters():
    p.requires_grad = True
module.lr_encoder = 1e-5
trainer = pl.Trainer(max_epochs=40, precision="bf16-mixed", accelerator="gpu")
trainer.fit(module, datamodule=dm)

A few engineering details that matter in practice:

Mixed precision is mandatory. Prithvi-EO-2.0–600M at full FP32 needs roughly 80 GB of GPU memory for a meaningful batch size; bf16 on an A100/H100 fits a batch of 8 comfortably. The pretrained weights are bf16-compatible by construction.

LoRA as the lighter alternative. For teams without 8-GPU H100 nodes, low-rank adaptation produces 80–90% of the fine-tuning gain at a fraction of the memory:

from peft import LoraConfig, get_peft_model

lora_config = LoraConfig(
    r=16, lora_alpha=32, lora_dropout=0.1,
    target_modules=["qkv", "proj", "fc1", "fc2"],  # ViT attention + FFN
    bias="none",
)
model.encoder = get_peft_model(model.encoder, lora_config)
# Trainable params now ~0.5% of full encoder; trains on a single A10G

Yield-monitor labels need explicit masking, not just augmentation. Combine yield monitors produce systematic errors at headlands and field boundaries (header surge, fill delay, GPS jitter). The valid_mask in the training step above is generated from a pre-processing pipeline that filters by realistic moisture/speed/distance-from-boundary thresholds. Without it, the model overfits to sensor artifacts at field edges and the test-set RMSE looks better than the deployment RMSE.

5. Working Code: Pattern B with AlphaEarth Embeddings

Pattern B looks completely different — no GPUs, no deep learning framework, just Earth Engine + scikit-learn / XGBoost. For a field-level yield model:

# pip install earthengine-api geopandas xgboost
import ee
import geopandas as gpd
import numpy as np
import pandas as pd

ee.Authenticate()
ee.Initialize(project="your-gcp-project")

# 1) Load the AlphaEarth Foundations Satellite Embedding dataset
EMBEDDING_COLLECTION = "GOOGLE/SATELLITE_EMBEDDING/V1/ANNUAL"

def get_field_embeddings(fields_gdf, year):
    """
    fields_gdf: GeoPandas DataFrame with field polygons in EPSG:4326
    Returns: DataFrame with 64-dim mean embedding per field for the given year.
    """
    # Convert to Earth Engine FeatureCollection
    features = []
    for idx, row in fields_gdf.iterrows():
        geom = ee.Geometry(row.geometry.__geo_interface__)
        features.append(ee.Feature(geom, {"field_id": int(row["field_id"])}))
    fc = ee.FeatureCollection(features)

    # Filter the embedding collection to the year
    embedding_img = (ee.ImageCollection(EMBEDDING_COLLECTION)
                     .filterDate(f"{year}-01-01", f"{year}-12-31")
                     .mosaic())

    # Reduce each polygon to its mean 64-dim embedding
    reduced = embedding_img.reduceRegions(
        collection=fc,
        reducer=ee.Reducer.mean(),
        scale=10,  # AlphaEarth native resolution
    )
    rows = reduced.getInfo()["features"]
    records = []
    for r in rows:
        props = r["properties"]
        rec = {"field_id": props["field_id"]}
        for k, v in props.items():
            if k.startswith("A"):  # AEF dimensions named A00..A63
                rec[k] = v
        records.append(rec)
    return pd.DataFrame(records)

# 2) Pull embeddings for the prior 3 years (capture phenological trajectory)
fields = gpd.read_file("fields.geojson")
emb_2023 = get_field_embeddings(fields, 2023).add_suffix("_2023")
emb_2024 = get_field_embeddings(fields, 2024).add_suffix("_2024")
emb_2025 = get_field_embeddings(fields, 2025).add_suffix("_2025")

# 3) Stack into a feature matrix
features = (emb_2023.merge(emb_2024, left_on="field_id_2023", right_on="field_id_2024")
                    .merge(emb_2025, left_on="field_id_2023", right_on="field_id_2025"))
X = features.drop(columns=[c for c in features.columns if "field_id" in c]).values
# X shape: (n_fields, 192)  — 64 dims x 3 years

The downstream model is standard tabular ML, identical to what Article 1 covered:

import xgboost as xgb
from sklearn.cluster import KMeans

# Spatial-temporal cross-validation from Article 1
class SpatioTemporalCV:
    def __init__(self, n_clusters=8, random_state=42):
        self.n_clusters = n_clusters
        self.random_state = random_state

    def split(self, df, lat_col="lat", lon_col="lon", year_col="year"):
        coords = df[[lat_col, lon_col]].values
        clusters = KMeans(self.n_clusters, random_state=self.random_state).fit_predict(coords)
        years = sorted(df[year_col].unique())
        for yr in years[1:]:
            for c in range(self.n_clusters):
                test_mask = (df[year_col] == yr) & (clusters == c)
                train_mask = (df[year_col] < yr) & (clusters != c)
                if test_mask.sum() < 10 or train_mask.sum() < 100:
                    continue
                yield np.where(train_mask)[0], np.where(test_mask)[0]

cv = SpatioTemporalCV(n_clusters=8)
fold_metrics = []
for tr, te in cv.split(metadata_df):
    dtrain = xgb.DMatrix(X[tr], label=y[tr])
    dtest  = xgb.DMatrix(X[te], label=y[te])
    bst = xgb.train(
        {"objective": "reg:squarederror", "tree_method": "hist",
         "max_depth": 6, "learning_rate": 0.05, "subsample": 0.8},
        dtrain, num_boost_round=2000,
        evals=[(dtest, "test")], early_stopping_rounds=50, verbose_eval=False,
    )
    pred = bst.predict(dtest)
    fold_metrics.append({"rmse": float(np.sqrt(((pred - y[te])**2).mean())),
                         "n": len(te)})

The entire pipeline above runs in CPU minutes for a typical mid-sized farm. The first time a practitioner trades a 24-hour GPU fine-tune for a 5-minute embedding lookup with comparable accuracy, the appeal of the embeddings-as-features pattern becomes obvious.

6. What the Numbers Actually Say

The most pressing practical question — does this work, and how much — has gotten real answers in late 2025 and early 2026 from a small but growing benchmark literature.

FARM (Prithvi-EO-2.0–600M fine-tuned for canola yield, Canadian Prairies). RMSE 0.44 t/ha, R² 0.81 at 30m intra-field resolution. The same ViT architecture trained from scratch on the same labels performs substantially worse, confirming that the pretraining transfers. The paper’s key claim: fine-tuned Prithvi outperforms 3D-CNN and DeepYield baselines on the same task.

Harvesting AlphaEarth (Ma et al., Stanford + Corteva). Evaluates AEF embeddings on U.S. crop yield prediction, tillage mapping, and cover crop mapping. Headline result: AEF embeddings + simple downstream models match or exceed handcrafted remote sensing feature pipelines on all three tasks, with dramatically less engineering effort. The paper’s caveat — and the right caveat to internalize — is that the gap narrows in data-rich settings. When the practitioner already has years of high-quality labeled data and well-tuned feature engineering, the marginal value of foundation model embeddings shrinks.

GEO-Bench-2 (Nov 2025). Updated benchmark covering segmentation, regression, and change detection across multiple domains. Two findings worth absorbing: (1) EO-specific models like TerraMind, Prithvi, and Clay outperform natural-image pretrained models (ConvNext-ImageNet, DINOv3) on multispectral applications including agriculture; (2) no single GFM dominates across all tasks — the choice of base model depends on sensor, resolution, and task.

Translating to practitioner expectations:

Task                                    | Without GFM (from-scratch)  | With GFM (fine-tuned/embed)
----------------------------------------+-----------------------------+-----------------------------
Sub-field yield (canola, 30m)           | R^2 ~0.65-0.70              | R^2 ~0.78-0.82  (FARM)
County corn yield (mid-season)          | RMSE 14-18 bu/ac            | RMSE 11-14 bu/ac
Cover crop binary classification        | F1 0.78-0.85                | F1 0.85-0.92
Tillage type (no-till vs conventional)  | F1 0.75-0.82                | F1 0.82-0.88
Pixel-level crop type (10m, in-season)  | mIoU 0.65-0.72              | mIoU 0.74-0.81

The gains are real but not transformative for tasks where strong baselines already exist. They become transformative for data-scarce tasks (a new crop, a new region, a new on-farm trial), where from-scratch training simply doesn’t have enough signal to learn.

7. Evaluation: The Cross-Validation Problem Carries Over

The spatial autocorrelation trap from Article 1 is even more dangerous with foundation models. GFMs absorb broad-scale geographic patterns into their location embeddings — meaning that a model evaluated with random k-fold cross-validation will heavily benefit from leaking spatial structure between folds. Random-split R² of 0.85 routinely collapses to year-out + region-out R² of 0.65–0.70 on the same data.

The mandatory evaluation discipline:

  • Year-out cross-validation. Hold out one year of labels; train on prior years. Mimics deployment.
  • Region-out cross-validation. Hold out a spatially contiguous region (a state, an ecoregion, an H3 cell at resolution 4). Mimics geographic transfer.
  • Combined year × region folds. The strictest test. This is what GEO-Bench and PANGAEA use.
  • Pre-AEF / pre-Prithvi temporal split. When using AlphaEarth embeddings, ensure the embedding year aligns with the label year. AEF embeddings are annual; mixing 2024 embeddings with 2023 yield labels leaks future information and inflates apparent accuracy.

For Pattern A (fine-tuning), there’s a subtler concern: the encoder was pretrained on a corpus that may have included satellite imagery overlapping the evaluation region. Prithvi-EO-2.0 was trained on globally distributed HLS samples, so pretraining contamination is not “test set memorization” in the LLM sense — there are no labels in the pretraining — but the encoder has seen the visual statistics of every major agricultural region. This isn’t disqualifying; it just means GFM evaluation should report performance broken out by region and by data-availability regime, not as a single headline number.

8. Production Engineering Considerations

Several operational details determine whether GFMs become a sustainable part of an agricultural ML stack or a research project that quietly dies in production.

Inference cost at fleet scale. A typical large-farm or co-op deployment covers 50,000–500,000 field-years annually. Pattern A inference on Prithvi-EO-2.0–600M at 80 ms/tile × 4 tiles/field comes to roughly $50–200/day on spot A100 instances at that scale. Pattern B (AlphaEarth embedding lookups) is effectively free, with the cost dominated by Earth Engine quota and storage. Most production deployments adopt a hybrid: Pattern B for routine workflows, Pattern A for high-value applications where the marginal accuracy gain justifies GPU spend.

Embedding storage and retrieval. Pre-computed embeddings need a place to live. AlphaEarth embeddings are 64-dim float32 = 256 bytes/pixel; at 10m resolution that’s 2.56 MB/km² annually. For a typical U.S. corn belt deployment covering 50 million acres (~200,000 km²), one year of embeddings is roughly 500 GB. Storage options that work in practice: Parquet partitioned by H3 cell + year for tabular access patterns; Zarr for raster/spatial queries; pgvector or LanceDB for similarity search. The choice depends on query patterns more than data volume.

Version drift across model releases. Foundation models update. Clay v1.0 to v1.5 changed the embedding space; Prithvi-EO-1.0 to 2.0 is a fundamentally different architecture; AlphaEarth’s annual updates may or may not preserve embedding semantics across years (Google’s documentation promises stability with one-year deprecation notice). Production systems need either (a) frozen pinned versions with explicit migration plans, or (b) downstream models that are robust to embedding drift via continuous retraining.

Multi-resolution alignment. Prithvi works at 30m HLS; Clay works at native sensor resolution; AlphaEarth is 10m. Combining them — or pulling embeddings for a field whose boundary doesn’t align cleanly with pixel grids — requires careful resampling. Standard practice is to compute zonal statistics (mean, p10, p50, p90, std) of embedding dimensions within each field polygon, then use those as features. Naive nearest-neighbor lookup at the polygon centroid loses substantial information.

9. The Honest Limits

Foundation models are not magic. Five categories of agricultural problems where GFMs still don’t help meaningfully:

Sub-meter perception tasks. See-and-spray weed segmentation, fruit counting, and disease lesion detection operate at sub-centimeter resolution from in-cab or UAV cameras. The pretraining corpora of Prithvi, Clay, and AlphaEarth are dominated by 10–30m satellite imagery; the visual statistics of a leaf surface or a weed seedling are entirely outside the training distribution. CNNs and ViTs pretrained on natural images (ImageNet, SA-1B) still outperform geospatial foundation models for these tasks, often substantially.

Short-cycle in-season prediction. AlphaEarth’s annual embeddings are useless for “what is the yield risk given the heatwave that started Tuesday.” Daily or weekly embeddings are emerging but not yet at parity. For sub-seasonal forecasting, classical features (NDVI time series, cumulative GDD, water deficit) remain superior because their temporal granularity matches the decision horizon.

Causal inference and treatment effect estimation. Foundation models produce better features; they do not solve confounding. A causal forest or doubly-robust estimator built on Prithvi features still requires randomized on-farm trials to identify treatment effects. The variable-rate prescription problem from Article 1 doesn’t get easier with GFMs; it just gets a slightly better baseline.

Rare crops and smallholder systems. Pretraining corpora are dominated by major commodity crops in well-developed agricultural regions. Smallholder mixed-cropping systems, traditional rotations in low-income countries, and uncommon specialty crops (sorghum varieties, indigenous grains, mixed agroforestry) are systematically under-represented. GFM performance on these systems often lags state-of-the-art region-specific models trained from scratch.

Genotype-specific phenotypes. Yield prediction at the cultivar/hybrid level — telling a breeder which lines will outperform — requires inputs that GFMs don’t ingest: genomic markers, parental pedigree, trial-plot phenotypic measurements. The remote-sensing signal foundation models extract is real, but it explains the environment side of G×E, not the genotype side.

10. What Changes, What Stays the Same

The short version of where the field is in 2026: foundation models have moved from research novelty to production-ready infrastructure for a specific set of agricultural ML problems — primarily field-to-region scale tasks where labeled data is scarce and the underlying signal is dominated by surface reflectance and phenology. For these problems, the labeled-data economics genuinely have changed. A team that needed 50,000 labeled tiles to train a competitive crop-type model in 2022 can now do it with 5,000, sometimes 500, using Prithvi or Clay fine-tuning. A team that needed a multi-stage feature pipeline plus a custom ViT to produce a county yield forecast can now run AlphaEarth embeddings through XGBoost in an afternoon.

What hasn’t changed is the rest of the stack. The spatial-temporal cross-validation discipline from Article 1 still determines whether reported metrics survive deployment. The causal inference machinery for variable-rate prescriptions still requires randomized trials and is unaffected by foundation models. The edge perception stack for see-and-spray still wants ImageNet-pretrained CNNs more than satellite-pretrained ViTs. The label quality problem — yield monitor noise, cloud contamination, mismatched polygon boundaries — gets exactly the same engineering treatment it always did.

The practitioner who treats Prithvi or AlphaEarth as a drop-in replacement for the entire stack is going to be disappointed. The practitioner who treats it as a much better feature extractor for the parts of the stack where features were the bottleneck — and leaves the rest of the engineering discipline intact — is going to see real, sustained accuracy gains and dramatically faster iteration cycles.

That’s the actual win. Foundation models are not a new paradigm replacing precision agriculture’s existing ML stack; they’re a substantially better default for one specific layer of it. The teams that adopt them earliest, and most carefully, are the ones who already had clean evaluation pipelines, honest baselines, and the discipline to ask “did this actually help on the year-out fold” before declaring victory. Everything else is the next article in the series.


About the Author

Brian Curry is a Kansas City-based data scientist and applied AI researcher with two decades of enterprise experience across retail, agriculture, energy, hospitality, telecommunications, and media. He is the founder of Vector1 Research, an independent lab focused on applied AI, causal inference, agentic systems, and the economics of intelligent organizations. His work centers on building systems that surface the causal and structural drivers of performance — bridging advanced analytics, machine learning, and executive decision-making. He writes regularly on Medium about applied AI, knowledge engineering, decision science, and the engineering disciplines that make machine learning actually work in production.References

  • Szwarcman, D., Roy, S., Fraccaro, P., et al. (2024). Prithvi-EO-2.0: A Versatile Multi-Temporal Foundation Model for Earth Observation Applications. arXiv:2412.02732. Model weights: huggingface.co/ibm-nasa-geospatial/Prithvi-EO-2.0–600M.
  • Clay Foundation (2024). Clay v1.5: An Open Foundation Model for Earth. clay-foundation.github.io/model. Weights under Apache 2.0 on Hugging Face.
  • Brown, C., et al. (2025). AlphaEarth Foundations: An embedding field model for accurate and efficient global mapping from sparse label data. arXiv:2507.22291. Dataset: Google Earth Engine, GOOGLE/SATELLITE_EMBEDDING/V1/ANNUAL.
  • Khoshdel, V., Nejadshamsi, S., et al. (2025). FARM: Fine-Tuning Geospatial Foundation Models for Intra-Field Crop Yield Regression. arXiv:2510.26609.
  • Ma, Y., Shen, Y., Swatantran, A., Lobell, D. B. (2026). Harvesting AlphaEarth: Benchmarking the Geospatial Foundation Model for Agricultural Downstream Tasks. arXiv:2601.00857.
  • GEO-Bench-2: From Performance to Capability, Rethinking Evaluation in Geospatial AI (Nov 2025). arXiv:2511.15658.
  • Marsocci, V., et al. (2024). PANGAEA: A Global and Inclusive Benchmark for Geospatial Foundation Models.
  • IBM Research (2024). TerraTorch: A flexible fine-tuning toolkit for geospatial foundation models. github.com/IBM/terratorch.

Related research