AI agents that generate analytical code and read files from object storage still require traditional SQL engines to produce trustworthy results, according to a technical analysis published on InfoQ examining disaster-recovery automation. The report, written by engineer Peihao Yuan, argues that artificial intelligence changes the analytical interface and interpretation layer but doesn't eliminate the need for precise computation. The core finding: deterministic engines should filter, aggregate, and join data, while agents should interpret evidence and communicate conclusions.
The analysis drew on a real-world disaster-recovery exercise that processed 1,127,748 metric rows across 1,523 services, stored as approximately 3.8 megabytes of compressed Parquet data in object storage. The workflow used DuckDB, an embedded SQL engine, for deterministic aggregation and an AI agent to classify failover outcomes. Metrics were collected at thirty-second resolution, with upstream collection across all services taking roughly an hour using concurrent workers. The system evaluated three questions for every service: whether the surviving region absorbed traffic from the isolated region, whether the service remained available after absorbing traffic, and whether latency stayed within acceptable range or showed sustained degradation under additional load.
The report introduces what Yuan calls the "determinism split"—a separation between exact computation and contextual reasoning. Filtering, aggregation, joins, sorting, and window calculations belong to the engine, producing exact and reproducible numerical results. Selecting relevant evidence, classifying failover behavior, and suggesting investigation paths belong to the AI agent. The analysis warns against a common anti-pattern: using a language model as a query engine. "A language model should not read hundreds of thousands of rows and calculate an error count, percentile, or average," the report states, calling that approach slow, expensive in tokens, and difficult to reproduce.
The architecture deliberately avoided a shared lakehouse because the workload didn't yet require one. An embedded engine proved sufficient when data volume was moderate, the primary consumer was the agent workflow, and writes were controlled. The report identifies four signals that indicate when a lightweight architecture encounters pressure and a managed lakehouse becomes valuable: when independent consumers such as dashboards or scheduled jobs need direct access, when data becomes too large to move to the agent environment, when the workflow must join with large shared datasets already registered in a catalog, and when concurrent writes or table-level evolution are required. Each signal points to a different capability—a catalog for shared discovery and governance, an open table format for safe concurrent writes and evolution, or a distributed query engine when computation must move closer to large shared datasets.
Production-grade agent analytics should retain the source data, configuration, derived facts, and model outputs so that every report can be validated and replayed, the report recommends. The workflow preserved a replay bundle containing Parquet inputs, manifests and checksums, exercise configuration, generated SQL or Python code, execution metadata, deterministic derived facts, model output, agent version and prompt, and model identifier. The report concludes that the main architectural trade-off isn't AI versus SQL or files versus tables, but rather how much analytical infrastructure needs to sit behind the agent for the workload at hand. "A small embedded engine may be sufficient for a focused workflow," Yuan writes, while shared catalogs, open table formats, and distributed engines should be introduced only as sharing, scale, write concurrency, or governance create a concrete need. Organizations building agent-driven analytics face a classic build-versus-buy tension that data teams have navigated for years, now reframed around which layer—interface or execution—the model actually transforms.