Key Takeaways #
- The analytics stack was built for people to read data, not for agents to act on it. Every added system is another consistency gap.
- Agent loops on a warehouse are expensive. One EV-charging platform burned $50,000 in a day of testing and projected $130,000 a month at scale.
- One cluster changed the economics. On [TiDB], agent confidence rose from a 74% cold start to roughly 93%.- Keep the data plane and the context plane in one ACID boundary. Context assembly then runs in a single SQL query, with no loops.
- Write outcomes, not reasoning steps. Five custodial duties hold data quality as volume grows.
Real-time data has been the promise of the analytics stack for a decade. Dashboards refresh, pipelines run, and a human reads the result. That model holds right up until you ask an agent to act on the data instead of look at it.
At TiDB SCaiLE Europe 2026 in Stockholm, Bernard Kavanagh, Solutions Architect at TiDB, made the case that analytical agents break the stack business intelligence was built on. The session was not theoretical. It followed an EV-charging platform that tried to automate fleet maintenance, cost itself $50,000 in a single day of testing, and then ran the same workload on one TiDB cluster. This article covers why the BI stack cannot carry agentic workloads, what the single-cluster architecture changed, and the discipline it takes to keep agent confidence high. It is a companion to the multi-tenant agent database keynote and the Bolt MySQL migration session from the same event.
Why the BI Stack Cannot Run Analytical Agents #
The analytics stack was built for people to look at data, not for agents to act on it. For a decade, events from applications, payment systems, and IoT sensors have flowed through Kafka or Flink into a lakehouse, then through transformation tools, shaped tables, queries, and a dashboard or a spreadsheet. Every one of those steps was fine when the consumer was an analyst. It becomes a liability when the consumer is an autonomous agent that has to decide and act in real time.
The result is a Frankenstack. It is a BI pipeline held together with duct tape, then extended with the parts an agent needs: a vector database, embeddings, cosine-distance search, an orchestration layer, and agents plus sub-agents on top. Each addition is another system boundary, and each boundary carries a cost.
Every boundary is a place where the architecture leaks value. This is where the bill and the risk accumulate:
- Every boundary is a consistency gap between what one system knows and what the agent reads.
- Every boundary is another authentication protocol for the security team to manage.
- Every sync job has a cost, because data takes time to move and the systems are never fully in line.
- Every unjoined audit trail is a liability, which matters under the EU AI Act when the data is high-risk and public-facing.
For the workloads agents actually generate, real-time inference, hybrid semantic search, and single-query root-cause analysis, a warehouse cannot keep up. Root-cause analysis is the sharp example: when an agent produces a harmful outcome or a hallucination, the first question is what the agent saw when it decided, and a stack of disconnected systems cannot answer that in one query. The margin that data monetization depends on dies inside the stack. Bernard Kavanagh, Solutions Architect at TiDB
The $50,000 Bug: What Agent Loops Cost on a Warehouse #
The cost of getting this wrong is concrete. An EV-charging platform runs IoT telemetry from 20,000 charge points, 112 million events a day, and wanted to automate fleet maintenance. Error messages arrived from the field, Flink windowed them, an anomaly score landed in the database, an embedding was generated, and agents ran the investigation. Sync lag between those systems left the agents looping continuously. One day of testing cost $50,000. The team named it the $50,000 bug and shelved the project.
The economics did not improve at scale. The platform wants to grow from 20,000 chargers to 100,000, a 5x jump, and to sit in front of any procurement team and claim the most automated fleet-maintenance system in its market. After optimizing the workload on their existing stack, the projected cost to run it in production came to close to $130,000 a month. That number is what sent them to an A/B test against TiDB.
What Changed on a Single TiDB Cluster #
On TiDB, the same workload ran on one cluster with no session cache and no separate analytical warehouse. Vectors are a native data type in TiDB, so semantic search happens inside the database rather than in a bolted-on vector store. Because TiDB is a single ACID engine optimized for reads and writes together, an anomalous row can trigger an investigation, and a single SQL query can check whether a matching semantic memory already exists. When it does, the agent routes to a cheaper model instead of paying for a full investigation.
The confidence numbers tell the story of the A/B test. The agentic investigation started at a 74% confidence score from a cold start. After 21 investigations of warmup, as cold data turned warm, token cost fell and confidence climbed toward 99%, averaging roughly 93%. Same model, same telemetry, same prompt. The only variable that changed was the number of systems: one instead of six. For contrast, a team building coding agents that must pull context from Drive, Jira, Slack, and other fragmented sources reported confidence stuck around 60%.
The Data Plane and the Context Plane in One ACID Boundary #
The architecture behind those numbers is a single cluster with two planes. The data plane is the normal input: telemetry, events, and payments. The context plane is where the agent writes back to TiDB, in the same schema, inside the same ACID boundary. Because both planes share one transactional system, context assembly happens in a SQL query before the request reaches the model. There are no cross-system loops to assemble context, and removing those loops is what lifts the confidence score.
This is the pattern every database vendor is chasing when they talk about building memory for agents. An online transactional processing (OLTP) system that can read and write at the same time, with no sync job sitting between the data and the context, is the substrate that pattern needs. One cluster, one schema, one consistency boundary.
Five Custodial Duties That Keep Agent Confidence High #
High confidence is not automatic. It depends on what the agent is allowed to write and how that memory is maintained. Five custodial duties keep the data an agent reasons over clean, and they are the reason the engineer’s role grows rather than disappears. As the volume of analysis, observability, and traceability rises, the engineer who governs input and output quality becomes more central, not less.
The five duties work together:
Write control. Do not persist every ephemeral reasoning step. Write outcomes: confirmed, escalated, deferred, or flagged for review. This keeps a human in the loop and keeps the memory meaningful.Deduplication. Similar outcomes recur, because the same error message arrives more than once. Merge records that fall below a cosine distance of 15%.Compaction. Collapse many weak, similar memories into a few strong ones. Stronger memories raise the confidence of later analysis.Reconciliation. Keep the written record consistent as new outcomes arrive, so the context the agent reads stays trustworthy.Guarding against confidence decay. More context is not always better. Past a point, extra context lowers the security of the outcome, so the system prunes rather than hoards.
Serverless Branching, Native Vectors, and an Open-Source Context Plane #
Three TiDB capabilities make the single-cluster pattern practical. Hybrid transactional and analytical processing (HTAP)plus a native vector engine lets one system serve transactions, analytics, and semantic search. Database branching lets an engineer spin up a safe sandbox with human-verified outputs, change the rules, and test guardrails without touching production or standing up a separate QA environment, which shrinks the time to iterate. Elastic auto-scaling on AWS absorbs the bursty shape of agent workloads.
The deployment numbers underline the point. The EV-charging workload, 20,000 charge points and 112 million events a day, was written down to eight tables and nine agent tools, with a 3,600-token budget per investigation held in place by model routing. Model routing, sometimes called model weighting, sends each investigation to the cheapest capable model based on cost per invocation, whether that is a frontier model or a smaller one.
The talk closed with an invitation rather than a pitch. TiDB has open-sourced the context-plane code so teams can clone it, run it on their own clusters with the provided seed scripts, and open pull requests. The pattern is generic, and the ask to the room was to test it in production and send feedback so the use cases grow.
The Stack Was Built to Be Read, Not to Act #
The through-line of the session is a single claim. The analytics stack was designed for people to look at data, and agents need a system designed for acting on it. Bolting agent parts onto a warehouse multiplies boundaries, and every boundary costs consistency, security review, sync time, and audit integrity. Collapsing the workload onto one ACID cluster removed those boundaries, and agent confidence moved from 74% to roughly 93% as a result.
Every system boundary is another consistency gap.Bernard Kavanagh, Solutions Architect, TiDB
For teams staring at a Frankenstack and a rising agent bill, the takeaway is that the fix is architectural, not additive. Fewer systems, one consistency boundary, and disciplined memory beat another vector store and another sync job. Want to test the context plane on your own data? Spin up a free TiDB cluster, and run your own A/B test before you add another system to the stack.
Experience modern data infrastructure firsthand.
TiDB Cloud Dedicated #
A fully-managed cloud DBaaS for predictable workloads
TiDB Cloud Starter #
A fully-managed cloud DBaaS for auto-scaling workloads