By Neil Kumar, Principal Product Manager at Ocient
For a decade, every data leader heard the same advice: pick best-of-breed per domain. Snowflake or BigQuery for OLAP. SageMaker or Databricks for ML. PostGIS for spatial. Neo4j for graph, a vector store like Pinecone for similarity. Fivetran and dbt for ingest. Stitch it together with a federation layer and you have a modern data stack.
That advice was right, because the integration was paid for once and reused. Application code and ETL pipelines stitched the systems together: pull keys from one store, look them up in another, join the results, land them somewhere. The access patterns were known in advance and stable, so the glue was written once and run a million times. The seams were real, but the cost of crossing them was amortized.
Agentic analytics breaks the amortization. An agent doesn’t run a known pattern; it decides its next query from the last result, so the integration can’t be pre-built. The agent re-derives that integration glue on the fly, every reasoning loop. Agents are good at writing that glue, but that was never where the cost lived. The cost is in the crossing itself: every boundary the agent spans is paid for live, in tokens, accuracy, latency, and scratch state, and a single question spans a lot of boundaries.
How agents actually work
An agentic analytics workflow doesn’t look like BI. When an agent takes on a business question like “why did churn spike in the Southeast last quarter?”, it doesn’t run one query. It decomposes the question, runs a sub-query, evaluates the result, branches, backtracks, and synthesizes. A single question routinely becomes a 10- to 30-query reasoning loop.
The workload shape is fundamentally different from dashboards: high amplification (one question, dozens of queries), exploratory (the agent doesn’t know the third query until it sees the second result), and cross-modal. A typical reasoning loop spans modalities: a cube or rollup over relational data, a geospatial filter, an ML score, graph analytics across a relationship network, a vector similarity search, and operational data that landed minutes ago. Six different shapes of analytics, and a single question routinely touches four or five of them before it converges.
A human ran this loop a few times a day. An agent runs it continuously, and fans sub-queries out in parallel wherever they don’t depend on each other. Speed was never the issue; frequency is. Every per-hop cost that was rounding error at human cadence becomes a line item when the loop never stops.
Why best-of-breed was rational
The stack didn’t happen by accident. Each tool is genuinely best-in-class at its job. Snowflake excels at OLAP. SageMaker handles ML at scale. PostGIS evaluates spatial predicates a general-purpose warehouse can’t touch. Neo4j walks graphs at depth; a dedicated vector store returns nearest neighbors in milliseconds.
The architecture worked because integration was a build-time problem, not a query-time one. An application pulled a keylist from one database, looked those keys up in another, and joined the results in code. A pipeline denormalized across systems on a schedule. The work was real, but it was written against known access patterns and amortized over millions of runs. Nobody paid the integration cost per query.
Agents move that cost to query time. The access pattern isn’t known until the agent is halfway through the loop, so there is no pipeline to amortize against. Each reasoning loop re-derives the integration the pipeline used to own, and pays for it in full, every time.
The modal tax: three faces
Agents don’t pay integration cost in time. They pay it three concrete ways on every hop.
The token tax. Every hop runs through the model’s context. The agent has to see enough of each result to decide the next step, so context grows turn over turn until compaction or a sliding window caps it. Past that point every call pays for a near-full context, and prompt caching reduces but doesn’t erase the bill. The compaction that bounds the cost is itself lossy: it drops or summarizes intermediate results the agent may need three steps later, which is the accuracy tax arriving early. Models also lose track of detail buried mid-context even when it is still present (Liu et al., 2023).
The accuracy tax. Predicates set in system A have no representation in system B’s query plan. The classic failure: the agent applies a geographic filter in the warehouse, then calls an ML scoring service that has no knowledge the filter exists. The service returns a number with the right shape and the wrong meaning. Benchmark work on multi-tool agents (AgentBench, ToolBench) documents exactly this class of failure. Agents degrade most where tools must share state they have no common way to express.
The latency tax. Independent steps parallelize and dependent steps stay serial no matter how many systems you run, so the latency tax isn’t about sequencing. It is the fixed cost on each hop: serialize the result, ship it across the network, re-plan and re-optimize in the next system, maybe wait out a cold start, then move the bytes back to be combined. In one engine an intermediate stays put and feeds the next operator directly. Across systems it makes a round trip on the wire every time, and the larger the intermediate, the more that trip costs.
The fourth tax: materialization
The framing most people miss: agents don’t just query. They write.
Agents save intermediate results so they can refer back without re-computing. They create scratch tables to keep multi-step reasoning coherent. They branch environments to test alternative paths without disturbing anything. The well-built ones don’t dump results into the prompt; they write them to a file or a table and pass a reference. That is the right move, and it is exactly where the cost hides: the reference points to data sitting outside any engine, with no schema, no index, and no way to join it against anything else without hauling it back in.
This is not a niche behavior. Databricks’s 2026 State of AI Agents report, built on aggregated data from more than 20,000 organizations including over 60% of the Fortune 500, found that on Neon, the Postgres layer behind Databricks Lakebase, 80% of databases are now created by AI agents, up from 0.1% in October 2023. Database branches, the isolated test and dev environments, went from 0.1% to 97% agent-created over the same period. Agents took over an entire infrastructure function in two years.
In a best-of-breed stack, materialization compounds the modal tax. The agent cannot create a scratch table that joins ML features, geospatial data, graph-derived signals, and vector matches against freshly loaded operational records, because no single system in the stack handles all of them. So the agent shuttles cross-modality state through external lookup tables, manifests, pointer files, or worst of all, through its own context window. That is a fourth tax stacked on top of token, accuracy, and latency.
Why consolidating onto a warehouse doesn’t solve this
The obvious response: fine, consolidate everything onto the warehouse.
Consolidation onto an OLAP warehouse collapses the analytics half of the stack, and only that half. The warehouse still doesn’t run native ML inference at scale on petabytes of features. It doesn’t do spatial indexing on coordinates the way PostGIS does. It doesn’t do streaming ingest with seconds-to-query latency the way an in-cluster loader does. Graph and vector, where the warehouse offers them at all, arrive as separate indexes or offloaded services rather than first-class operations over the same copy. And it doesn’t let an agent materialize scratch state across modalities, because there are no cross-modality semantics to materialize.
So even after consolidation, the agent still crosses two or three boundaries to answer a cross-modal question. The modal tax persists, and the materialization problem persists with it.
The structural fix is not fewer warehouses. It is one engine that runs every analytical modality the agent touches, over one owned copy, with the agent’s writes handled in the same place. That engine is the OcientAIQ™ Unified Data Platform, and it was built for exactly the workload that breaks everyone else.
How OcientAIQ removes the tax
On OcientAIQ, every predicate, join, modality, and intermediate materialization runs inside one engine. The agent submits a question, the engine resolves it server-side, and the agent’s working state lives in the same place as the data. Our position is simple: AI agents should use the LLM to reason, and the data platform to calculate.
This is where the six modalities collapse into one design choice. OcientAIQ runs all six as first-class, composable citizens in a single engine over a single copy: relational and OLAP, geospatial, ML through OcientML™, graph analytics, vector search, and real-time rollups. The language barely matters here: graph uses GQL and SQL, the rest are SQL, and all of it composes inside one native query plan, joinable like any other subquery. An agent can run graph analytics over a relationship network and a vector search for similar entities, then feed both into a relational analysis that scores with a model, filters by geography, and rolls the result into a cube. One statement, one engine, no exported intermediate, no second system to cross.
The mechanism underneath is what makes that real: OcientML trains and scores in-engine, OcientGeo™ provides secondary spatial indexing, graph runs over adjacency indexes, vector search runs approximate nearest-neighbor with filters and joins, in-cluster loading makes streaming data queryable within seconds, and Compute Adjacent Storage Architecture™ (CASA) on local NVMe serves both reads and the agent’s writes. Every one of these is an access path inside the same query plan, not a separate system the agent has to call. When there is no second system, there is no hop. And no hop means no tax. The architectural details are documented at docs.ocient.com.
One aside on economics, because it changes agent behavior rather than just the bill. OcientAIQ’s pricing is fixed: per-core, capacity-based, on-prem or dedicated cloud. Agents can explore, materialize, and iterate without each action invoking a meter. The exploratory behavior agents need to do their job stops being in tension with the cost structure of the platform they do it on.
The era is ending
Best-of-breed isn’t dead, and this post isn’t claiming it is. If you need the single fastest engine in one domain, a specialist will still beat a unified one, the way it always has. That tradeoff hasn’t changed.
What changed is the default for one specific, growing workload: an agent composing many modalities over the same data, at scale, in a loop that doesn’t stop. There the integration cost stops being a build-time line item you amortize and becomes a per-query tax you pay forever. That is when the unified engine wins, not because it is fastest at any one thing, but because nothing has to cross a boundary.
That is what OcientAIQ is built for. We run relational, geospatial, ML, graph, vector, and real-time analytics as composable operations over one copy of the data, at trillion-row scale, with the agent’s writes handled in the same place. A specialist might win a single benchmark. It can’t compose six modalities together over petabytes of data without the tax, and at that scale most of the alternatives can’t run the workload at all.
If this workload shape sounds familiar, talk to our team about what it looks like on OcientAIQ, or start with how we run AI on enterprise data. And watch for the next post, where we look at what happens when this workload pushes past what cache can absorb.
(Editor’s note: This is the first of two posts. The companion piece will pick up where this one ends and argues why these tradeoffs sharpen dramatically once your workload pushes past what cache can absorb.)