DEV Community

ArisynData
ArisynData

Posted on

Why Every AI Agent Shouldn't Have to Rediscover Your Data Model

#ai #data #sql #llm

Enterprise AI is moving toward a multi-agent architecture.

Instead of one general-purpose assistant, organizations are starting to build specialized agents for:

  • sales;
  • finance;
  • operations;
  • customer support;
  • analytics;
  • management.

That creates an engineering problem that is easy to miss.

If every agent independently receives database schemas, retrieves metadata, learns metric definitions, discovers join paths, and builds its own interpretation of the business, then every new agent becomes another data-modeling project.

The result is not only duplicated engineering work.

It is duplicated enterprise understanding.

A better architecture is to separate agent reasoning from shared data intelligence.

## The Problem With Agent-Local Data Knowledge

A simple data agent often looks something like:

User
  ↓
Agent
  ├── System Prompt
  ├── Schema Retrieval
  ├── Metric Definitions
  ├── Join Instructions
  ├── SQL Tool
  └── LLM
        ↓
    Database
Enter fullscreen mode Exit fullscreen mode

For a single proof of concept, this is reasonable.

Now imagine five teams building five agents:

Sales Agent
Finance Agent
Supply Chain Agent
Support Agent
Analytics Agent
Enter fullscreen mode Exit fullscreen mode

Each team has to solve the same problems:

Which tables are relevant?

What does "Customer" mean?

Which definition of Revenue is authoritative?

How should Customer connect to Order?

Which data source should be trusted?
Enter fullscreen mode Exit fullscreen mode

The implementation may be different, but the underlying enterprise knowledge is largely the same.

If that knowledge lives inside each agent, duplication begins immediately.

## Example: Five Agents, Three Definitions of Revenue

Suppose an enterprise contains:

sales_order.total_amount
finance_invoice.invoice_amount
finance_revenue.recognized_amount
payment.received_amount
Enter fullscreen mode Exit fullscreen mode

A sales agent might map:

Revenue → sales_order.total_amount
Enter fullscreen mode Exit fullscreen mode

A finance agent might use:

Revenue → finance_revenue.recognized_amount
Enter fullscreen mode Exit fullscreen mode

An analytics agent might retrieve:

Revenue → finance_invoice.invoice_amount
Enter fullscreen mode Exit fullscreen mode

All three agents may generate syntactically correct SQL.

All three queries may execute successfully.

But the organization now has three AI systems answering the same business question differently.

The problem is not LLM reasoning.

The problem is that business meaning was implemented locally inside each agent.

## Business Knowledge Should Be an Enterprise Dependency

Agent-specific knowledge and enterprise-wide knowledge should be separated.

An agent may legitimately own:

  • task instructions;
  • workflow logic;
  • persona;
  • tool selection;
  • planning strategy.

But definitions such as these should not be duplicated:

Customer
Revenue
Active Customer
Inventory Balance
Gross Margin
Enter fullscreen mode Exit fullscreen mode

The same applies to data relationships:

Customer
   ↓
Order
   ↓
Invoice
   ↓
Payment
Enter fullscreen mode Exit fullscreen mode

These are enterprise data assets.

They should be reusable dependencies.

## Thick Agents vs. Thin Agents

A thick agent contains a large amount of enterprise-specific intelligence:

Agent
├── LLM
├── Business Semantics
├── Metrics
├── Schema Knowledge
├── Relationship Knowledge
├── Business Rules
├── Query Logic
└── Tools
Enter fullscreen mode Exit fullscreen mode

This creates coupling.

If the Revenue definition changes, multiple agents may need to change.

If a trusted join path changes, multiple prompts or tools may need to be updated.

If the organization switches models, important business knowledge may be buried inside model-specific implementation.

A thinner design looks different:

Agent
├── LLM
├── Task Logic
├── Planning
└── Tools
      ↓
Shared Data Intelligence
├── Business Semantics
├── Metrics & Dimensions
├── Metadata
├── Trusted Relationships
└── Query Context
      ↓
Enterprise Data
Enter fullscreen mode Exit fullscreen mode

Now the agent does not need to rediscover the enterprise every time it answers a question.

## What Should the Shared Data Layer Expose?

The shared layer does not have to be one monolithic service.

It can expose several reusable capabilities.

### 1. Metadata Retrieval

For example:

{
  "table": "sales_order",
  "columns": [
    "order_id",
    "customer_id",
    "order_date",
    "total_amount"
  ]
}
Enter fullscreen mode Exit fullscreen mode

But raw metadata alone is not enough.

### 2. Business Semantics

The agent should be able to resolve:

"recognized revenue"
Enter fullscreen mode Exit fullscreen mode

into something like:

metric: revenue
definition: recognized revenue
aggregation: SUM
source:
  table: finance_revenue
  column: recognized_amount
Enter fullscreen mode Exit fullscreen mode

This definition can then be reused by every authorized agent.

### 3. Relationship Discovery

Suppose the agent needs Customer and Payment data.

It should not have to guess the join path from raw schemas.

A relationship service could return:

Customer
   ↓ customer_id
Order
   ↓ order_id
Invoice
   ↓ invoice_id
Payment
Enter fullscreen mode Exit fullscreen mode

along with evidence or confidence information.

For example:

{
  "path": [
    "customer",
    "sales_order",
    "invoice",
    "payment"
  ],
  "status": "trusted"
}
Enter fullscreen mode Exit fullscreen mode

### 4. Query Context

Instead of sending an entire warehouse schema into the prompt, the agent can receive only the relevant context:

Question
   ↓
Resolve Business Concepts
   ↓
Retrieve Relevant Metadata
   ↓
Retrieve Trusted Relationships
   ↓
Generate Query Context
   ↓
LLM
Enter fullscreen mode Exit fullscreen mode

This reduces unnecessary context and gives the model more targeted information.

## Why Schema Retrieval Alone Is Not Enough

A common pattern today is:

Question
   ↓
Embedding Search
   ↓
Relevant Tables
   ↓
LLM
   ↓
SQL
Enter fullscreen mode Exit fullscreen mode

This is useful.

It solves the problem of sending thousands of tables to the model.

But it does not answer:

Which metric definition is authoritative?

Which relationship is trusted?

Which business entity does this table represent?
Enter fullscreen mode Exit fullscreen mode

Retrieval answers:

What looks relevant?

A shared data intelligence layer must also answer:

What is valid for this business question?

That distinction matters more as the number of agents grows.

## Relationship Knowledge Should Be Evidence-Based

Enterprise relationships are often not fully represented by foreign keys.

A relationship engine can use several signals:

Database constraints
Naming similarity
Value overlap
Uniqueness
Inclusion relationships
Validated business mappings
Enter fullscreen mode Exit fullscreen mode

For example, if:

A = order.customer_id
B = customer.customer_id
Enter fullscreen mode Exit fullscreen mode

we can calculate:

Inclusion(A → B)
=
|distinct(A) ∩ distinct(B)|
---------------------------
|distinct(A)|
Enter fullscreen mode Exit fullscreen mode

A high inclusion ratio can provide evidence that A references B.

But discovered relationships should not automatically become business truth.

A safer lifecycle is:

Discovered
    ↓
Candidate
    ↓
Validated
    ↓
Trusted
Enter fullscreen mode Exit fullscreen mode

Agents should preferentially consume trusted relationships rather than independently inventing joins.

## MCP Fits Here — But It Is Not the Data Model

MCP gives agents a standardized way to discover and call tools.

That makes it a natural interface for shared data capabilities.

For example, an enterprise data MCP server could expose tools such as:

get_metric_definition()

get_table_metadata()

discover_relationships()

get_query_context()
Enter fullscreen mode Exit fullscreen mode

An agent could then call:

Agent
  ↓
MCP
  ↓
Shared Data Intelligence Services
Enter fullscreen mode Exit fullscreen mode

But MCP itself does not determine:

What Revenue means

Which customer definition is authoritative

Which join path is trusted
Enter fullscreen mode Exit fullscreen mode

Those decisions come from the data intelligence behind the interface.

A useful distinction is:

MCP standardizes access. Shared data intelligence standardizes understanding.

## Centralization Does Not Mean Static Knowledge

Moving enterprise knowledge into a shared layer solves duplication, but it creates another responsibility:

the shared knowledge must stay current.

Enterprise systems continuously change:

New tables
New columns
New metrics
New business rules
New relationships
Enter fullscreen mode Exit fullscreen mode

So the shared layer needs its own lifecycle:

Discover
   ↓
Detect Change
   ↓
Evaluate Impact
   ↓
Validate
   ↓
Version
   ↓
Publish
Enter fullscreen mode Exit fullscreen mode

Otherwise the organization simply replaces many stale agent configurations with one stale central configuration.

## What Happens When a Metric Changes?

Suppose:

Revenue v1
=
SUM(invoice_amount)
Enter fullscreen mode Exit fullscreen mode

changes to:

Revenue v2
=
SUM(recognized_amount)
Enter fullscreen mode Exit fullscreen mode

With agent-local knowledge:

Sales Agent → update
Finance Agent → update
Analytics Agent → update
Management Agent → update
Support Agent → maybe update
Enter fullscreen mode Exit fullscreen mode

Someone has to discover every dependency.

With shared semantics:

Revenue Definition
       ↓
Version Update
       ↓
Shared Data Intelligence
       ↓
All Authorized Agents
Enter fullscreen mode Exit fullscreen mode

The enterprise changes the definition once.

Agents consume the updated version.

That is a much cleaner dependency model.

## Shared Data Intelligence Also Reduces Agent Coupling

There is another benefit.

Agent frameworks are changing quickly.

Organizations may switch between:

  • models;
  • orchestration frameworks;
  • agent runtimes;
  • application interfaces.

Business knowledge should survive those changes.

If metric definitions, data relationships, and business mappings are independent of the agent implementation, agents become easier to replace.

That suggests an architectural principle:

Agents = Replaceable Compute / Reasoning

Enterprise Data Intelligence = Durable Knowledge
Enter fullscreen mode Exit fullscreen mode

The enterprise should own its understanding of itself.

Not the current agent framework.

## A Practical Multi-Agent Data Architecture

A simplified architecture might look like:

               Sales Agent
                    │
              Finance Agent
                    │
             Analytics Agent
                    │
             Operations Agent
                    │
                    ▼
        ┌──────────────────────┐
        │ Shared Data          │
        │ Intelligence Layer   │
        ├──────────────────────┤
        │ Business Semantics   │
        │ Metrics & Dimensions │
        │ Metadata             │
        │ Relationships        │
        │ Trusted Query Paths  │
        └──────────────────────┘
                    │
                    ▼
             Enterprise Data
Enter fullscreen mode Exit fullscreen mode

The shared layer does not replace agents.

It makes them thinner.

It does not replace the LLM.

It gives the LLM a consistent representation of the enterprise.

## Final Thoughts

The first generation of enterprise agents focused on making individual agents more capable.

The multi-agent era creates a different engineering problem:

How do many agents share one consistent understanding of enterprise data?

If every agent independently discovers schemas, defines metrics, and guesses relationships, organizations will create duplicated logic and inconsistent answers.

The better pattern is separation of concerns:

Agents reason.

Shared data intelligence defines what the enterprise means.
Enter fullscreen mode Exit fullscreen mode

Models will change.

Agents will change.

Frameworks will change.

Your enterprise should not have to rediscover its own data model every time they do.

Top comments (0)