Tabular AutoML assumes someone already built the table. Geospatial work usually does not. On August 27, 2026, Google Research announced the Planetary Prediction Engine (PPE): an experimental Earth AI agent that takes a predictive natural-language query, discovers covariates, fuses foundation-model embeddings, trains a model, and writes a report.
Authors Rama Pasumarthi (Staff Software Engineer) and Shravya Shetty (Distinguished Engineer) put the time claim in one line: weeks of manual data engineering become minutes of autonomous insight. The numbers behind that claim are specific — 76.8% mean R² on 21 CDC health indicators versus 60.0% for a manual expert pipeline — and they are Google's evals, not a public product scoreboard.
If you build agent loops, the interesting part is not "AI for the planet." It is a three-stage orchestrator that refuses to stuff Earth Engine rasters into the context window.
| Question | Answer (as of August 27, 2026) |
|---|---|
| What shipped? | Experimental research system inside Google Earth AI — paper + blog, not a Cloud SKU |
| Input | Geospatial predictive natural-language query |
| Output | Retrieved data, engineered features, trained/evaluated model, written report |
| Time claim | Weeks of specialist curation → minutes of autonomous insight |
| CDC health (21 indicators) | Mean R² 76.8% vs 60.0% manual expert pipeline |
| Nigeria food security | ADM1 → ADM2 downscaling R² 66.1% vs 31.5% |
| DRC Ebola nowcasting | Recall@10 83.3% (15/18 zones; +10.3 pp vs ~73% Bayesian SOTA) |
| Can I call an API? | No. Early-stage research; no public builder API documented |
| What to copy | Stage modularity, opaque handles, Feature Gate, Overfitting Guard |
What is the Planetary Prediction Engine?
PPE is Google Research's name for an LLM-orchestrated geospatial modeling agent. It sits under the broader Earth AI initiative — the same Google science lane as WeatherNext cyclone forecasting and the earlier Earth AI reasoning work, not the Nano Banana "reimagine this place" consumer feature in Google Earth.
The problem statement is blunt. Geospatial data is fragmented. Building a predictive model still takes specialist teams weeks of curation, feature engineering, and spatial validation. Ordinary AutoML and LLM agents automate the last mile — they need a clean table. Humanitarian timelines do not.
Given a query, PPE is supposed to retrieve relevant data, engineer features, train and evaluate models, and generate a comprehensive report. Google's phrasing: it "turns planetary information into actionable insights." Treat that as the research pitch, not a product promise.
The companion paper is arXiv:2608.26088, Planetary Prediction Engine: Autonomous Geospatial Prediction via Intelligent Data Selection and Foundation Model Embeddings.
Can I use PPE today?
No. The announcement calls PPE an "experimental research capability" and, in the close, an "early-stage research project." That is the honest product status.
There is no documented public API, waitlist, Vertex AI endpoint, or Earth Engine checkbox that turns PPE on for your project. Do not design a 2026 roadmap that depends on calling PPE. Design around the patterns (below) using tools you already control: Earth Engine, Data Commons, your own AutoML, your own agent harness.
If you need a Google Research agent you can study as a published pipeline, ScientistOne / AI Scientist at ICML 2026 is the literature-to-manuscript cousin — still research, but a different stack.
How is this different from AutoML agents?
Three gaps, all from Google's own contrast with "existing AutoML and LLM-based agents":
- No pre-curated table. PPE has to discover join keys, spatial grain, and temporal scope from language, then pull from Data Commons, Google Earth Engine, and (when those miss) government portals and academic repos at inference time.
- Geospatial foundation-model fusion. Tabular covariates are fused with Population Dynamics Foundation Models (PDFM) for socio-demographic latent states and AlphaEarth for satellite-imagery semantics. That is not a standard AutoML preprocessor.
- Spatial leakage and overfitting are first-class. Feature Gate and the Overfitting Guard Protocol exist because geospatial labels leak easily (shared surveys, future timestamps, algebraic parts of the target).
Adaption Labs' AutoScientist automates a training-recipe loop over data mixtures and alignment. PPE automates a geospatial dataset loop before any GBDT is fit. Same "agent does the specialist's week" story; different bottleneck.
What are the three stages?
Google decomposes the workflow into three modular stages, each orchestrated by an off-the-shelf LLM. The blog's animation caption mentions four visual beats (selection through report); the architecture write-up and paper treat report generation as the output of stage 3, not a fourth independent LLM stage.
Stage 1 — Intelligent geospatial data selection
The query is compiled into geographic constraints: spatial granularity, join-keys, temporal scope. Then grounded signal discovery: domain hypotheses, direct signals, and causal proxies checked against published literature. Retrieval hits Data Commons and Google Earth Engine first. Missing signals trigger live open-web discovery.
Stage 2 — Multimodal dataset curation
Covariates fuse with frozen PDFM and AlphaEarth embeddings. A strict Feature Gate scores every candidate against four anti-leakage tests (next section). The paper also describes split-isolated imputation so fill values are computed on the train split only.
Stage 3 — Automated model building and prediction
Search over regularized linear models, gradient-boosted decision trees (GBDT), and multi-layer perceptrons. An Overfitting Guard Protocol pre-assesses dataset risk and runs a self-correction loop when generalization fails.
Opaque handles sit between stages. Data artifacts are not serialized into prompts. The LLM sees a handle — an ID pointing at storage — so the context window does not become a raster dump. If you have ever watched an agent paste a 200-column CSV into chat, this is the fix.
What do the R² and Recall@10 numbers mean?
Read them the way how to read AI benchmarks teaches: named task, named baseline, named metric, Google-run eval. Not a public leaderboard you can re-score tonight.
| Task | Metric | PPE | Baseline | What "win" means |
|---|---|---|---|---|
| 21 CDC health indicators (US) | Mean R² | 76.8% | 60.0% manual expert pipeline | More variance explained on county-scale health rates |
| FEMA national risk | Mean R² | 64.9% | 60.0% | Smaller lift; still above the same expert-style baseline |
| Social Vulnerability Index | Mean R² | 66.2% | 58.6% | Socioeconomic vulnerability, not weather |
| Nigeria food security | R² (ADM1 → ADM2) | 66.1% | 31.5% | Local-government downscaling; Google says this doubles the baseline |
| DRC Bundibugyo ebolavirus, 2026 | Recall@10 | 83.3% (15 of 18 zones, five weekly forecasts) | ~73% Bayesian SOTA (+10.3 pp) | Did the top-10 predicted zones include newly invaded health zones? |
R² here is spatial regression fit, not "the model is 76.8% accurate." A jump from 60.0 to 76.8 is a large lift on that metric; it does not tell you calibration, fairness across counties, or whether a health department should act without a human epidemiologist.
Recall@10 is a hotspot ranking metric: of the zones that actually newly invaded, how many sat in the model's top 10? 15 of 18 across five weeks is the count Google published. Collaboration credit: Institut National de Recherche Biomédicale (INRB) on the DRC work; UN World Food Programme / VAM for food-security data.
Nigeria's lift is the headline for data-scarce regions: market shocks, food-price anomalies, microclimate, then PDFM + AlphaEarth fusion. Use cases Google actually names: public health, food security, environmental / FEMA risk, socioeconomics. Do not expand that list into astronomy or "manage the world."
Key finding Google wants you to take: structured covariates and latent FM embeddings are complementary, not redundant. Ablations (paper) show neither modality alone matches the full stack. Future work they flag: more sources, plus Remote Sensing Foundations multimodal embeddings.
How does Feature Gate prevent leakage?
Geospatial labels are leaky. A "poverty" target that includes a survey item you also ingested as a covariate is not a model — it is a mirror. Feature Gate is PPE's automated answer to train-test leakage.
Four filters, from the research blog:
| Gate | Drops covariates that… |
|---|---|
| Mathematical sub-components | Are algebraic parts of the target (the feature is the label in disguise) |
| Shared survey data | Come from the same survey instrument as the label |
| Downstream causal effects | Are effects of the target, not usable predictors |
| Future temporal data | Sit after the prediction timestamp |
The paper is more cautious than the blog: anti-leakage protocols are "strong safeguards," but formal verification of causal-direction filters remains an open challenge, especially when relationships are bidirectional. Copy the four checks into your own agent. Do not assume they are complete.
A builder-shaped gate you can paste into a curation stage today:
For each candidate feature F against target Y at time t:
1. Reject if F is a formula, subset, or rename of Y.
2. Reject if F and Y share a survey instrument or collection wave.
3. Reject if domain literature treats F as a downstream effect of Y.
4. Reject if F's timestamp is after t (no future leakage).
5. Impute using train-split statistics only; never peek at val/test.
Return {keep, drop, reason} — do not silently include.
Opaque handles vs stuffing data in context?
PPE's stages are independent. Artifacts move as opaque handles, not as prompt text.
That is the same lesson as any serious agentic workflow: the LLM is an orchestrator, not a database. Pass dataset://cdc-health-v3 (or an object-store URI). Let tools load the bytes. You avoid context-window limits, you keep a provenance trail, and you stop the model from "summarizing" a raster into fiction.
If you are wiring this into a loop, the handle is the state; the prompt is the control plane. That maps cleanly onto the stop-and-check discipline in explainx.ai's agent-loop guide — do not stream a 4 GB Earth Engine export through the chat.
What should agent builders copy even without a PPE API?
Four patterns survive if Google never ships a product:
- Stage modularity. Discovery, curation, and model search as separate contracts with typed I/O. One failing stage should not require re-prompting the whole planet.
- Opaque handles. IDs between stages; bytes in storage.
- An explicit leakage gate before AutoML. Especially if your agent can search the live web — web-discovered features are where leakage hides.
- An overfitting guard that pre-assesses small-n / high-p risk and self-corrects when val/test diverge. PPE searches linear, GBDT, and MLP families; your search space can be smaller.
Also copy the honesty about frozen embeddings. PPE uses PDFM and AlphaEarth as feature extractors, not as end-to-end fine-tunes. The paper lists that as a limitation, plus a noise-resolution trade-off: on one SVI super-resolution setting, adding high-resolution AlphaEarth features hurt overall R² (40.1% vs 52.0% for the covariate-PDFM stack). More satellite channels is not automatically better.
What are the honest limitations?
- Not a product. Experimental, early-stage, no public builder API in the announcement.
- Google-run benchmarks. Strong numbers, single-lab eval. Re-run on your geography before you trust a deployment.
- Ebola nowcast is one outbreak (2026 Bundibugyo ebolavirus in the DRC). The paper says validation across pathogens and geographies is still needed.
- Causal Feature Gate is not formally verified for messy bidirectional targets.
- Frozen FMs. No claimed end-to-end fine-tune of PDFM/AlphaEarth for each task.
- Fine-scale satellite features can add noise. Paper ablation on SVI super-resolution; the blog headline numbers do not advertise this failure mode.
- Off-the-shelf LLMs orchestrate stages — Google does not name the model family in the blog. Do not assume a specific Gemini SKU.
This is closer to a research demo of geospatial AutoML agents than to a tool you pip install. The adjacent Google science story on explainx.ai is still WeatherNext for forecast fields, not PPE for custom spatial regression.
Related reading
- What are AI agents? Complete guide
- How to build your first agent loop
- God's Eye View: open-source spy-satellite cockpit — live public globe + voice agent you can clone; PPE models outcomes, GEV renders the present
- DeepMind WeatherNext cyclone forecasting
- Google Earth + Nano Banana 2 geospatial generation
- Google AI Scientist / ScientistOne at ICML 2026
- Adaption AutoScientist — automated model training
- How to read AI benchmarks
- What are world models?
Primary sources: Google Research blog — Planetary prediction engine · Paper — arXiv:2608.26088
Figures, R², Recall@10, and the weeks-to-minutes claim reflect Google Research's August 27, 2026 blog and arXiv:2608.26088. PPE is experimental research, not a generally available API — re-check the official Earth AI pages before treating any number as a product spec. Follow @explainx_ai for agent-architecture coverage.
