Original · Unique Research · 2026-06-07
Editor's note: The first-person report and its judgments belong to the original Chinese author. This English rendition retains the complete narrative analysis, all three customer scenarios, six database roles, the TiDB Agent State Layer three-layer architecture, Agentic Scale discussion, data governance, HTAP, APAC market analysis, closing reflection, and the full 10-question Q&A. All named speakers, companies, numbers and claims are preserved. Company, personal and product names are transliterated where official English forms remain unverified. Market projections, performance claims and company-specific figures are source or speaker attributions, not independently verified findings.
AI Industry Observation
The Database in the AI Era: From a Backend "Data Warehouse" to an Agent's "Operating System"
The core contradiction of enterprise AI is not whether there is a large model, but whether data can be called by Agents securely, in real time, at low cost, and governably
"
Your AI Agent performs perfectly in the Demo. It can answer customer questions, retrieve knowledge bases, and generate beautifully formatted reports. Then you connect it to a real business system.
Your AI Agent performs perfectly in the Demo. It can answer customer questions, retrieve knowledge bases, and generate beautifully formatted reports. Then you connect it to a real business system.
On the first day, based on yesterday's inventory data, it refunded a customer for a product that had already been delisted. On the second day, it forgot the process it had just approved that morning and resubmitted it again. On the third day, the security team found it had read customer information it shouldn't have, without leaving any operation records.
The model is smart. The problem lies elsewhere.
Li Lux (李粒), APAC AI Business & Product Leader at PingCAP TiDB, gave a more precise judgment: "The core contradiction of enterprise AI is not whether there is a large model, but whether enterprise data can be called by Agents securely, in real time, at low cost, and governably."
I chatted with Li Lux for nearly two hours. He repeatedly mentioned one term: State Layer. He believes the real bottleneck for AI applications moving from Demo to production lies not in model parameters or inference speed, but in the fact that no one has prepared a reliable data state layer for Agents.
After AI Succeeds, the Problems Truly Begin
Li Lux shared three scenarios he repeatedly sees among customers.
Scenario 1: After AI products explode, the data layer is the first to buckle.
An AI-native company's product launched and users grew rapidly. At first, the team focused most on model inference capability and user experience. But as scale grew, what truly became tight was not the model, but the ongoing data pressure from user states, session records, context, task history and analysis needs.
"Many systems can hold up the early stage through sharding, caching and offline analysis," Li Lux said. "But as scale continues to grow, the data chain becomes increasingly complex: transaction data in one place, analysis data in another, logs in another, user states in yet another. It can run in the short term, but in the long term it's an operations nightmare."
Scenario 2: Agents create databases themselves, and humans can't keep up.
Another category of AI applications has a more radical trend. Agents no longer merely query databases—they create applications themselves, generate schemas, and read/write data. When AI shifts from "using tools" to "creating tools," the requirements placed on databases are completely different.
It must be simple enough for Agents to easily call. It must be elastic enough to support the rapid startup of a large number of short-lived workspaces. It must have isolation capabilities so different Agents and applications don't affect each other. And it must be low-cost enough, because many databases created by Agents may only survive for a few hours.
Scenario 3: Context gets shattered.
There's another category of AI hardware and productivity tool companies. Behind a recording device, there may simultaneously exist audio files, transcribed text, meeting summaries, task items, user tags, team knowledge bases and sharing permissions. Many teams put these things separately in object storage, vector databases, business databases, search engines and data warehouses.
"This is natural in the early stage, but when an Agent needs to answer 'what changes in customer risk mentioned in this meeting compared to last time,' it gets stuck," Li Lux said. "This isn't a pure vector retrieval problem, nor a pure SQL problem. It needs to simultaneously understand files, text, structured business data, historical memory and real-time state."
Three stories point to the same conclusion: after AI Demos enter production environments, the most common bottleneck is not that the model isn't strong enough, but the lack of a unified, real-time, governable state layer.
Databases Are No Longer Warehouses
In traditional applications, the database's role is relatively clear: serving transactions, supporting analysis. Users click buttons, and the application writes orders, inventory, payments and logs. Processes are deterministic, paths are fixed.
Agents are different. They don't execute fixed processes—they continuously understand, plan, call tools, write state, and revise plans. Li Lux believes that in the Agent era, databases have at least six additional roles:
Runtime state center. Agent tasks, steps, plans, retries, failures and recoveries must all be persisted. Disconnection cannot mean losing the entire task chain.
Long-term memory system. User preferences, historical conversations, operation habits and business facts need to be distilled into retrievable, updatable memory.
Context assembly platform. Before each action, an Agent must assemble complete context from structured data, text, files, logs and historical tasks.
Workspace. Agents don't just chat. They generate code, reports, spreadsheets and configuration files—all of which need persistent storage and version management.
Permission and audit layer. Agents act on behalf of humans, and every access, write and call must be traceable.
Real-time analysis and feedback layer. Enterprises need to know how well Agents are performing, how much they cost, which tasks fail, and which processes can be optimized.
"So the database in the Agent era has essentially shifted from backend storage to an Agent's state operating system," Li Lux said.
If Not Necessary, Do Not Multiply Entities
The other side of the judgment is: many enterprises, when building AI applications, split their data systems into more and more pieces.
Business state in MySQL, documents in object storage, vectors in Pinecone or Milvus, search in Elasticsearch, analysis in Snowflake, task state in Redis or Postgres. Every time an Agent completes a task, it must stitch together context across many systems.
Li Lux used Occam's razor to summarize this problem: "If not necessary, do not multiply entities."
He listed five costs brought by data fragmentation: complex data replication, degraded consistency, difficult unified permissions, runaway costs, and exponentially rising engineering complexity. "In the Demo stage you can bolt together components; in production, every chain needs monitoring, retry, audit and recovery. The more systems, the more chains, the harder to manage."
Meaning Similarity vs. Fact Accuracy
On the matter of retrieval, Li Lux proposed a very practical distinction.
Vector search is suitable for finding content with "similar meaning." A user asks about "refund rules," and the system can find "return policy" and "after-sales terms." But enterprise scenarios also have a large amount of content that must match precisely: order numbers, contract numbers, SKUs, device IDs, error codes, version numbers, legal clause numbers. Semantic similarity can't help here.
"Vector search solves 'meaning similarity,' full-text search solves 'fact accuracy,' and hybrid search solves whether enterprise AI can truly be trustworthy."
TiDB's hybrid search workflow uses both full-text search and vector search simultaneously, then merges results through a reranker. This isn't a technical detail—it's a key step for enterprise AI to move from "can answer" to "trustworthy."
From RAG to Agent State Layer
Many enterprise AI evolution paths are similar.
The first stage builds chatbots, focusing on whether answers are fluent and interfaces are user-friendly. The second stage builds knowledge bases and RAG, starting to discover problems with retrieval quality, document updates, permission isolation and knowledge expiration. The third stage lets Agents execute business tasks—and only then do backend data architecture problems truly surface.
"When AI moves from 'answering questions' to 'completing tasks,' enterprises will realize the real problem lies in data architecture," Li Lux said.
RAG can help Agents find relevant documents. But for an Agent to complete a business task, it also needs to query real-time order status, read data according to user permissions, write to CRM or ticketing systems, save intermediate task states, remember user preferences, manage generated files and artifacts, and recover after failure.
None of these are problems RAG can solve.
Not a Universal Database, but the Core Entry Point of the State Layer
The TiDB Agent State Layer proposed by Li Lux is not a new packaging of a "universal database." Understanding it requires looking at three layers.
The first layer is TiDB's existing base capabilities. Distributed SQL, transaction consistency, HTAP (Hybrid Transactional/Analytical Processing), vector search, full-text search, hybrid search. These are hard capabilities the database itself can directly deliver.
The second layer is an Agent-oriented architecture paradigm. Metadata manages Agents, tasks, steps, runtime states and audit records; AgentDB is each Agent's own long-term data space; Memory is responsible for long-term memory, preferences, historical behavior and fact extraction. These are more about "how to use TiDB to carry Agent state"—a set of architectural methodology.
The third layer is peripheral systems that need integration. Original files, large object storage, model services, embedding services, rerankers, workflow orchestration, existing enterprise permission systems. These are not what TiDB aims to replace, but to collaborate with.
Li Lux himself repeatedly emphasized this boundary: "We're not saying TiDB will replace all systems, but that it should become the core and integration entry point of the Agent State Layer."
What TiDB truly wants to compete for is the most core layer after Agent productionization: the unified entry point for state, memory, context, task records, permission boundaries and real-time analysis. Files, models, workflows and object storage still exist, but every step of an Agent—"what it knows, what it did, whether it can recover, whether it can be audited"—needs a stable data state layer to absorb.
Take the scenario of AI application development platforms like Dify as an example. Knowledge base retrieval is not just "vectorize documents then do similarity recall." In real business, developers first need to filter by structured conditions such as tenant, application, knowledge base, permissions, tags and update time, then do semantic retrieval. TiDB's value is not just storing vectors, but putting SQL condition filtering and vector retrieval in the same data layer, reducing the complexity of multi-system integration.
For enterprises, the most direct benefit is not a single-point performance improvement, but making AI applications easier to enter production environments. Agents can query business state (using SQL), query context and memory (using vector, full-text and hybrid search), and do real-time analysis and decision-making (using HTAP analysis capabilities)—all in the same state layer. Only when these three capabilities are together can an Agent move from "can answer questions" to "can understand business, execute tasks, and continuously optimize."
When It's No Longer Humans Accessing the System
Li Lux repeatedly mentioned a concept: Agentic Scale.
In the past, the main users accessing systems were humans. Human click frequency is limited, and behavior paths are relatively fixed. In the future, systems will be accessed by large numbers of Agents. Behind one user there may be multiple Agents, and each Agent has multiple rounds of reasoning and tool calls.
"This will bring completely different database pressure," Li Lux said. Higher request frequency, more state writes, more complex data forms. Structured data, vectors, full text, files, logs and memory will be mixed together. Isolation requirements are stronger, and cost models are changing.
"In the past, we estimated resources by user access volume; now we need to estimate by Agent active time, task complexity, state write volume and context retrieval volume."
This is also why he believes "one agent, one database" makes sense: each Agent should have independent data boundaries and evolution space, rather than all Agents sharing one giant global state pool.
Data Governance: From Managing Humans to Managing Agents
The deeper AI Agents go into business, the higher the complexity of data governance.
Traditional data governance mainly manages humans: who can view which tables, who can export which data. In the Agent era, the governance object becomes the combination of "human + Agent + tool + action."
Enterprises need to answer a string of new questions. Whom does this Agent represent? What data can it access? Can it write to production systems? Which actions require human confirmation? Can every operation be audited? Can generated files, conclusions and memories be deleted, rolled back and explained?
"The deeper Agents go into business, the more data governance cannot just manage data itself—it must manage how Agents understand, call and change data."
HTAP: Letting Agents Participate in Business as It Happens
Industries such as finance, e-commerce, logistics and manufacturing share a common characteristic: business state changes rapidly, while simultaneously requiring real-time analysis. Traditional architectures separate transaction systems and analysis systems—transactions go to OLTP, analysis to data warehouses.
But Agents can't wait hours for offline synchronization before seeing analysis results. They need to understand state, make judgments and execute actions while business is happening.
TiDB's HTAP capability brings transaction data and analysis closer together, reducing the latency and complex synchronization between transaction databases and analysis systems. Agents can simultaneously read real-time order and inventory status, analyze trends and anomalies, and execute within the business closed loop.
"HTAP lets Agents not just analyze business after the fact, but participate in business while it's happening."
APAC Market: Don't Talk Concepts—Tell Me If It Can Run
As PingCAP TiDB's APAC AI Business & Product Leader, Li Lux's feeling about the APAC market is: extremely pragmatic.
"Many enterprises don't do AI for the sake of 'doing an AI project,'" he said. "They'll directly ask: Can it reduce costs? Can it improve efficiency? Can it launch faster? Can it run within compliance boundaries? Can it integrate with existing systems?"
Compared with Europe and America, APAC enterprises focus more on landing speed and business results, and are more cost-sensitive. Large enterprises emphasize security, compliance and local deployment; internet and AI-native companies value speed, elasticity and architectural simplification.
He observes that APAC enterprise demand is going through three stages.
Stage 1: From model experience to business results. Initially focusing on model capabilities and chatbot effects, they quickly discover that simply answering questions doesn't create enough business value. What's truly valuable is AI entering real processes such as sales, customer service, operations and risk control.
Stage 2: From knowledge bases to real-time business systems. Starting with internal knowledge bases and document Q&A, which is relatively safe. Once Agents need to execute tasks, they must connect to orders, customers, inventory, contracts, tickets, payments and permissions. At this point RAG is just the entry point, and what the backend truly needs is a unified data state layer.
Stage 3: From single AI projects to production-grade platforms. After entering scale, cost, security, elasticity and operations complexity become core issues.
"Enterprises are moving from 'I want an AI feature' to 'I want a data foundation that can support AI running continuously.'"
The industries with the earliest awareness are internet and AI-native companies, which first encounter Agent high concurrency, state management and isolation problems. Next is finance, with high requirements for consistency, permissions, audit and real-time risk control. Then e-commerce and logistics, with high-frequency transactions and real-time inventory. Further out are manufacturing and large enterprises.
On globalization, Asian AI enterprises simultaneously face three major challenges: rapid business growth, wide market distribution, and high cost pressure. Globalizing AI applications is not just deploying models—it also requires deploying memory, state, files, permissions and business data. Open source brings controllability, cloud-native brings elasticity, and distributed databases bring cross-regional capability.
In Closing
I asked Li Lux: In the next three years, what will be the biggest change AI brings to the database industry?
His answer was not a specific feature. Vector capabilities will become standard, databases and search will continue to converge, and real-time analysis will become more important. But the bigger change is at the role level: databases will shift from backend storage systems for applications to context operating systems for Agents.
In the future, Agents won't just ask databases "what is this data." They will continuously press: What state am I in now? What are the user's preferences? What step is the task at? Which files can I use? Which memories are trustworthy? Is the business data up to date? What action can I take next? How do I update state after completion?
"Models let AI think, Agents let AI act, and the TiDB Agent State Layer lets AI remember accurately, see precisely, run stably, and be governed."
Whether or not you're optimistic about TiDB's solution, one trend judgment may be uncontroversial: the next stage of enterprise AI is not adding a vector field to a database, but building a state layer for Agents.
Who builds it, how to build it, what to build it with? These questions are worth every team pushing AI from Demo to production thinking carefully about.
Selected Q&A
Q: Without using the official introduction, how would you explain what you're doing to an enterprise client unfamiliar with TiDB?
We're helping enterprises truly run AI applications into production environments. Models are responsible for thinking, Agents for acting, and TiDB is responsible for reliably managing all context, state, memory, files, business data and analysis data. AI doesn't just need a smart brain—it also needs long-term memory, a workbench, task records, permission boundaries and real-time business state. TiDB does this "data foundation for AI applications."
Q: In the past, when people talked about AI, the first reaction was models, computing power, applications. Why do you think data infrastructure will become core again?
Because after AI applications move from Demo to production, the bottleneck shifts from "can the model answer" to "can the Agent get the right data, understand the current state, execute actions and leave traceable records." When enterprises truly go live, the questions become: Does it know who I am? Does it know the current business state? Does it know which data can and can't be seen? Can it recover if it executes wrongly? Can the results be audited? None of these can be solved by model parameters alone.
Q: How does the database AI Agents need differ from what traditional applications need?
Traditional databases serve deterministic systems. AI Agents continuously understand, plan, call tools, write state and revise plans. So they need to support long-term evolution. The more natural future model is one agent, one database—letting each Agent have independent data boundaries and evolution space. They need to support multimodal context—not just tables, but also documents, code, audio transcripts, image descriptions, vectors, files and task logs. They need to support real-time state. They need to support integrated search, analysis and files.
Q: What is the value of hybrid search in enterprise AI applications?
Enterprise scenarios have a large amount of content that must match precisely: order numbers, contract numbers, SKUs, device IDs, error codes, version numbers, legal clause numbers. Vector search solves "meaning similarity," full-text search solves "fact accuracy," and hybrid search solves whether enterprise AI can truly be trustworthy.
Q: What do you think about the direction of "context platform for AI applications"?
The scarcest thing in future AI applications is not model calls, but context organization capability. Whoever can organize an enterprise's business state, user memory, files, permissions, historical tasks and analysis results into context callable by Agents will capture the core entry point of AI applications. Databases will shift from backend systems to context platforms for AI applications. It's not just passive storage—it actively answers: Who is this Agent currently? What task is it doing? What data can it access? What has it learned in the past? What context does it need next?
Q: If Agents are to execute business tasks, how high are the requirements for data consistency, real-time performance and traceability?
Much higher. If AI only answers "what is the company's reimbursement policy," being wrong is at most an experience issue. But if an Agent is to execute "help me apply for a refund," "help me modify an order," "help me trigger a payment," it enters the core flow of the business system. In the Agent State Layer, Metadata is very important—it must record the Agent's Job, Step, Tool Call, Human Approval, Sandbox Lease, Retry, Rollback and Audit Trail. Without this layer, it's hard for Agents to move from toys to production.
Q: What new challenges will Agentic scale bring to data infrastructure?
In the past, the main users accessing systems were humans, with limited click frequency. In the future, systems will be accessed by large numbers of Agents. Higher request frequency, more state writes, more complex data forms, stronger isolation requirements, and changing cost models. In the past we estimated by user access volume; now we need to estimate by Agent active time, task complexity and state write volume. Future databases need to support not just user scale, but agent scale.
Q: How should enterprises rethink data governance when deploying AI Agents?
In the past, data governance mainly managed humans: who can view which tables. In the Agent era, we need to manage "human + Agent + tool + action." Enterprises need to answer: Whom does this Agent represent? What data can it access? Can it write to production systems? Which actions require human approval? Can every step be audited? Can generated files, conclusions and memories be deleted, rolled back and explained? Data governance is no longer just data catalogs and permission configuration—it's the runtime governance of Agents.
Q: When will enterprises realize that the real problem is not frontend interaction, but backend data architecture?
Usually in the third stage. The first stage builds chatbots, focusing on fluency. The second stage builds knowledge bases and RAG, discovering retrieval quality and permission issues. The third stage lets Agents execute business tasks—such as querying real-time orders, writing to CRM, managing file artifacts, and recovering after failure. At this point, enterprises discover that the frontend chat box is just the entry point, and what truly determines whether AI can be productionized is the backend State Layer.
Q: In the next three years, what will be the biggest change AI brings to the database industry?
Databases will shift from backend storage systems for applications to context operating systems for Agents. In the future, Agents won't just ask databases "what is this data"—they will continuously press: What state am I in now? What are the user's preferences? What step is the task at? Which files are available? Which memories are trustworthy? Is the business data up to date? What do I do next? How do I update state after completion? Truly valuable databases are not just those that support vector, but those that can become an Agent State Layer.