Methods
SQL, retrieval, and forecasting answer different questions
One operational dataset can support a lookup, a comparison, an investigation, or a forecast. The question determines the method—and the evidence needed to trust its result.
In this article
Begin with the question, then choose the operation
A team connecting an agent to operational data will soon face a choice between SQL, retrieval, and time-series models. It helps to make that choice at the level of a question. The same measurements can support several kinds of work, and one investigation may require all three methods.
Take the public building-energy record used in our reference replay. It contains appliance energy at ten-minute intervals. We can ask what the reading was at a particular time, whether usage changed, what might explain a selected event, or how much energy the building might use tomorrow. Those requests share a dataset. They do not share a definition of a correct answer. 1
Separating them early prevents a common design mistake: expecting whichever component is easiest to connect to perform every part of the analysis. A search result may supply relevant context while leaving the arithmetic unresolved. An accurate forecast may still leave the cause of a past event unknown.
| Question | Operation | What to check |
|---|---|---|
| What was the total? | Filter and aggregate | Units, period, missing values |
| When did it change? | Compare defined windows | Reference period and sampling |
| What explains the change? | Inspect corroborating records | Timing, identity, alternatives |
| What happens next? | Forecast a defined target | Held-out error and uncertainty |
An exact question should produce an exact calculation
For a request such as the appliance-energy reading at 18:50 on 16 January 2016, the core operation is a lookup. Select the right entity and timestamp, return the value and unit, and preserve a link to the source. An agent may translate the request into a query, but the database should supply the number.
Our replay asks a slightly richer numerical question: find the three consecutive readings with the largest sum in the selected week. A window function or a short script can enumerate the candidate groups. The recorded maximum is 2,390 Wh across readings of 560, 1,080, and 750 Wh. No language model is needed for that calculation. 2
Query correctness still depends on the data contract. A three-row window means three intervals only after checking ordering, duplicates, and sampling gaps. Energy and power need different aggregations. The selected period must be explicit. These details belong in the tool's validation and returned evidence, so the agent does not have to guess them from a column name.
A change needs a reference
Now ask whether energy usage increased. We need a comparison: the previous reading, the previous hour, the same time yesterday, or a baseline adjusted for operating conditions. Choosing among them is part of defining the question. It should be visible in the answer.
A largest-value query and a largest-change query can select different periods. The highest energy total may be sustained, expected operation. A sharp rise from a low starting point may remain small in absolute terms. Calling either event abnormal introduces an additional standard: what range of behavior should be expected under comparable conditions?
Simple differences, rolling statistics, and matched historical comparisons are useful starting points. More elaborate detectors need an evaluation showing that their extra complexity helps with the intended task. Preserve the readings around the event and the baseline used. A conclusion about a change is much easier to review when the reader can see both sides of the comparison.
An explanation needs context the meter may not contain
The next question is often why the selected event occurred. An aggregate energy meter cannot tell us which appliance ran or why someone switched it on. More analysis of the same three values will not create a missing operating record. At this point, the investigation needs additional sources.
Retrieval-augmented generation (RAG) supplies retrieved material to a language model as context for its answer. Retrieval can locate schedules, equipment descriptions, maintenance notes, or earlier incidents. Structured queries can connect those records to the right building and period. Similar wording alone is weak evidence: a note about another building, or about work completed after the event, may be highly relevant to the search phrase and irrelevant to this explanation.
OpenAI's account of its internal data agent offers a concrete example of combining these operations. The system uses table metadata, expert descriptions, organizational knowledge, and live queries. It evaluates generated SQL against expected results and lets users inspect the underlying data. That combination addresses several distinct sources of error. 3
For the building replay, a schedule would be a candidate source to investigate; we have not supplied one or established a device-level cause. If an explanation relies on an assumed schedule, it should state the assumption and request confirmation. A retrieved document becomes evidence only to the extent that it supports the particular claim being made.
A forecast answers a question about the future
Asking about tomorrow's energy use changes the task again. We need an issuance time, a forecast horizon, a target, and a definition of acceptable error. A forecast may use the building's history and information already available about tomorrow, such as an issued schedule. An evaluation must keep later observations outside that input.
A useful starting comparison might repeat a recent value or a comparable historical period. A time-series model earns its place by improving the relevant forecast against an appropriate baseline. Toto 2.0 is one public example of a model evaluated for forecasting across several benchmarks; those results concern predicted values under specified tests. They do not establish the cause of a particular building event. 4
The methods can also combine. Research on retrieval-augmented time-series forecasting investigates using related historical sequences to help a forecasting model. Retrieval is an operation that can support prediction as well as explanation. Choosing a forecasting model does not require excluding retrieval from the system. 5
Even when a model identifies a variable as useful for prediction, that does not by itself show what would happen if someone changed it. Physical cause and the effect of an intervention require further evidence. Keep that boundary visible when moving from a forecast to a recommendation.
Connect the methods through evidence someone can inspect
A practical investigation might begin with a query, use a comparison to locate a change, retrieve a relevant operating record, and ask a forecasting model about the next period. Each step should return an identifiable result, its scope, and the source or method supporting it. The final answer can then explain how those pieces fit together without pretending that they establish more than they do.
At Reific, we are working on making operational history usable in that process. The useful interface is a bounded question followed by relevant readings, context, and sources that an agent can inspect. It should also make missing evidence apparent, so the next step follows from the unresolved question.
Start with the simplest complete workflow for the actual job. Check numerical queries against known results, compare changes under an explicit baseline, review explanations for support, and evaluate forecasts on unseen periods. Add a component when it improves that workflow. A sophisticated diagram cannot substitute for an answer whose values and conclusions survive inspection.