Not every enterprise AI problem needs an agent. BigQuery's TimesFM 3.0 puts forecasting inside the database

The most useful AI release of the week for a demand planner involves no agent, no prompt and no chat window. It is a SQL function.

On October 7, Google Cloud added TimesFM 3.0 to BigQuery’s AI.FORECAST function, in preview. TimesFM is a forecasting foundation model from Google Research, released as open source, and BigQuery now runs it as a built-in model. The new version adds multivariate forecasting: predictions for many time series at once, using their history plus additional variables, called covariates, that help explain them.

That is a modest release on paper. It is also a useful corrective to a habit forming in enterprise AI, where every analytical problem is assumed to need an agent.

What the function does

A forecast in BigQuery now looks like a query. Google’s tutorials use a single input table in which historical rows hold the dates, the values to forecast and the past covariates, while future rows hold the dates and the covariates already known for the future, such as a promotions calendar or a weather forecast. Google’s examples forecast sales with promotions and weather as inputs.

Two related functions come with it: AI.EVALUATE, which measures forecast accuracy, and AI.DETECT_ANOMALIES, which flags unusual points. Both are documented for single time series, a detail that matters below.

The agent version of the same problem

Picture the alternative many teams are now building. An agent receives a question about next quarter’s demand, queries the warehouse, pulls the data into a notebook or a sandbox, writes Python to fit a model, runs it and reports a number.

Every step in that chain is a place to fail. The data leaves the platform where its permissions and audit trail live. The code is generated fresh each time, so two runs of the same question can use two different methods. The cost includes a frontier model’s reasoning for what is, underneath, a well-understood statistical task. And as we noted when agents started putting new load on the data path, moving data to the model is often slower than it looks.

The in-database version has fewer parts. The data stays where it is governed. The method is the same on every run. The model needs no training pipeline of its own. That is not a small difference for a forecast that feeds inventory, staffing or cash planning.

Where agents still belong

None of this makes agents useless for forecasting. They are good at the parts around the number: asking which covariates matter, explaining a forecast to a planner, assembling a report. The right shape is an agent that calls the forecasting function as a tool, not one that reinvents it. It is the same portfolio logic we argued for in our framework for an enterprise model portfolio, where the predictive models a company already owns keep their role next to generative ones.

What to check before relying on it

It is a preview. Capacity, regions and behavior can change before general availability.

Evaluation has to come from you. The built-in evaluation and anomaly functions are documented for single series. For multivariate forecasts, backtest against held-out history, and compare against the models the planning team already trusts. Many already run statistical forecasts in the same warehouse.

Covariates are business data. A forecast that uses the promotions calendar is only as good as that calendar. The owner of each covariate becomes part of the forecasting process, whether anyone writes that down or not.

Before designing an agent for a forecasting problem, ask a simpler question first: is the answer a function call? Increasingly, it is.