Data Agent Architecture: 7 Layers to Connect Enterprise Data Beyond Text-to-SQL

Many Data Agent projects start with a naive architecture: connect ERP, CRM, MES, databases, and data warehouses directly to a large language model and expect a chat interface to work. In practice, this quickly fails because the model cannot resolve fundamental ambiguities: which table defines "monthly sales" (orders, shipments, or financial revenue), how "East China region" is scoped (sales org, customer location, or shipping address), whether a regional manager can accidentally see other regions' data, and why the same profit metric yields 18% one day and 19.2% the next.

1. Design Data Entry Points, Not Just Database Connections

The first version of a Data Agent often lets the LLM read the database schema, generate SQL, execute it, and summarize results. This works for demos but collapses with hundreds or thousands of tables due to three problems:

Complexity: Orders scatter across order header, detail, refund, product, and customer tables; the model must infer joins.

Stability: A schema change (renamed column, altered business logic) breaks previously correct SQL overnight.

Performance: The model does not know which tables have billions of rows, which columns lack indexes, or which queries cause full scans.

Instead of a single database connection, enterprises should design layered data entry points :

Raw data entry – for data engineers and exploratory queries, accessing underlying databases and data lakes.

Analytical data entry – pre-built stable datasets, data marts, or subject models for orders, customers, inventory, revenue.

Business capability entry – high-level tools like "query sales metric," "get customer profile," "check inventory risk."

Higher layers restrict agent freedom but increase determinism. The principle: the more deterministic the business scenario, the more it should use pre-processed data; only exploratory questions should reach raw layers.

This shifts the work from "understanding data on every question" to "building stable data entry points upfront."

2. Build Business Objects, Not Just Tables

Databases store tables; business users talk about objects. CRM, ERP, and finance systems may each have a "customer" table with different names (e.g., "counterparty"). To the agent they are three entities; to the business they are one. Therefore, core business objects must be abstracted first:

Subject objects: customer, supplier, employee, organization, product, equipment.

Transaction objects: order, contract, procurement, payment, invoice.

Operating objects: revenue, cost, inventory, receivables, cash flow.

Stable relationships between objects must be pre-defined. For "customer profit" the agent needs to know: which orders belong to the customer, which products per order, revenue recognition rule, cost allocation method, expense apportionment. Relationships decidable via master data, data models, and business rules should not be re-inferred by the LLM on every query. The agent should reason about analysis direction , not which column to join on .

3. The Semantic Layer Is the Real Accuracy Differentiator

Clean data does not guarantee correct understanding. A database may contain "sales amount," "invoiced revenue," "shipment value," "financial revenue" simultaneously. When a user asks "How much did sales grow this year?" the agent must pick the right one. A semantic layer for Data Agents must store at least four categories:

Metrics

Dimensions

Business definitions (口径)

Metric relationships

For example, "sales revenue" must specify: data source, time field, tax inclusion, return deduction, included order statuses, granularity, applicable scenarios. Further, metric hierarchies enable drill-down:

Profit = Revenue − Cost

Revenue = Volume × Average Price

Volume = Customer Count × Purchase Frequency × Units per Purchase

When a user asks "Why did profit drop?" the agent follows the predefined logic: Profit → Revenue/Cost → Volume/Price → Customer/Product, instead of randomly searching dozens of fields. The key is to fix "what profit means" and let the agent judge "why profit dropped." The former is deterministic knowledge; the latter requires model reasoning.

4. Permissions Must Live in the Data Architecture, Not in Prompts

Enterprise Data Agents differ from public QA bots because they handle permissioned data. Examples: a salesperson sees only their customers; a regional manager sees their region; HQ sees all; staff see department costs but not individual salaries. Using a superuser database account and telling the model via prompt "don't answer unauthorized data" is not real permission control. Prompts govern model behavior ; permission systems govern physical data access .

At minimum, four permission layers are needed:

Data source permission – can this user connect to the source?

Object permission – can they use this table or metric?

Row permission – which organizations, regions, customers are visible?

Column permission – which sensitive fields can be returned?

Principle: The agent must never possess more data permissions than the current user. User identity must flow through the entire chain: Question → Agent → Tool Call → Data Query → Result Return. Otherwise the database always receives a superuser credential and permission control becomes a UI illusion.

5. Agents Should Call "Data Capabilities," Not Raw SQL

Early Text-to-SQL architectures expose a single execute_sql() tool. At enterprise scale this granularity is too low. Instead, encapsulate lower-level capabilities into higher-level tools: query_metric() – query standard metrics compare_period() – run YoY/MoM comparisons query_customer() – get customer business info drill_order() – drill into order details query_inventory_risk() – check inventory risks get_metric_definition() – retrieve metric definitions

The agent's task shifts from "figure out how to query the database" to "decide which data capabilities to invoke." For "Why did East China profit drop?" the agent might: call profit metric (finds −12%), decompose into revenue/cost, identify revenue as main driver, break down by region/product, pinpoint a specific product's volume decline. The execution chain becomes: Understand problem → Plan analysis → Call tools → Get data → Judge result → Decide next step → Output conclusion. This is a true agent, not just natural-language-to-SQL.

6. Add a Verification Layer Before Delivering Answers

Many architectures stop at answer generation. For finance, operations, supply chain, a result verification layer is mandatory, checking three things:

Data freshness: If the inventory table was last updated three days ago, the agent must not label the result "current inventory."

Numeric closure: If the agent attributes a ¥10M profit drop to three causes, the sum of their impacts should roughly match the total change.

Evidence-backed conclusions: "Sales volume fell" is directly provable; "market demand fell" requires external data, customer behavior, or sales feedback. Mature agents must distinguish facts, inferences, and hypotheses .

Proven facts are stated clearly; supported but unproven judgments are labeled; insufficient evidence triggers a request for more data. This capability—knowing when not to give a definitive answer—is crucial for enterprise adoption.

Conclusion: The Ceiling of a Data Agent Is the Underlying Data System

Superficially, a Data Agent looks like an AI project. Decomposed, most work remains traditional data architecture: data ingestion, cleansing, master data, modeling, metric definitions, permission management, lineage tracking, data quality. AI mainly changes the top interaction layer. Previously users found reports, picked metrics, analyzed manually; now they say "Analyze why East China profit dropped" and the agent orchestrates the analysis. The prerequisite never changes: there must be a trustworthy data system underneath.

A mature Data Agent architecture is not:

Business Systems → LLM

It is:

Business Systems → Data Preparation → Business Objects → Semantics & Metrics → Permission System → Data Tools → Agent → Verification

Deterministic knowledge is fixed upfront; only genuine judgment space is left to the agent. This is the core insight from a data architecture perspective: Don't make the LLM re-learn the enterprise's data; turn the enterprise's established data knowledge into callable capabilities for the agent. Only then does the agent evolve from a "chatbot that can query a database" into a true analytical entry point for enterprise operations.