Pre-aggregation has carried analytics for a decade. Rollup tables and materialized views work because human-authored dashboards ask the same questions on a predictable cadence — profile the query log, build the rollup, serve from it. But agents break the assumption the whole approach rests on: that you know the questions in advance.
The precompute playbook assumes a fixed question set
An agent answering a business question does not issue one query. It decomposes the question, inspects the schema, checks its own intermediate results, and revises — often across a dozen round trips before it returns an answer.
That changes the workload in ways precomputation cannot absorb:
- Unbounded query shapes — An agent joins whichever tables the question implies, not the three you modeled a rollup around. Covering the long tail would take a combinatorial number of views.
- Runtime-decided filters — Predicates come from conversation context, so grouping columns and filter cardinality are unknown at the moment the view is defined.
- Freshness pulling against the rollup — Every refresh cycle inserts latency between an event landing and becoming answerable. Agents acting on live state need the opposite.
- Bursty fan-out — One user request expands into tens of concurrent queries, producing a spiky concurrency profile rather than the steady trickle dashboards generate.
- Compounding maintenance — Each view is another object to refresh, monitor, and invalidate whenever an upstream schema changes.
Any one of these is survivable. Together they mean the precomputed layer is permanently chasing a query distribution it cannot observe ahead of time; the hit rate collapses precisely when the agent asks something new, which is the entire reason to run an agent.
Optimize the engine, not the query shape
Instead of narrowing the workload until the engine can serve it, the engine should execute the query the agent actually wrote. That means treating a multi-table join over a normalized schema as the default path, not the fallback.
The principle is straightforward: precomputation becomes an optional accelerator for the heaviest repeat patterns rather than the precondition for acceptable latency.
Three engine properties make that practical.
What the engine has to do instead
Join normalized data at query time
A cost-based optimizer that reorders joins, pushes predicates down, and generates runtime filters keeps multi-table queries from degrading into full scans. Denormalizing to dodge joins is what starts the rollup treadmill in the first place.
A question such as "which enterprise accounts increased spend after their last P1 escalation" produces SQL nobody pre-modeled:
SELECT a.account_name,
SUM(o.amount) AS spend_after,
COUNT(DISTINCT t.ticket_id) AS escalations
FROM orders o
JOIN accounts a ON a.account_id = o.account_id
JOIN tickets t ON t.account_id = o.account_id
WHERE t.severity = 'P1'
AND o.created_at > t.escalated_at
AND a.segment = 'enterprise'
GROUP BY a.account_name
ORDER BY spend_after DESC
LIMIT 50;Nothing about this query is exotic. It is also not a query anyone would have built a materialized view for.
Keep mutable data queryable within seconds
Primary Key tables with native Kafka and Flink CDC ingestion make mutable rows — updates and deletes included — queryable seconds after they land. No refresh step sits between the event and the answer.
Isolate agent traffic from everything else
Agent fan-out and nightly ETL contend for the same CPU unless something separates them. Multi-warehouse workload isolation gives agent queries dedicated compute over the same data, so a spike in agent concurrency does not push BI or ingestion past its SLA.
In practice, these three properties compose. The result is an engine that absorbs unpredictable query shapes at the concurrency agents generate, without a modeling layer standing in front of it.
Evidence from production
Teams running this pattern report the same outcome: the modeling layer shrinks.
- Verisoul — moved off BigQuery and serves sub-100ms queries on real-time mutable data with no pre-aggregation.
- Celonis — runs 20-billion-row queries with more than 100 joins on its process mining platform.
- Demandbase — consolidated 49 clusters into one and cut storage by 90% by normalizing instead of maintaining denormalized copies.
The common thread is not raw scan speed. Each team stopped shaping data around a fixed set of questions — which is exactly the constraint an agent cannot operate within.
Where this leaves you
Agents are a workload, not a feature: unpredictable query shapes, second-level freshness requirements, and bursty concurrency arriving together. An analytical engine that executes complex SQL directly on normalized, fresh data lets agents ask what they need to ask, and keeps materialized views as an optimization you reach for rather than a dependency you build on. Start a free trial and point your own agent workload at it.