WeatherNext skipped the physics. That's the whole story.
DeepMind's WeatherNext does something counterintuitive: it predicts cyclone tracks by learning patterns in reanalysis data rather than solving Navier-Stokes equations on supercomputers. Fifty years of numerical weather prediction built on the assumption that you must model the physics to model the world. WeatherNext trained on ERA5 reanalysis and predicts the next atmospheric state directly. Cyclone track error dropped meaningfully versus ECMWF's HRES, a physics-based model that costs orders of magnitude more to run.
The domain-specific feature engineering—pressure gradients, vorticity fields, potential temperature—became learned representations. This is the same shift AlphaFold did to Rosetta. A deep network absorbed decades of domain knowledge without anyone writing down a single physics equation. And it's coming for every multivariate stream you own: market microstructure, sensor telemetry, fleet routing, load forecasting.
For teams building agents that touch continuous data, this is not a model story. It's an architecture story.
Why your agent is bad at time series (and doesn't know it)
LLM agents asked to reason over numeric streams hit a wall the moment you try to make them actually predict. Tokenizers shred floats. A temperature reading like 1273.44 becomes 4-6 tokens with no ordinal meaning. Your model has no native concept that 1273 is close to 1274. It's a trick it learned from training text, not a structural understanding of magnitude.
Context windows collapse fast. Ten thousand sensor readings at 1 Hz—three hours of data—hits token limits before you've even asked the question. So you summarize. You feed the agent text: "the series averaged 67.3, peaked at 89.2, trending up." Now the agent is reasoning over summaries, not the actual stream. It invents patterns that pass eyeballing but fail backtests.
Retrieval doesn't fix it. You can RAG-fetch historical context, tick charts, news. You're still retrieving text about the series, not the series itself. The tell: your eval set measures "does the answer sound right" not "does it predict the next value." Chain-of-thought over numeric sequences hallucinates with confidence.
The delegation pattern: agent as router, sequence model as tool
The fix is architectural, not a model-scale play. The LLM decides what to ask and how to act. A specialized sequence model produces the forecast. Wire it in as a tool.
Tool signature: forecast(series_id, horizon, quantiles) -> {p10, p50, p90, confidence}. You have options: TimesFM (Google), Chronos (Amazon), Moirai (Salesforce), Lag-Llama—all pretrained, zero-shot decent on domains they've seen structure in. Fine-tune only when your domain has structural regime shifts the pretrained model missed.
Latency math: a Chronos-small inference runs in 200–500ms per forecast call versus 3–8 seconds of LLM "reasoning" that's worse. Cost math: a Chronos-small call costs fractions of a cent. A GPT-4-class model chewing through 8k tokens of CSV runs 20–100x more expensive and less accurate. When your agent needs to forecast every 15 minutes across 500 sensors, the cost difference shifts from "optimization" to "business model."
This is where we've built our routing logic for agent reasoning models—the expensive, capable reasoning stays for decisions, not for transcription of patterns the data already holds.
When to defer, when to reason: a decision rule we actually use
Continuous, multivariate, more than 100 points, needs a numeric answer: sequence model, always. Sparse events with rich text context—incidents, tickets, news, customer emails—the LLM reasoning wins. When you need both forecast and narrative, the sequence model produces the number and confidence band; the LLM produces the story. Anomaly detection is the ambiguous case: let the sequence model compute forecast residuals, then the LLM triage high-variance spikes into "real anomaly" or "sensor glitch."
The failure to avoid: having the LLM "sanity check" the sequence model and override it. You've just re-added the hallucination. The agent second-guesses its tool because the number "seems too high." An agent that doesn't trust its tools is an agent that's doing the work twice.
The real tradeoff we think about: useful work per dollar isn't the first question—does your problem need an agent loop at all, or a workflow? If you're forecasting a stream and the forecast is the decision, you don't need an agent. Pipe the forecast straight to your infrastructure. Agents shine when the next step depends on reasoning over the forecast plus external context.
Production plumbing: schemas, retries, and the confidence contract
The engineering discipline matters. Return quantiles, not point estimates. The agent needs uncertainty to decide whether to act or escalate. A forecast of "73 with p10=71, p90=75" tells the agent whether to wake someone up. A point estimate of "73" tells it nothing.
Version the model behind the tool. Log inputs, outputs, and drift metrics per call. Apply the same observability discipline you'd use for cache-reason logs in your agent observability: if the forecast confidence drops below your threshold, the agent should widen the query window or escalate, not re-prompt itself.
Run backfill eval weekly. Replay the last 90 days of production series against your sequence model. Alert on MAPE regressions. The trap we've hit: pretrained sequence models drift silently on non-stationary streams. Schedule quarterly re-eval—don't just evaluate at deploy. If your domain was stationary six months ago and isn't now, your sequence model doesn't know.
What this means for the next 12 months of agent design
WeatherNext is a signal, not a one-off. Expect specialized foundation models for load forecasting, order-book microstructure, fleet telemetry. Your agent framework needs to treat "call a specialized model" as a first-class primitive, not a bolted-on tool. The competitive edge shifts from "which LLM" to "which tools does your agent know how to reach for."
Teams still trying to prompt GPT-class models into forecasting will lose to teams shipping the boring architecture. The uncomfortable read: for a lot of high-value problems, the LLM is the least interesting part of the stack. It's routing and orchestration and knowing when to defer.
If you're building an agent that touches a numeric stream, audit one workflow this week. Measure what your LLM is actually doing to the numbers. Then benchmark it against a zero-shot TimesFM or Chronos call. We're happy to help you run that comparison at /contact.