Can a local AI team help utilities question their smart-meter data?

Which electricity meters stopped reporting regularly? Where did voltage fall below a specified threshold? For utility staff, these are practical questions. Answering them can nevertheless require navigating millions of records, unfamiliar table layouts and SQL, the language used to query databases.

In a November 2026 preprint, Carlos Martín-Abellán and Mark Kröll present OpenMeter, a system that translates natural-language questions into database queries and explanatory responses. Their results suggest that dividing the work among specialized AI roles can help a smaller, locally operated language model. They also show why a working query, a correct answer and a convincing explanation must be judged separately.

A division of labour

OpenMeter uses three AI roles, all powered by the same underlying model. An orchestrator first classifies the question, prepares an execution plan and selects relevant domain guidance. A coding agent then generates SQL for DuckDB, a database engine. Finally, an interpretation agent explains the returned results.

The domain guidance includes a smart-metering glossary and rules informed by electricity standards and expert knowledge. Rather than passing every rule to every agent, the orchestrator selects material relevant to the question and, later, to the retrieved results.

The authors describe a read-only, sandboxed execution environment without network or filesystem access. If SQL fails to execute, an optional repair loop gives the coding agent the database’s error message and allows up to two retries. SQL performs the analysis; optional Python code produces charts.

That repair mechanism has an important boundary: it responds to execution errors. A query that runs successfully but calculates the wrong quantity does not automatically trigger another attempt.

Testing against industrial records

The evaluation used three measurement tables from one industrial partner, containing approximately 7.5 million rows. Measurements arrived at 10- or 15-minute intervals, and the tables used different layouts. The researchers retained outages, counter resets and other real-world irregularities rather than cleaning them away.

They constructed 62 manually verified question-and-SQL pairs from 39 question templates. Thirteen pairs supported prompt refinement and debugging; the remaining 49 formed the reported evaluation. Each configuration was tested across five runs.

Six configurations compared a single agent with the three-role pipeline, switching error repair and domain guidance on or off. One hardware tier ran a nine-billion-parameter Qwen3.5 model locally on an RTX A5000 GPU with 24 GB of graphics memory. The other used a much larger Qwen3.5 mixture-of-experts model through Ollama Cloud.

The main accuracy measure, called relaxed execution accuracy, compared generated results with reference results. It ignored column names and ordering and allowed extra columns, but still required matching values and row counts. It therefore measured something more useful than reproducing identical SQL, although it was not a comprehensive test of operational correctness.

A local gain with a substantial cost

On local hardware, the fully enabled multi-agent system achieved 42.4% relaxed execution accuracy, compared with 36.3% for the strongest single-agent configuration. That is a gain of 6.1 percentage points—not evidence that the system reliably answered most questions. Even the best local configuration failed this automated correctness measure more often than it passed.

The local full system produced executable SQL in 74.7% of cases, illustrating the gap between code that runs and code that answers the intended question.

The accuracy gain also required patience. Median response time rose from 31.9 seconds for the single agent with repair to 183.1 seconds for the full pipeline: roughly half a minute versus three minutes.

The larger cloud model showed a different pattern. The simplest single-agent configuration achieved the highest relaxed accuracy, 54.7%, while the full pipeline reached 53.1%. Selective domain guidance helped on stricter result-matching measures, but adding every component did not deliver a consistent advantage.

Privacy and reliability remain separate questions

Local execution offers a concrete privacy benefit: queries and consumption records need not be sent to an external model provider. However, the study was not exclusively local. Its cloud experiments transmitted data after anonymizing personally identifiable information. Those experiments should not be confused with the on-premises arrangement, and the paper does not establish that anonymization eliminates re-identification risk.

Explanation quality was also less clear-cut than automated scores suggested. Human reviewers found similar factual groundedness for the strongest single-agent and full multi-agent configurations. Agreement between reviewers was low, and human assessment used selected questions and each configuration’s best-performing run.

The evidence remains limited to one operator, one model family and a small held-out question set. The preprint supports a narrower conclusion than autonomous grid analysis: specialized AI roles may improve local database assistance when cloud access is undesirable, but their extra latency and substantial remaining error rate make independent checking essential.