How the Agent Paradigm Is Redefining Enterprise Data Infrastructure

01 The Agent Era Is Arriving

In the past year, the concept of an Agent has moved from a technical idea to the primary entry point for enterprise intelligence. Like the Web unified many protocols under a single URL and browser, Agents unify the interface between humans and capabilities: users state goals, and the Agent interprets intent, decomposes tasks, selects tools, accesses data, and executes the workflow.

02 Three Software Forms: Rules, Training, and Agentic Control

Software has evolved through three stages. The first stage relied on explicit rules coded by engineers, with relational databases storing state and guaranteeing transactional stability. The second stage introduced data‑driven intelligence: massive datasets fed into models for prediction, recommendation, and recognition, giving rise to the Lakehouse that combined SQL/BI with Spark or PyTorch for training (e.g., Databricks, Snowflake). The third stage, driven by pre‑trained large language models (OpenAI, Anthropic, Google), shifts the workflow from data‑clean‑feature‑train‑deploy to feeding the most relevant context to an Agent at inference time, typically within 200 ms.

03 Lakehouse Assumptions Are Cracking

The classic Lakehouse promise—"one data, two uses"—assumes the same Parquet files can serve both batch analytics and model training. In the Agent era this assumption weakens. Training and inference have different data requirements: batch processing favors large‑scale scans, while Agents need point lookups, filters, aggregations, vector and full‑text search within a single conversational turn. Latency matters: a 200 ms query is acceptable, but a 3‑second query makes an Agent appear unresponsive. Moreover, the need for shared data diminishes as enterprises rely more on pre‑trained models rather than custom‑trained ones; data scientists now prefer hot, semantically rich data over cold Parquet files.

04 Real‑Time Analytics Engines Become the Data Core

When the primary consumer of data shifts from humans to intelligent agents, the architecture of analytical databases must prioritize sub‑second latency, fine‑grained indexing (Short Key Index, ZoneMap, Bloom Filter, inverted index), and row‑level data pruning. Hybrid retrieval—combining SQL, vector similarity, and full‑text search in a single query plan—is essential because an Agent may perform a point lookup, then an aggregation, followed by a vector search, and finally a keyword search to gather evidence. Existing ecosystems are fragmented: Pinecone excels at vector search but lacks SQL; Elasticsearch offers keyword search but limited real‑time aggregation; traditional warehouses excel at batch analytics but not low‑latency mixed queries. A unified engine that schedules these capabilities together is needed; Doris/SelectDB is cited as investing in this direction.

05 Not Replacement, but Layering

The article stresses that real‑time OLAP engines do not replace Lakehouses; instead, the data stack is re‑layered. Hot data resides in real‑time OLAP systems such as Doris/SelectDB or ClickHouse to serve Agent queries with millisecond response times. Cold data remains in Lakehouses built on object storage for long‑term archival, compliance, and historical analytics. This layered architecture balances the need for rapid, concurrent Agent queries (potentially 100‑1000× higher than traditional analyst workloads) with cost‑effective storage for massive, infrequently accessed datasets.

06 Conclusion

Agents are reshaping the application layer, and real‑time analysis engines are becoming the critical data entry point in the Agent era. As Agents proliferate across customer service, operations, BI, and knowledge‑base scenarios, enterprises will demand sub‑second latency, high concurrency, hybrid retrieval, semantic schema support, and elastic, low‑cost scaling. Doris/SelectDB and ClickHouse are positioned to become default components of next‑generation intelligent data architectures.

Example schema name: ods_usr_bhvr_pv_log_di illustrates how traditional table identifiers are easy for humans but hard for Agents to parse without semantic enrichment.