DEV Community: Arisyn

When Should a Data Agent Ask a Clarifying Question?

Arisyn — Wed, 26 Aug 2026 14:17:00 +0000

A production Text-to-SQL agent should not generate SQL simply because it can interpret a question. It should first decide whether the business intent is clear enough to query safely.

Consider:

Show me our best customers.

A language model can parse this easily.

It can identify customers, search the schema, choose a metric, generate SQL, and return a ranked list.

The problem is not language understanding.

The problem is that best has no unique analytical meaning.

It could mean:

Revenue
Profit
Growth
Retention
Lifetime Value

If the agent silently chooses Revenue, the generated SQL may be syntactically correct and the returned data may be completely real.

But the system has made a business decision the user never made.

This creates an important engineering requirement for production data agents:

Before generating SQL, decide whether the intent is sufficiently resolved.

## 1. Add an Intent Gate Before SQL Generation

A basic Text-to-SQL pipeline often looks like:

Question
   ↓
Schema Retrieval
   ↓
Prompt Construction
   ↓
LLM
   ↓
SQL

For enterprise use, add an intent-resolution gate:

Question
   ↓
Intent Extraction
   ↓
Semantic Candidate Resolution
   ↓
Ambiguity Detection
   ↓
Intent Complete?
   │
   ├── YES → Data Context → SQL
   │
   └── NO  → Clarification
                  ↓
             Update Intent
                  ↓
             Re-evaluate

Clarification is therefore not a conversational feature added after the agent fails.

It is part of query planning.

## 2. Represent Intent Explicitly

Do not let the entire interpretation live only inside the LLM prompt.

Represent the query intent as structured state.

For example:

{
  "entity": "customer",
  "metric": null,
  "metric_candidates": [
    "revenue",
    "profit",
    "growth",
    "retention"
  ],
  "dimensions": [],
  "time_range": "last_quarter",
  "scope": null,
  "requires_clarification": true
}

After the user selects Profit:

{
  "entity": "customer",
  "metric": "profit",
  "dimensions": [],
  "time_range": "last_quarter",
  "scope": null,
  "requires_clarification": false
}

This gives the system an inspectable state transition:

Ambiguous Intent
      ↓
User Clarification
      ↓
Resolved Intent

Only the resolved form should move into SQL generation.

## 3. Detect Different Types of Ambiguity

Not all ambiguity is the same.

A useful implementation should detect at least four categories.

### Metric Ambiguity

Question:

Who are our best customers?

Candidates:

{
  "term": "best",
  "type": "metric",
  "candidates": [
    "revenue",
    "profit",
    "growth",
    "retention"
  ]
}

### Dimension Ambiguity

Question:

Show sales by region.

Possible dimensions:

customer_region
sales_region
billing_region
delivery_region

### Time Ambiguity

Question:

Show recent revenue.

Possible interpretations:

last_7_days
last_30_days
current_month
current_quarter

### Scope Ambiguity

Question:

How many active customers do we have?

Possible business definitions:

purchased_in_last_30_days
logged_in_last_30_days
active_contract
non_churned

These ambiguities are dangerous because each candidate may produce perfectly executable SQL.

## 4. Candidate Count Is Not Enough

A naive ambiguity detector might say:

if len(candidates) > 1:
    clarify()

That creates too many questions.

Suppose Revenue maps to three technical fields, but one is the governed enterprise metric and the others are deprecated or non-authoritative.

There may be multiple candidates, but no meaningful ambiguity.

A better decision considers:

Candidate Similarity
Governed Definition
Authority
Business Impact
Default Availability
User / Workspace Context

For example:

def resolve_concept(term, context):
    candidates = semantic_search(term)

    governed = [
        c for c in candidates
        if c.is_governed and c.is_active
    ]

    if len(governed) == 1:
        return Resolution(
            value=governed[0],
            requires_clarification=False
        )

    return evaluate_ambiguity(
        candidates=candidates,
        context=context
    )

The goal is not to ask whenever the model sees alternatives.

The goal is to ask when multiple materially different interpretations remain valid.

## 5. Score Clarification Need

A useful conceptual model is:

Clarification Need
=
Ambiguity
×
Business Impact

You can extend this for implementation:

Clarification Score
=
Ambiguity Score
× Business Impact
× (1 - Default Confidence)
× (1 - Governance Confidence)

For example:

def clarification_score(concept):
    return (
        concept.ambiguity_score
        * concept.business_impact
        * (1 - concept.default_confidence)
        * (1 - concept.governance_confidence)
    )

Then:

if clarification_score(concept) > THRESHOLD:
    request_clarification(concept)

The exact formula is domain-specific.

The important architectural point is:

Clarification should be a policy decision, not an LLM reflex.

## 6. Estimate Business Impact

Ambiguity only matters if different interpretations can materially change the result.

Consider:

Top 10 customers.

Whether ties return 10 or 11 rows is usually low impact.

Now consider:

Most profitable customers.

If the enterprise has:

Gross Profit
Contribution Profit
Operating Profit

the choice can completely change the ranking.

A practical impact model might use:

LOW
Formatting, display, minor ranking behavior

MEDIUM
Time defaults, optional filters, non-critical dimensions

HIGH
Metric definition, financial scope, entity identity,
relationship path, aggregation grain

High-impact ambiguity should have a lower clarification threshold.

## 7. Resolve What the Enterprise Already Knows

A good clarification engine should ask fewer questions as enterprise knowledge improves.

Suppose the semantic layer already contains:

term: revenue

resolved_metric:
  id: recognized_revenue

status: active
owner: finance

Then:

Show revenue by region last quarter.

should not trigger:

What do you mean by revenue?

The enterprise has already answered that question.

The resolution order should look like:

User Input
   ↓
Session Context
   ↓
Governed Business Definition
   ↓
Workspace Default
   ↓
Candidate Meanings
   ↓
Clarify Only If Still Unresolved

This is critical for usability.

## 8. Generate Clarifications From Known Candidates

Avoid generic questions such as:

Could you clarify what you mean?

The agent already has candidate meanings.

Use them.

Instead:

How should “best customers” be ranked?

[ Revenue ] [ Profit ] [ Growth ] [ Retention ]

Or:

Which region should I use?

[ Customer Region ]
[ Sales Region ]
[ Billing Region ]
[ Delivery Region ]

This transforms clarification from an open-ended conversation into a constrained resolution step.

## 9. Ask the Highest-Impact Question First

A single user question can contain multiple ambiguities.

Example:

Show our best customers in Europe recently.

Potential ambiguity:

best      → Revenue / Profit / Growth
Europe    → Customer / Sales / Billing Region
recently  → 7 / 30 / 90 days

Do not immediately ask three questions.

Rank unresolved concepts:

ambiguities = [
    Ambiguity("best", impact=0.95),
    Ambiguity("Europe", impact=0.35),
    Ambiguity("recently", impact=0.40)
]

ambiguities.sort(
    key=lambda x: x.clarification_score,
    reverse=True
)

Ask:

How should “best” be measured?

After resolving it, re-evaluate the remaining intent.

The other ambiguities may already be resolvable through workspace defaults or governed semantics.

## 10. Use a Clarification Budget

Every clarification has a UX cost.

A useful runtime configuration could be:

clarification:
  max_rounds: 2
  max_questions_per_round: 1
  minimum_impact: 0.5

This forces the system to prioritize.

If the intent remains unresolved after the budget is exhausted, the system can:

1. Show the assumption explicitly
2. Ask the user to choose whether to proceed
3. Refuse high-risk execution

For example:

I can proceed using Revenue as the ranking metric and the last 30 days as “recent.” Continue?

This is better than silently guessing.

## 11. Define Intent Completeness

The agent needs a deterministic stop condition.

For a typical analytical query, required slots might include:

required_intent:
  metric: true
  dimensions: optional
  time_range: true
  filters: optional
  entity_scope: true

Then compute:

def intent_complete(intent, requirements):
    for slot, required in requirements.items():
        if required and intent.get(slot) is None:
            return False

    return True

A more advanced version can include confidence:

Metric       Revenue          0.98
Dimension    Customer         0.99
Time         Last Quarter     0.96
Scope        Enterprise       0.93

SQL generation begins only after the required intent reaches the accepted state.

## 12. Separate Semantic Confidence From Model Confidence

This distinction is important.

An LLM may be:

95% confident

that “best customers” probably means highest revenue.

That does not mean the enterprise has defined it that way.

So distinguish:

Model Confidence

from:

Semantic Resolution Confidence

Semantic confidence should come from evidence such as:

Governed Metric Match
Business Glossary Match
Workspace Configuration
Prior Clarification
User Selection

Do not treat model certainty as proof of business intent.

## 13. Preserve Clarification State Across Turns

Clarification should not restart the entire reasoning process.

Maintain state:

{
  "query_id": "q_1042",

  "original_question":
    "Show our best customers last quarter",

  "resolved": {
    "entity": "customer",
    "time_range": "last_quarter"
  },

  "unresolved": {
    "metric": [
      "revenue",
      "profit",
      "growth"
    ]
  }
}

User:

Profit.

Update only the unresolved slot:

{
  "resolved": {
    "entity": "customer",
    "metric": "profit",
    "time_range": "last_quarter"
  },

  "unresolved": {}
}

Then continue query planning.

This keeps the interaction efficient and auditable.

## 14. Feed Resolved Intent Into Data Context Resolution

Clarification should narrow the downstream search space.

Before clarification:

best customers

may require retrieving context for:

Revenue
Profit
Growth
Retention
Customer

After:

best = Profit

the system can focus on:

Profit Metric
Customer Dimension
Required Data Sources
Required Relationships
Last Quarter

So clarification does more than improve UX.

It reduces context size and downstream reasoning complexity.

## 15. Validate SQL Against Resolved Intent

After SQL generation, compare the query against the intent state.

Suppose the user clarified:

best = Profit

but generated SQL ranks:

ORDER BY revenue DESC

That should fail validation.

Conceptually:

def validate_query(sql_plan, intent):
    violations = []

    if sql_plan.metric != intent.metric:
        violations.append({
            "type": "metric_mismatch",
            "expected": intent.metric,
            "actual": sql_plan.metric
        })

    return violations

Clarification therefore creates a stronger validation target.

## 16. Log Why the Agent Asked

For production systems, store the clarification decision:

{
  "concept": "best",
  "reason": "multiple_valid_metrics",
  "candidates": [
    "revenue",
    "profit",
    "growth",
    "retention"
  ],
  "ambiguity_score": 0.92,
  "business_impact": 0.95,
  "decision": "clarify"
}

This helps answer:

Why did the agent ask this question?
Why did it not ask another one?
Which ambiguities cause the most friction?

It also makes clarification behavior measurable.

## 17. Measure the Clarification System

Useful production metrics include:

### Clarification Rate

% of user queries requiring at least one clarification

### Average Clarification Rounds

Mean number of follow-up turns before query generation

### Resolution Rate

% of ambiguous queries successfully resolved

### Abandonment Rate

% of users leaving during clarification

### Post-Clarification Accuracy

Compare:

SQL / answer accuracy before clarification
vs.
after clarification

### Unnecessary Clarification Rate

How often users select the obvious/default interpretation.

This is important because too many questions can be as harmful as too few.

## 18. A Practical Clarification Runtime

Putting everything together:

User Question
      ↓
Intent Parser
      ↓
Semantic Resolver
      ↓
Candidate Meanings
      ↓
Ambiguity Detector
      ↓
Impact + Governance Evaluation
      ↓
Clarification Needed?
      │
      ├── NO
      │    ↓
      │  Resolved Intent
      │
      └── YES
           ↓
      Ranked Clarification
           ↓
      User Selection
           ↓
      Update Intent State
           ↓
      Re-evaluate
           ↓
      Resolved Intent
           ↓
Data / Relationship Context
           ↓
SQL Generation
           ↓
Intent Validation
           ↓
Execution

The LLM remains important.

But the decision to query is no longer left entirely to free-form generation.

## 19. The Engineering Principle

The goal is not to make the agent less autonomous.

It is to define where autonomy is appropriate.

If the enterprise has already defined the answer, use the definition.

If a safe default exists, use it.

If ambiguity is low impact, proceed.

But when multiple valid business interpretations remain and the choice materially changes the answer:

Give the decision back to the user.

That is not a weakness.

It is good query planning.

## Final Thoughts

A production data agent should not optimize for:

Always generate SQL.

It should optimize for:

Generate SQL when intent is sufficiently resolved.

That requires:

Structured Intent
Semantic Candidates
Ambiguity Detection
Business-Impact Scoring
Governed Defaults
Clarification Budget
Intent Completeness
Post-Generation Validation

The most dangerous enterprise data errors often happen when the model makes a reasonable assumption that nobody explicitly approved.

So before improving the SQL generator again, add one question to the pipeline:

Do we actually know what the user means?

If not, the correct next step is not SQL.

It is clarification.

What Makes Enterprise Data AI-Readable?

Arisyn — Mon, 24 Aug 2026 15:56:00 +0000

A schema tells an AI what exists. It does not tell the AI what the data means, how it should be connected, or when it should not be used.

For decades, enterprise databases have been designed primarily for developers, data engineers, and analysts.

That design worked because humans supplied the missing context.

An experienced analyst knows that invoice_amount is not the same as recognized revenue.

A data engineer knows that two tables should not be joined directly even though their IDs look compatible.

A finance team knows that created_at is an operational timestamp while financial reporting should use settlement_date.

None of this knowledge has to exist in the physical schema for humans to work effectively.

AI agents change that assumption.

If an agent is expected to query enterprise data directly, the data model must communicate much more than:

table
column
type

The real engineering question becomes:

What information does an AI system need before enterprise data becomes reliably usable?

I think the answer is larger than schema retrieval and embeddings.

A useful model is:

AI-Readable Data
=
Meaning
+
Structure
+
Relationships
+
Usage Rules
+
Trust

## 1. Machine-Readable Is Not AI-Readable

Consider this schema:

CREATE TABLE sales_order (
    order_id      BIGINT,
    customer_id   BIGINT,
    total_amount  DECIMAL(18,2),
    created_at    TIMESTAMP,
    status        VARCHAR(20)
);

A model can parse it.

It knows that total_amount is numeric and created_at is temporal.

But it still does not know:

Does total_amount include tax?

Are cancelled orders included?

Is total_amount order value or recognized revenue?

Should created_at be used for financial reporting?

How does customer_id map across CRM and ERP?

Can this table be joined directly to invoice?

The schema describes structure.

Enterprise analytics requires usage context.

That gap is where many AI data failures begin.

## 2. Descriptions Help, but They Do Not Solve the Problem

A common improvement is to add table and column descriptions:

table: sales_order

columns:
  total_amount:
    type: decimal
    description: Total amount of the sales order.

  created_at:
    type: timestamp
    description: Time when the order was created.

This is useful metadata.

But now ask:

What was revenue last quarter?

The description still does not tell the model whether total_amount should be used as Revenue.

A technically accurate description can still be insufficient for analytical reasoning.

The missing information is not:

What is this column?

It is:

When is this column valid for a business question?

## 3. Meaning Should Be Explicit

Suppose the warehouse contains:

sales_order.total_amount
invoice.invoice_amount
finance_revenue.recognized_amount
payment.received_amount

All four fields may be retrieved for the word:

Revenue

Embedding similarity is doing exactly what it should.

The fields are semantically related.

But enterprise AI needs a stronger object:

metric:
  id: revenue
  name: Revenue
  version: 2.1

  definition:
    business_term: Recognized Revenue
    aggregation: SUM

  source:
    table: finance_revenue
    column: recognized_amount

  time:
    field: recognition_date

This changes the problem from:

Which revenue-like field should the model choose?

to:

Retrieve the governed Revenue definition.

That is a much more reliable operation.

## 4. Relationships Need to Be First-Class Context

Even perfect semantic definitions are not enough for multi-table analytics.

Suppose a user asks:

Which customers have unpaid invoices?

The system may need:

Customer
   ↓
Order
   ↓
Invoice
   ↓
Payment

But real enterprise schemas often do not contain complete foreign keys.

A relationship may exist because:

order.customer_id

and:

customer.customer_id

share values.

One useful relationship signal is inclusion:

Inclusion(A → B)
=
|distinct(A) ∩ distinct(B)|
---------------------------
|distinct(A)|

where:

A = order.customer_id
B = customer.customer_id

If the inclusion ratio is high and B has high uniqueness, the system has evidence for a possible reference relationship.

Relationship discovery can combine:

Database Constraints
Column Names
Value Inclusion
Uniqueness
Business Validation

Then relationships can move through states:

Discovered
    ↓
Candidate
    ↓
Validated
    ↓
Trusted

At query time, the AI should prefer trusted relationships instead of reconstructing joins from scratch.

## 5. Positive Knowledge Is Only Half the Model

Most semantic systems are good at representing positive knowledge:

Revenue uses recognized_amount.

But production systems also need negative knowledge:

Do NOT use invoice_amount as Revenue.

That distinction is more important than it looks.

Imagine:

field:
  table: sales_order
  name: total_amount

usage:
  valid_for:
    - order_value
    - sales_volume

  invalid_for:
    - recognized_revenue
    - cash_collection

Now the system knows both:

What this field can answer.

and:

What this field must not answer.

Humans use this kind of knowledge constantly.

We say:

Don't use that table for finance.

Don't join those tables directly.

Don't use created_at for reporting.

That field looks like customer_id, but it is actually account_id.

These constraints often exist only as tribal knowledge.

For AI systems, they should become structured context.

## 6. Why Negative Knowledge Matters for Retrieval

Suppose a vector search for:

customer revenue

returns:

sales_order.total_amount       score 0.91
invoice.invoice_amount         score 0.89
finance_revenue.recognized_amount score 0.87

A naive retrieval pipeline might choose the highest score.

But relevance is not authority.

If the governed context says:

sales_order.total_amount
invalid_for: recognized_revenue

the retrieval system can exclude or penalize that candidate.

Conceptually:

def rank_candidate(candidate, query_context):
    score = candidate.semantic_similarity

    if candidate.is_authoritative_for(query_context.metric):
        score += AUTHORITY_BONUS

    if candidate.is_invalid_for(query_context.metric):
        score -= INVALID_USAGE_PENALTY

    return score

The important shift is that retrieval is no longer based only on similarity.

It becomes:

Similarity
+
Business Validity
+
Trust
+
Usage Constraints

## 7. Usage Rules Should Be Machine-Consumable

A free-text description such as:

This table is generally used for order reporting and should normally not be used for financial revenue reporting.

is useful to humans.

For AI systems, structured rules are easier to enforce:

table: sales_order

valid_for:
  - order_analysis
  - sales_pipeline

invalid_for:
  - recognized_revenue
  - financial_close

preferred_time_field:
  order_analysis: created_at

constraints:
  - exclude_cancelled_orders

This does not mean every business rule must become rigid YAML.

Some rules remain contextual.

But high-value, frequently reused constraints should be represented in a form tools and agents can consume deterministically.

## 8. Trust Signals Resolve Competing Context

Enterprise systems frequently contain multiple definitions.

For example:

Revenue v1.8
Revenue v2.0
Revenue v2.1

Or several candidate relationships:

Customer → Order
Customer → Account → Order
Customer → Contract → Order

An AI-readable context needs signals that help select among them.

For example:

metric:
  id: revenue
  version: 2.1
  status: active
  owner: finance
  effective_from: 2026-01-01
  validated: true

A relationship might include:

relationship:
  id: rel_customer_account
  status: trusted
  confidence: 0.97
  validated_by: data_governance

Now retrieval can distinguish:

Relevant

from:

Relevant + Authoritative

That difference matters in production.

## 9. AI-Readable Context Can Be Built as a Data Object

A richer representation for a field might look like:

field:
  table: sales_order
  name: total_amount
  type: decimal

meaning:
  business_term: Order Value
  description: Confirmed sales order value

structure:
  nullable: false
  distinct_ratio: 0.84

relationships:
  - target: customer.customer_id
    via: sales_order.customer_id
    status: trusted

usage:
  valid_for:
    - order_analysis
    - sales_volume

  invalid_for:
    - recognized_revenue
    - cash_received

trust:
  owner: sales_operations
  status: active
  validated: true

This object contains far more actionable context than:

total_amount DECIMAL

or even:

Total amount of the sales order.

## 10. Build Query Context From AI-Readable Objects

Once these objects exist, query-time context construction becomes more reliable.

Suppose the question is:

Show recognized revenue by customer for last quarter.

A context builder could resolve:

Business Metric
→ Revenue v2.1

Dimension
→ Customer

Relevant Sources
→ finance_revenue
→ customer

Trusted Relationship
→ finance_revenue.customer_id
→ customer.customer_id

Time Field
→ recognition_date

Excluded Candidates
→ sales_order.total_amount
→ invoice.invoice_amount

The resulting model context can be compact:

metric:
  name: Revenue
  source: finance_revenue.recognized_amount
  aggregation: SUM

dimension:
  name: Customer
  source: customer.customer_name

relationship:
  finance_revenue.customer_id -> customer.customer_id

time_field:
  finance_revenue.recognition_date

do_not_use:
  - sales_order.total_amount
  - invoice.invoice_amount

The LLM no longer needs to infer the enterprise model from raw schema.

It receives an instruction-ready representation.

## 11. This Is More Than RAG

A standard RAG pipeline looks like:

Question
   ↓
Embedding
   ↓
Retrieve Relevant Context
   ↓
LLM

An AI-readable data layer introduces additional steps:

Question
   ↓
Resolve Business Concepts
   ↓
Retrieve Relevant Data Objects
   ↓
Apply Usage Constraints
   ↓
Prefer Trusted Definitions
   ↓
Resolve Relationships
   ↓
Build Query Context
   ↓
LLM

The goal is not merely:

Find context.

It is:

Find context that is valid for this analytical task.

## 12. AI-Readable Data Should Be Model-Independent

One architectural mistake is putting all of this context inside a model-specific system prompt.

For example:

If user asks Revenue, use table X.
Never join A directly to B.
For finance reporting use settlement_date.
...

That works initially.

But the knowledge becomes coupled to one agent implementation.

A better architecture keeps enterprise data knowledge outside the model:

AI Agent
    ↓
Context Resolver
    ↓
AI-Readable Data Layer
    ↓
Enterprise Data

Then different agents can consume the same knowledge:

Sales Agent
Finance Agent
Analytics Agent
Operations Agent

The model can change without rebuilding the enterprise's data understanding.

## 13. AI-Readable Data Needs a Lifecycle

This context cannot be static.

Schemas change.

Metrics change.

Relationships change.

Usage rules change.

So the system needs:

Discover
   ↓
Validate
   ↓
Publish
   ↓
Monitor
   ↓
Detect Change
   ↓
Update

For example, if:

Revenue v2.1

becomes:

Revenue v2.2

the old version should not silently disappear.

Historical queries may still need to be reproduced.

The same applies to relationships and usage constraints.

## 14. A Practical Architecture

One possible design:

                Enterprise Data
                      │
                      ▼
          ┌─────────────────────┐
          │ Metadata Extraction │
          └──────────┬──────────┘
                     │
          ┌──────────▼──────────┐
          │ Relationship        │
          │ Discovery           │
          └──────────┬──────────┘
                     │
          ┌──────────▼──────────┐
          │ Semantic / Metric   │
          │ Governance          │
          └──────────┬──────────┘
                     │
          ┌──────────▼──────────┐
          │ Usage Rules &       │
          │ Negative Knowledge  │
          └──────────┬──────────┘
                     │
                     ▼
          AI-Readable Data Objects
                     │
                     ▼
              Context Resolver
                     │
                     ▼
                 AI Agent

The point is not that every implementation needs these exact services.

The important idea is the separation between:

Raw Enterprise Data

and:

Context AI Can Reliably Use

## 15. What Should Be Measured?

If AI-readability becomes a real engineering objective, teams can measure it.

Possible metrics include:

Semantic Coverage

% of important tables / fields mapped to business concepts

Relationship Coverage

% of frequently queried multi-table paths represented as validated relationships

Usage Rule Coverage

% of high-value data objects with explicit valid / invalid usage

Trusted Context Resolution Rate

% of queries where metric + sources + relationships
are resolved without free-form LLM inference

Negative Constraint Hit Rate

How often invalid candidates are removed
because of explicit usage constraints

These metrics move the conversation from:

Our documentation is better.

to:

Our data is increasingly usable by AI systems.

## 16. The New Definition of Data Readiness

Traditional data readiness asks:

Is the data available?
Is it clean?
Is it integrated?
Is it documented?

AI adds another requirement:

Can an AI determine:
- what the data means,
- how it connects,
- when it is valid,
- when it is invalid,
- and why it should be trusted?

That is a much stronger definition.

## Final Thoughts

Enterprise AI is exposing a problem that humans have hidden for years.

Our data models often depend on undocumented organizational knowledge.

Experienced people know:

which field to use,
which table not to use,
which relationship is valid,
which timestamp matters,
which definition is authoritative.

AI does not automatically know any of that.

So the goal should not be merely to give AI access to more schemas.

The goal should be to make enterprise data AI-readable.

That means representing:

Meaning
Structure
Relationships
Usage Rules
Trust

And especially the knowledge most systems still ignore:

What the AI should not do with the data.

Sometimes the difference between a demo and a production data agent is not another model upgrade.

It is one critical piece of enterprise knowledge:

Don't use this data that way.

Beyond SQL Accuracy: Building Evidence Chains for AI Data Agents

Arisyn — Thu, 20 Aug 2026 15:10:00 +0000

AI data agents are getting good at producing executable SQL.

That is useful, but executable SQL is not the same thing as a correct business answer.

A query can compile, run successfully, return real rows, and still answer the wrong question because the agent selected the wrong metric definition, source table, relationship, grain, time field, or filter.

For production systems, this creates a different engineering requirement:

An AI data agent should not only generate an answer. It should preserve the evidence that produced it.

This article explores how to treat that evidence as a first-class artifact rather than an explanation generated after the fact.

## 1. Why SQL Accuracy Is an Incomplete Target

Consider this question:

What was net revenue by region last quarter?

The agent generates:

SELECT
    c.region,
    SUM(i.invoice_amount) AS net_revenue
FROM invoices i
JOIN customers c
    ON i.customer_id = c.customer_id
WHERE i.invoice_date >= '2026-04-01'
  AND i.invoice_date < '2026-07-01'
GROUP BY c.region;

The query is valid.

But suppose the enterprise definition is:

Net Revenue
=
Recognized Revenue
-
Refunds
-
Credits

and regional attribution is based on the billing account rather than the customer master.

The SQL engine cannot detect this error.

From the database's perspective, the query is correct.

From the business's perspective, it is wrong.

That gives us two different validation layers:

SQL Validity
=
Can this query execute?

Business Validity
=
Does this query represent the intended business question?

Production AI analytics needs both.

## 2. The Failure Surface Is Larger Than SQL Generation

A useful way to model an AI data query is:

Question
   ↓
Semantic Resolution
   ↓
Source Selection
   ↓
Relationship Selection
   ↓
Filter / Time Resolution
   ↓
SQL Generation
   ↓
Execution
   ↓
Answer

An error can occur at any stage.

For example:

Semantic Resolution
Revenue → Invoice Amount       ❌

Source Selection
invoices                       ✓

Relationship Selection
invoice.customer_id → customer ✓

Time Resolution
invoice_date                   ❌

SQL Generation
Valid SQL                      ✓

Execution
Success                        ✓

If we evaluate only the final SQL syntax or execution status, the system appears healthy.

The real failure happened much earlier.

This is why AI data agents need evidence chains, not just query logs.

## 3. What Is an Evidence Chain?

An evidence chain records the artifacts and decisions that connect a user question to the final answer.

Conceptually:

User Question
      │
      ▼
Business Definition
      │
      ▼
Source Data
      │
      ▼
Relationships
      │
      ▼
Filters / Time Rules
      │
      ▼
Generated SQL
      │
      ▼
Execution Result
      │
      ▼
Final Answer

The goal is not to create another verbose chain-of-thought log.

The goal is to preserve verifiable system artifacts.

That distinction matters.

Internal model reasoning is probabilistic and may not be suitable as an audit artifact.

A metric identifier, relationship identifier, SQL query, data-source identifier, and execution result are inspectable.

## 4. Evidence Should Be Structured

Instead of storing only:

question
sql
answer

store a structured evidence object.

For example:

{
  "question": "What was net revenue by region last quarter?",

  "semantic_resolution": {
    "metric_id": "net_revenue",
    "metric_version": "3.2",
    "dimensions": ["billing_region"]
  },

  "sources": [
    "orders",
    "refunds",
    "billing_accounts"
  ],

  "relationships": [
    {
      "relationship_id": "rel_orders_billing_account",
      "from": "orders.billing_account_id",
      "to": "billing_accounts.account_id",
      "status": "trusted"
    }
  ],

  "time": {
    "field": "settlement_date",
    "period": "last_quarter"
  },

  "sql": {
    "query_id": "q_8271"
  },

  "execution": {
    "result_id": "r_4412",
    "status": "success"
  },

  "validation": {
    "status": "passed"
  }
}

Now the answer has provenance.

## 5. Capture Evidence During Execution, Not Afterward

A common anti-pattern is:

1. Agent generates answer
2. User asks "Why?"
3. LLM generates an explanation

That produces a narrative, not necessarily provenance.

The model may describe what it believes happened.

A stronger implementation captures evidence as each stage executes.

For example:

evidence = Evidence(question=question)

metric = resolve_metric(question)
evidence.metric_id = metric.id
evidence.metric_version = metric.version

dimension = resolve_dimension(question)
evidence.dimensions.append(dimension.id)

path = relationship_service.get_trusted_path(
    metric=metric,
    dimensions=[dimension]
)
evidence.relationship_ids.extend(path.relationship_ids)

sql = generate_sql(
    question=question,
    metric=metric,
    dimensions=[dimension],
    relationship_path=path
)
evidence.sql = sql

result = execute(sql)
evidence.execution_status = result.status
evidence.result_id = result.id

The evidence object is built from actual system events.

That makes it much more useful for debugging and audit.

6. Semantic Evidence

The first layer is semantic resolution.

If the user asks:

What was revenue last quarter?

the system should be able to show:

User Term:
Revenue

Resolved Metric:
Net Revenue

Version:
3.2

Definition:
Recognized Revenue - Refunds - Credits

This matters because business terms are often ambiguous.

The SQL may be technically perfect while using the wrong definition.

A metric version is particularly important.

If Revenue v3.1 and v3.2 differ, the evidence chain should preserve which version generated the answer.

## 7. Source Evidence

The next question is:

Which data actually contributed to the answer?

For example:

orders
refunds
billing_accounts

A production evidence record may also include fields:

{
  "source": "orders",
  "fields": [
    "billing_account_id",
    "recognized_amount",
    "settlement_date"
  ]
}

This makes it possible to inspect whether the agent used an authoritative source rather than merely a semantically similar table.

## 8. Relationship Evidence

Multi-table queries require another layer of provenance.

Suppose the query joins:

orders
   ↓
billing_accounts
   ↓
region

The evidence should preserve why that path was selected.

At minimum:

{
  "relationship_id": "rel_orders_billing_account",
  "from": "orders.billing_account_id",
  "to": "billing_accounts.account_id",
  "status": "trusted"
}

More advanced systems could include relationship evidence such as:

Database Constraint
Naming Similarity
Value Inclusion
Uniqueness
Business Validation

The important point is that the agent is not silently inventing a join.

The relationship is inspectable.

## 9. Filter and Time Evidence

Filters are easy to overlook because they often appear as simple SQL predicates.

But they can completely change the business answer.

For example:

"last quarter"

might resolve to:

2026-04-01 → 2026-06-30

and use:

settlement_date

rather than:

invoice_date

The evidence record should preserve both.

For example:

{
  "time_resolution": {
    "business_period": "last_quarter",
    "start": "2026-04-01",
    "end": "2026-06-30",
    "field": "settlement_date"
  }
}

This makes temporal interpretation auditable.

## 10. Query Evidence

The SQL itself remains critical evidence.

But do not treat SQL as the entire explanation.

SQL is the executable consequence of upstream decisions.

A useful query record might include:

{
  "query_id": "q_8271",
  "sql_hash": "sha256:...",
  "generated_at": "2026-08-20T09:15:00Z",
  "metric_version": "3.2",
  "relationship_ids": [
    "rel_orders_billing_account"
  ]
}

This makes the query reproducible and connects it to the semantic and relationship state used during generation.

## 11. Execution Evidence

Execution success is useful evidence, just not sufficient evidence.

Capture:

Execution Status
Duration
Rows Returned
Data Source
Query Timestamp
Result Identifier

Potentially:

{
  "status": "success",
  "duration_ms": 842,
  "rows_returned": 8,
  "result_id": "r_4412"
}

This lets the system distinguish:

Bad SQL

from:

Valid SQL + Wrong Business Interpretation

## 12. Validation Should Check the Chain

Instead of asking only:

Did the SQL execute?

validation can inspect several layers.

### Semantic Validation

Was an approved metric definition used?

### Source Validation

Were authorized and current data sources used?

### Relationship Validation

Were joins based on trusted relationships?

### Filter Validation

Were required business filters applied?

### Query Validation

Did the SQL pass syntax and safety checks?

This produces a richer validation object:

{
  "semantic": "passed",
  "sources": "passed",
  "relationships": "passed",
  "filters": "passed",
  "sql": "passed"
}

## 13. Why LLM-as-a-Judge Cannot Be the Only Validator

A second model can review generated SQL.

That is useful.

But consider:

Agent:
Revenue = invoice_amount

Judge:
The SQL correctly sums invoice_amount.

Both models agree.

Both can still be wrong relative to the enterprise definition.

Language models are good at evaluating logical consistency inside the context they receive.

They cannot recover enterprise truth that is missing from that context.

So:

You cannot verify a data answer with language alone.

Verification needs grounded evidence from semantic definitions, metadata, relationships, executed SQL, and query results.

## 14. Evidence Chains Improve Debugging

Suppose an answer is reported as incorrect.

Without structured evidence, the debugging workflow may be:

Reproduce Prompt
↓
Inspect Agent Logs
↓
Inspect SQL
↓
Guess What Went Wrong

With evidence:

Semantic Resolution      PASS
Source Selection         PASS
Relationship Selection   FAIL
Filter Resolution        PASS
SQL Validation           PASS
Execution                PASS

The engineering team immediately knows where to investigate.

This is especially valuable because many production NL2SQL failures happen before SQL generation.

## 15. Evidence Chains Improve Evaluation

Evidence also makes offline and online evaluation more granular.

Instead of only measuring:

Exact SQL Match
Execution Accuracy
Final Answer Accuracy

teams can measure:

Metric Resolution Accuracy
Source Selection Accuracy
Relationship Selection Accuracy
Filter Resolution Accuracy
Trusted Relationship Usage
SQL Validation Pass Rate

This turns a monolithic accuracy score into a diagnostic system.

If final-answer accuracy drops, the team can determine which layer caused the regression.

## 16. Evidence as an API Object

Evidence should not exist only in the UI.

It can be part of the agent API.

For example:

{
  "answer": {
    "metric": "Net Revenue",
    "value": 27300000,
    "currency": "USD"
  },

  "evidence": {
    "metric": {
      "id": "net_revenue",
      "version": "3.2"
    },

    "sources": [
      "orders",
      "refunds",
      "billing_accounts"
    ],

    "relationships": [
      "rel_orders_billing_account"
    ],

    "query_id": "q_8271",

    "validation": "passed"
  }
}

Now downstream systems can choose how much evidence to expose.

## 17. Progressive Disclosure in the UI

Most business users do not want to read SQL after every question.

So the default UI can remain simple:

Net Revenue
$27.3M

✓ Evidence available

Then:

Why this answer?

can reveal:

Metric Definition
Source Data
Relationships
Filters
SQL
Validation

Different users can inspect different levels.

An executive may stop at the answer.

An analyst may inspect the metric and filters.

A data engineer may inspect joins and SQL.

## 18. Evidence Is Stronger Than Explanation

There is an important difference between:

Explainable

and:

Inspectable

An LLM can generate a convincing explanation.

An inspectable system exposes the artifacts that actually produced the answer.

For enterprise data, inspectability is often the stronger trust mechanism.

The user does not have to believe the explanation.

They can inspect the evidence.

## 19. A Practical Evidence Pipeline

A simplified architecture could look like:

User Question
      │
      ▼
Semantic Resolver
      │
      ├── metric_id
      └── dimension_ids
      │
      ▼
Relationship Resolver
      │
      └── relationship_ids
      │
      ▼
Context Builder
      │
      ▼
SQL Generator
      │
      └── query_id
      │
      ▼
SQL Validator
      │
      ▼
Query Executor
      │
      └── result_id
      │
      ▼
Answer Generator
      │
      ▼
Evidence Object

Every stage contributes structured evidence.

The evidence object becomes the trace that connects the original question to the final answer.

## 20. What Should Be Stored?

At minimum:

Question ID
User Question
Resolved Metric + Version
Resolved Dimensions
Source Tables / Fields
Relationship IDs
Filters
Time Interpretation
Generated SQL / Query ID
Execution Result ID
Validation Status
Timestamp

Depending on governance requirements, also consider:

Semantic Model Version
Relationship Model Version
Data Snapshot / Query Timestamp
Authorization Context
Agent Version
Model Version

This makes answers reproducible even as the system evolves.

## 21. A Better Definition of Production Readiness

For a prototype, this may be enough:

Question → SQL → Answer

For production enterprise AI, a stronger standard is:

Question
→ Governed Interpretation
→ Trusted Data Path
→ Executable Query
→ Traceable Result
→ Evidence-Backed Answer

The difference is not cosmetic.

It changes how the system can be trusted, evaluated, debugged, audited, and improved.

## Final Thoughts

AI data agents are rapidly improving at generating SQL.

But SQL generation is only one stage in a much larger correctness problem.

A production system should be able to answer two questions:

What is the answer?

and:

What evidence produced that answer?

That evidence should include the business definition, source data, relationships, filters, SQL, execution result, and validation state.

Not because every user wants to inspect every detail.

But because enterprise trust should be based on something stronger than model confidence.

A trustworthy data agent does not just return a number. It preserves the chain of evidence that makes the number verifiable.

The Reasoning Tax: Why AI Data Agents Waste Tokens Relearning Your Schema

Arisyn — Tue, 18 Aug 2026 02:49:01 +0000

If your data agent has to rediscover metric definitions, table relationships, and trusted query paths on every request, you are spending LLM reasoning on knowledge your system should already have.

AI data agents are becoming increasingly capable.

A modern agent can:

retrieve schemas;
interpret business terms;
identify candidate tables;
infer joins;
generate SQL;
validate queries;
execute them;
explain the result.

That looks like progress.

But from an engineering perspective, there is an uncomfortable question:

How much of this work is genuinely new reasoning, and how much is the agent repeatedly rediscovering facts the enterprise already knows?

That repeated work creates a hidden cost: the reasoning tax.

## A Typical Data Agent Does Too Much at Query Time

Consider this question:

What was revenue by customer last quarter?

A typical agent pipeline may look like:

User Question
      ↓
Intent Detection
      ↓
Schema Retrieval
      ↓
Business Term Resolution
      ↓
Candidate Table Selection
      ↓
Relationship Discovery
      ↓
Join Path Selection
      ↓
Metric Construction
      ↓
SQL Generation
      ↓
SQL Validation
      ↓
Execution

Now the user asks:

Show customer revenue for Q2.

The analytical intent is almost identical.

But many implementations repeat most of the pipeline.

The agent may again retrieve schemas, resolve Revenue, identify Customer, compare join paths, and choose the reporting date.

This is wasteful because much of that information is not query-specific.

*## Separate Query-Time Reasoning From Reusable Knowledge
*
A useful engineering distinction is:

Reusable Enterprise Knowledge
vs.
Query-Specific Reasoning

### Reusable Enterprise Knowledge

Examples:

Revenue = Recognized Revenue

Customer = canonical customer entity

Revenue Date = recognition_date

Customer → Order = trusted relationship

Order → Revenue = validated query path

These should not be probabilistically reconstructed on every request.

### Query-Specific Reasoning

Examples:

What is the user asking?

Does "last quarter" mean fiscal or calendar quarter?

Should results be grouped by customer or customer segment?

Is the user asking for a comparison?

What should be investigated next?

These genuinely depend on the current request.

The design principle is:

Retrieve the known. Reason about the unknown.

## Why the Reasoning Tax Matters

There are three immediate engineering consequences.

### 1. Token Usage

Suppose schema retrieval returns 30 tables, each with:

table descriptions;
columns;
data types;
comments;
sample values.

The agent may receive thousands of tokens before reasoning even starts.

If every query repeatedly includes the same structural information, token consumption scales with query volume.

A rough model is:

Total Token Cost
≈
Requests
×
(Context Tokens + Reasoning Tokens + Output Tokens)

Reducing repeated context has a direct effect on cost.

### 2. Latency

Agent workflows often involve multiple model or tool calls:

Retrieve
→ Classify
→ Resolve
→ Plan
→ Generate
→ Validate

Even if each step takes only a small amount of time, the total latency accumulates.

If a trusted metric definition can be returned from a deterministic service in milliseconds, there is little value in asking an LLM to infer it again.

### 3. Inconsistency

Repeated reasoning also introduces variability.

One request may produce:

Revenue → invoice_amount

Another:

Revenue → recognized_revenue

Another:

Revenue → order_amount

The model may be behaving reasonably in all three cases.

The architecture is simply asking it to repeatedly solve an ambiguous problem.

Govern the definition once and retrieve it consistently.

## Schema Retrieval Is Necessary, but It Is Not Enough

A common NL2SQL architecture is:

Question
   ↓
Embedding Search
   ↓
Relevant Tables
   ↓
LLM
   ↓
SQL

This is much better than sending the entire warehouse schema.

But table retrieval still leaves unresolved questions:

Which metric is authoritative?

Which entity is canonical?

Which relationship is trusted?

Which date field should be used?

Which join path is safe?

Retrieval that returns only schema is still forcing the LLM to reconstruct business knowledge.

A richer query context should return something closer to:

question: "revenue by customer last quarter"

metric:
  name: revenue
  definition: recognized_revenue
  aggregation: SUM

dimensions:
  - customer

time:
  field: recognition_date

tables:
  - customer
  - sales_order
  - finance_revenue

trusted_path:
  - customer
  - sales_order
  - finance_revenue

Now the LLM is not discovering the data model.

It is using it.

## Precompute Relationship Knowledge

Relationship inference is a major source of unnecessary query-time reasoning.

Suppose the agent needs to connect:

Customer

to:

Payment

It may discover several candidate paths:

Customer → Order → Invoice → Payment

Customer → Account → Payment

Customer → Contract → Invoice → Payment

If the organization has already validated the first path for this analytical scenario, there is no reason to compare all three paths again.

Relationship knowledge can be discovered ahead of time using evidence such as:

Primary / Foreign Keys
Column Naming
Value Overlap
Uniqueness
Inclusion Ratio
Historical Query Patterns
Business Validation

For example:

A = order.customer_id
B = customer.customer_id

A useful signal is:

Inclusion(A → B)
=
|distinct(A) ∩ distinct(B)|
---------------------------
|distinct(A)|

Relationship candidates can then move through:

Discovered
    ↓
Candidate
    ↓
Validated
    ↓
Trusted

Query-time agents should preferentially retrieve the trusted result.

## Move Metric Resolution Out of the Prompt

Metric definitions are another common source of repeated reasoning.

Instead of embedding this in every system prompt:

When the user says revenue, use recognized_amount
from finance_revenue unless...

maintain a governed metric object:

{
  "metric": "revenue",
  "version": "2.1",
  "aggregation": "SUM",
  "table": "finance_revenue",
  "column": "recognized_amount",
  "time_field": "recognition_date",
  "status": "active"
}

The agent calls:

get_metric_definition("revenue")

and receives the current definition.

This has several advantages:

one definition across agents;
easier versioning;
easier auditing;
less prompt complexity;
fewer tokens;
less ambiguity.

## Build Query Context Before Calling the LLM

A useful architecture is:

                User Question
                     │
                     ▼
          ┌────────────────────┐
          │ Context Resolver   │
          ├────────────────────┤
          │ Business Terms     │
          │ Metrics            │
          │ Metadata           │
          │ Relationships      │
          │ Trusted Paths      │
          └─────────┬──────────┘
                    │
                    ▼
             Trusted Context
                    │
                    ▼
                  LLM
                    │
             Reason / Generate
                    │
                    ▼
                   SQL

The LLM receives only what is relevant.

This changes the role of the model.

Before:

LLM = Data Discovery + Business Interpretation + Reasoning + SQL

After:

Data Layer = Known Enterprise Facts

LLM = Intent + Reasoning + SQL / Analysis

## A Simple Context Resolver

Conceptually, the resolver could work like this:

def build_query_context(question):
    concepts = resolve_business_terms(question)

    metrics = get_metric_definitions(concepts)
    entities = get_business_entities(concepts)

    metadata = get_relevant_metadata(
        metrics=metrics,
        entities=entities
    )

    relationships = get_trusted_relationships(
        metadata.tables
    )

    return {
        "metrics": metrics,
        "entities": entities,
        "metadata": metadata,
        "relationships": relationships
    }

Then:

context = build_query_context(question)

sql = llm.generate_sql(
    question=question,
    context=context
)

The exact implementation will vary.

The architectural point is that the model does not have to infer every layer of enterprise knowledge itself.

## Cache Stable Knowledge at the Right Level

Not all knowledge changes at the same frequency.

For example:

Table Schema
→ changes occasionally

Metric Definition
→ changes occasionally

Trusted Relationship
→ changes occasionally

User Question
→ changes every request

This suggests different caching and refresh strategies.

A system might maintain:

Metadata Cache
Semantic Cache
Relationship Cache
Query Context Cache

with invalidation triggered by:

Schema Change
Metric Version Change
Relationship Update
Governance Update

This is more efficient than treating every query as a completely new reasoning problem.

## MCP Can Expose the Known Layer

For agent-based architectures, MCP can provide a clean interface to reusable enterprise knowledge.

For example:

get_metric_definition

get_business_entity

get_table_metadata

get_trusted_relationships

get_query_context

The agent workflow becomes:

Question
   ↓
Agent
   ↓
MCP Tools
   ↓
Enterprise Data Intelligence
   ↓
Trusted Context
   ↓
LLM Reasoning

MCP does not remove the need for semantic or relationship intelligence.

It gives agents a standardized way to access it.

## Do Not Confuse Precomputation With Hard-Coding

Moving knowledge out of query-time reasoning does not mean freezing the data model.

Enterprise knowledge changes.

Schemas evolve.

Metrics change.

Relationships change.

The reusable layer therefore needs:

Discover
   ↓
Detect Change
   ↓
Evaluate Impact
   ↓
Validate
   ↓
Version
   ↓
Publish
   ↓
Invalidate Cache

The objective is not:

Never reason about the data model again.

It is:

Do not reason about the same established data knowledge on every request.

## Measure the Reasoning Tax

Teams can make this problem observable.

Useful metrics might include:

### Context Tokens per Query

Average tokens sent before generation

*### Reasoning Calls per Query
*

Average LLM calls required before SQL execution

*### Schema Candidates per Query
*

How many tables / columns must the model evaluate?

### Relationship Resolution Rate

% of queries using prevalidated relationships

### Metric Resolution Rate

% of business metrics resolved without LLM inference

### Time to First SQL

Question received
→
Executable SQL generated

These metrics can reveal whether the agent is spending most of its time solving analytical problems or reconstructing the enterprise data model.

## The Optimization Target Changes

A common optimization question is:

Which model gives the best SQL accuracy?

That still matters.

But production systems should also ask:

How much unnecessary reasoning are we forcing the model to perform?

A more capable model may hide poor architecture by successfully reasoning through large amounts of noisy context.

That does not make the architecture efficient.

The better system may be the one that gives the model less to figure out.

## Final Thoughts

AI agents are good at reasoning.

Reasoning is also probabilistic, expensive, and slower than deterministic lookup.

So use it where it adds value.

If Revenue already has a governed definition:

retrieve it.

If Customer already has a canonical entity:

retrieve it.

If a join path is already trusted:

retrieve it.

Then let the model solve the genuinely new problem:

what the user is asking and how to analyze it.

The next generation of enterprise data agents may not win by thinking harder.

They may win by knowing what they no longer need to think about.

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

Arisyn — Fri, 14 Aug 2026 01:38:04 +0000

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

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

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?

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

A sales agent might map:

Revenue → sales_order.total_amount

A finance agent might use:

Revenue → finance_revenue.recognized_amount

An analytics agent might retrieve:

Revenue → finance_invoice.invoice_amount

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

The same applies to data relationships:

Customer
   ↓
Order
   ↓
Invoice
   ↓
Payment

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

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

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"
  ]
}

But raw metadata alone is not enough.

### 2. Business Semantics

The agent should be able to resolve:

"recognized revenue"

into something like:

metric: revenue
definition: recognized revenue
aggregation: SUM
source:
  table: finance_revenue
  column: recognized_amount

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

along with evidence or confidence information.

For example:

{
  "path": [
    "customer",
    "sales_order",
    "invoice",
    "payment"
  ],
  "status": "trusted"
}

### 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

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

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?

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

For example, if:

A = order.customer_id
B = customer.customer_id

we can calculate:

Inclusion(A → B)
=
|distinct(A) ∩ distinct(B)|
---------------------------
|distinct(A)|

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

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()

An agent could then call:

Agent
  ↓
MCP
  ↓
Shared Data Intelligence Services

But MCP itself does not determine:

What Revenue means

Which customer definition is authoritative

Which join path is trusted

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

So the shared layer needs its own lifecycle:

Discover
   ↓
Detect Change
   ↓
Evaluate Impact
   ↓
Validate
   ↓
Version
   ↓
Publish

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)

changes to:

Revenue v2
=
SUM(recognized_amount)

With agent-local knowledge:

Sales Agent → update
Finance Agent → update
Analytics Agent → update
Management Agent → update
Support Agent → maybe update

Someone has to discover every dependency.

With shared semantics:

Revenue Definition
       ↓
Version Update
       ↓
Shared Data Intelligence
       ↓
All Authorized Agents

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

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

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.

Models will change.

Agents will change.

Frameworks will change.

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

Semantic Drift: The Hidden Failure Mode of Enterprise AI Analytics

Arisyn — Wed, 12 Aug 2026 15:20:00 +0000

Enterprise AI systems rarely fail only because the model is weak.

A more subtle failure happens when the model is working correctly, the SQL executes successfully, and the result looks reasonable — but the system is reasoning over an outdated representation of the business.

This is semantic drift.

As more teams put semantic layers between LLMs and enterprise data, maintaining those semantics becomes a production engineering problem rather than a one-time modeling task.

The database changes.

Business definitions change.

Relationships change.

If the AI's understanding does not change with them, accuracy degrades quietly.

A Semantic Layer Is Runtime Infrastructure

A common AI analytics architecture looks roughly like this:

User Question
     ↓
LLM / Query Agent
     ↓
Semantic Layer
     ↓
Enterprise Data

The semantic layer may contain:

business terms;
metric definitions;
dimensions;
mappings to physical tables and columns;
relationships used to generate queries.

This helps prevent an LLM from guessing directly from raw schemas.

But there is an important consequence:

Once AI depends on the semantic layer at query time, stale semantics become a runtime failure.

The problem is that semantic models are often maintained as if they were documentation.

Define them once.

Review them.

Publish them.

Then assume they remain correct.

Enterprise data does not behave that way.

Failure Mode 1: Schema Drift

Suppose a metric is mapped to:

customer.customer_id

After a warehouse migration, the organization introduces:

account_customer.customer_key

The old table may remain available for compatibility.

That creates a dangerous situation.

Nothing necessarily breaks.

The old query can still execute.

The semantic mapping is simply pointing to a representation that is no longer authoritative.

Traditional schema monitoring may tell you that a column was added.

AI analytics needs to answer a harder question:

Does this schema change invalidate any business meaning used by the AI?

That requires connecting physical metadata changes to semantic dependencies.

Failure Mode 2: Semantic Drift

Semantic drift happens even when the schema does not change.

Consider:

Active Customer

Version 1:

customer.status = 'ACTIVE'

Later, the business changes the definition:

customer with >= 1 completed order in the last 90 days

The database can remain exactly the same.

But the meaning has changed.

An AI system using the old definition may continue returning perfectly valid SQL and perfectly wrong business answers.

This is why execution success is a weak validation signal for enterprise AI.

SQL succeeded != business meaning is correct

Failure Mode 3: Relationship Drift

This problem becomes more interesting when queries span multiple tables.

Imagine the original analytical path is:

Customer
   ↓ customer_id
Order

After an ERP redesign:

Customer
   ↓
Account
   ↓
Order

The old join may still work because legacy identifiers remain populated.

But the organization has changed the business relationship.

An LLM that sees both paths now has multiple executable options.

Which one is correct?

This cannot be solved reliably with schema retrieval alone.

The system needs maintained relationship knowledge.

Why Embeddings Do Not Solve Drift

A common approach is to embed schema metadata and retrieve relevant tables for each question.

For example:

User Question
     ↓
Embedding Search
     ↓
Relevant Tables / Columns
     ↓
LLM
     ↓
SQL

This is useful for reducing schema size.

But semantic similarity does not tell us whether a definition is current.

Embedding search may find:

invoice_amount
recognized_revenue
payment_amount

for the term:

revenue

All three are semantically related.

Only business governance can determine which one currently represents the metric.

Likewise, embeddings may identify two similar identifiers, but similarity does not prove that they form the trusted join path.

Retrieval solves relevance.

It does not solve validity.

Treat Semantic Assets Like Versioned Code

If semantic definitions affect AI-generated answers, they should be treated more like production code than documentation.

A metric definition should have:

metric: revenue
version: 2.1
status: active
definition: recognized revenue
source:
  table: finance_revenue
  column: recognized_amount
valid_from: 2026-07-01

A relationship should also carry explicit evidence:

relationship:
  from: customer.customer_id
  to: account.customer_id
type: business_validated
confidence: 0.97
status: active

The exact format is less important than the engineering principle:

Meaning needs identity, state, history, and validation.

Without versioning, it becomes difficult to answer basic production questions:

Which definition generated this answer?
When did that definition change?
Which queries are affected?
Can we roll back?

Detect Changes Before They Become Wrong Answers

A living semantic system needs change detection.

At the physical layer, monitor:

New table
Column added
Column removed
Type changed
Constraint changed

At the relationship layer:

New candidate relationship
Join coverage changed
Identifier uniqueness changed
Relationship confidence changed

At the semantic layer:

Metric definition changed
Mapping became ambiguous
Business term changed
New semantic version published

The important part is not generating more alerts.

It is calculating impact.

For example:

finance_invoice.invoice_amount changed
                 ↓
revenue metric mapping affected
                 ↓
12 query templates affected
                 ↓
AI queries using Revenue require validation

Now schema monitoring becomes useful to AI governance.

Relationship Discovery Should Produce Candidates, Not Truth

Automatically discovering relationships can help keep a data model current.

Signals may include:

declared primary/foreign keys;
naming similarity;
value overlap;
uniqueness;
inclusion ratio;
historical joins.

For two columns A and B, a simple inclusion signal could be:

inclusion(A → B)
=
|distinct(A) ∩ distinct(B)|
---------------------------
|distinct(A)|

A high value can indicate a possible relationship.

But it should not automatically become trusted business logic.

A better lifecycle is:

Relationship Detected
        ↓
Candidate
        ↓
Evidence / Confidence
        ↓
Validation
        ↓
Trusted Relationship

This distinction matters.

Automated discovery improves coverage.

Governance establishes trust.

Human-in-the-Loop Is a Feature, Not a Failure

Enterprise semantics often cannot be inferred safely from technical metadata alone.

If the system finds:

Revenue

mapped plausibly to both:

sales_order.total_amount

and:

finance_revenue.recognized_amount

the correct behavior may be to ask for clarification.

A useful workflow is:

Ambiguity Detected
       ↓
Candidate Definitions
       ↓
Human Review
       ↓
Validate With Query
       ↓
Publish New Version

The goal of automation is not to eliminate domain experts.

It is to stop asking them to manually rediscover every schema and relationship change.

A Practical Living Data Model Loop

Putting the pieces together, the lifecycle looks like:

1. Discover metadata
        ↓
2. Detect schema and relationship changes
        ↓
3. Identify impacted semantic assets
        ↓
4. Generate candidate updates
        ↓
5. Validate ambiguous business meaning
        ↓
6. Version and publish
        ↓
7. Use validated semantics for AI queries
        ↓
8. Repeat

This is fundamentally different from:

Build semantic layer → Done

The semantic model becomes an operational system.

What Should Be Monitored?

A few useful signals include:

Semantic Coverage

How much of the active analytical surface has governed meaning?

governed metrics / queried metrics

Relationship Coverage

How many required multi-table query paths are backed by trusted relationships?

Ambiguity Rate

How often does a business term map to multiple plausible definitions?

Stale Mapping Rate

How many semantic mappings reference changed or deprecated physical assets?

Validation Failure Rate

How often do proposed semantic or relationship updates fail business validation?

These metrics tell you more about production readiness than simply measuring whether SQL execution succeeds.

The Key Engineering Shift

The first generation of LLM analytics focused heavily on query generation.

The next engineering challenge is maintaining the data knowledge used to generate those queries.

A stronger model cannot compensate for a stale business definition.

A larger context window cannot determine whether an old join path is still authoritative.

And better embeddings cannot decide when the organization changed the meaning of revenue.

The system needs a maintained layer of enterprise data knowledge.

Not static metadata.

Not a one-time semantic project.

A living model.

Final Thoughts

If your AI analytics system depends on business semantics, those semantics are production infrastructure.

Treat them accordingly.

Monitor changes.

Track relationships.

Version definitions.

Detect ambiguity.

Validate business meaning.

Because the most dangerous enterprise AI failure is not always a broken query.

Sometimes the query works perfectly — against yesterday's understanding of the business.

Building AI Analysts: Why Enterprise Analytics Needs More Than BI Dashboards

Arisyn — Mon, 10 Aug 2026 01:25:31 +0000

For decades, enterprises have relied on dashboards as the primary way to consume business data.

A typical workflow looks like:

Business Question
↓
Find the Right Dashboard
↓
Select Filters
↓
Review Metrics
↓
Human Analysis

This model works well for predefined questions.

But modern businesses increasingly ask questions that were never designed into dashboards:

Why did sales decline in East China last month?

Answering this requires combining:

sales data;
customer data;
product data;
regional information;
order history.

A dashboard can show what happened.

But understanding why it happened requires deeper analysis.

This is where AI Analysts become valuable.

From BI Dashboards to AI Analysts

AI changes the interaction model.

Instead of searching for reports, users can directly express business questions.

Business Question

↓

AI Understanding

↓

Data Discovery

↓

Multi-dimensional Analysis

↓

Business Insight

The goal is not simply generating charts.

The goal is helping users understand:

What happened?
Why did it happen?
What factors contributed?
What should be investigated next?

Why Building AI Analysts Is Difficult

Connecting an LLM to a database is not enough.

Enterprise analytics requires understanding the business behind the data.

An AI Analyst needs to understand:

business concepts;
data relationships;
analytical logic.

Understanding Business Concepts

Business users do not think in tables.

They ask:

Show me high-value customers.

But enterprises may have:

customer_table

account_table

crm_customer

billing_customer

The AI needs to understand:

Which customer definition is correct?
Which attributes define value?
Which data source should be trusted?

A business concept is not always a table.

It is a combination of entities, metrics, rules, and relationships.

Understanding Data Relationships

Enterprise analysis rarely depends on one table.

A typical path may involve:

Customer
↓
Order
↓
Contract
↓
Payment

However, enterprises often contain:

multiple applications;
duplicated entities;
different identifiers;
historical data models.

A database may allow many joins.

But only some relationships represent business logic.

The important question is not:

Can these tables be joined?

It is:

Is this the correct business relationship?

Moving From Answers to Analysis

Traditional systems answer:

What is the number?

AI Analysts should answer:

Why is this number changing?

For example:

Sales decreased last month. Why?

The system should analyze:

regional changes;
customer changes;
product changes;
historical trends.

This requires dynamic analysis instead of fixed dashboards.

The Architecture Behind AI-Native Analytics

A future analytics system is not simply:

User
↓
LLM
↓
Database

A more reliable architecture requires:

User Question

↓

AI Understanding

↓

Semantic Layer

↓

Relationship Intelligence

↓

Query Generation

↓

Analysis Result

AI needs to understand:

Business Semantics

What does the data mean?

Examples:

revenue definition;
active customer definition;
inventory calculation.

Data Relationships

How is enterprise data connected?

Examples:

customer to order;
order to invoice;
invoice to payment.

Analytical Context

What analysis should happen next?

Examples:

comparison;
trend analysis;
root cause exploration.

The Future of Enterprise Analytics

The next generation of analytics will combine:

large language models;
semantic understanding;
relationship intelligence;
enterprise data governance.

The future is not about creating more dashboards.

It is about creating AI systems that can become intelligent partners in business analysis.

Final Thoughts

Traditional BI helped enterprises understand what happened.

AI Analysts will help enterprises understand why it happened.

But this requires more than connecting an LLM to a database.

AI needs to understand business concepts, data relationships, and analytical context.

Only then can enterprise AI move from answering questions to supporting real analysis.

Beyond Data Lineage: Building Observability for AI-Generated Queries

Arisyn — Wed, 05 Aug 2026 15:19:00 +0000

Enterprise AI is moving from experimentation to production.

Organizations are deploying AI assistants that can query databases, generate reports, and analyze business data.

The first challenge was making AI capable of answering questions.

The next challenge is making those answers trustworthy.

When an AI system provides an answer, enterprises need to understand:

What data did AI use?
Why did AI choose those tables?
Which business definitions were applied?
How was the final answer generated?

This is where traditional data observability needs to evolve.

Traditional Data Observability Was Built for Data Pipelines

For years, enterprises focused on understanding how data moved.

A typical lineage looks like:

Source Database

↓

ETL Pipeline

↓

Data Warehouse

↓

BI Report

Organizations needed to know:

Where did data come from?
Which pipeline transformed it?
Which reports depend on it?

This became the foundation of modern data governance.

However, AI introduces a different type of data consumption.

AI does not only move data.

AI interprets data.

AI Creates a New Observability Challenge

Consider a question:

Why did sales decrease last month?

An AI assistant may:

Understand the question.
Select relevant data sources.
Generate SQL.
Execute the query.
Explain the result.

The final answer may look reasonable.

But enterprises need more visibility.

They need to understand:

User Question

↓

AI Interpretation

↓

Business Definition

↓

Selected Data Sources

↓

Relationship Path

↓

Generated SQL

↓

Final Answer

This is different from traditional data lineage.

It is AI reasoning lineage.

Why AI Query Results Need Explainability

Traditional BI systems use predefined reports.

Users usually know:

which metric is used;
which data source is connected;
how calculations are performed.

AI-powered analytics changes this.

The query path can be generated dynamically.

The selected tables may change.

The SQL may be different for different questions.

Therefore, AI systems need to explain not only the answer, but also the reasoning behind the answer.

The Four Layers of AI Data Observability

AI data observability extends traditional data governance with new capabilities.

1. Query Lineage

Traditional lineage asks:

Where did this data come from?

AI query lineage asks:

How did AI produce this answer?

It should capture:

user question;
generated SQL;
selected tables;
filters;
returned datasets.

2. Semantic Lineage

Enterprise concepts often have multiple meanings.

For example:

Revenue may mean:

sales revenue;
recognized revenue;
invoice amount;
payment amount.

AI observability needs to record:

which business definition was used;
which metric mapping was applied;
which semantic rules affected the answer.

3. Relationship Lineage

Enterprise queries often depend on relationships:

Customer

↓

Order

↓

Invoice

↓

Payment

AI needs to know:

which relationship path was selected;
why this path was chosen;
whether the relationship is trusted.

A valid SQL join does not always represent a valid business relationship.

4. Answer Explainability

Enterprise users need more than a result.

They need to understand:

where the data came from;
what logic was applied;
what assumptions were made.

This is critical in industries where decisions depend on reliable data.

From Data Governance to AI Governance

Traditional data governance focused on:

data quality;
metadata;
lineage;
ownership.

AI introduces new requirements:

AI query traceability;
semantic consistency;
relationship validation;
answer transparency.

The question is changing from:

"Can we manage enterprise data?"

to:

"Can we trust how AI uses enterprise data?"

Final Thoughts

AI can generate answers quickly.

But enterprises need more than speed.

They need confidence.

Traditional data lineage helped organizations understand how data moved.

AI observability will help organizations understand how AI reasons over data.

The future of enterprise AI will belong to systems that are not only intelligent, but also transparent and trustworthy.

Building Data Intelligence for Reliable Enterprise AI

Arisyn — Mon, 03 Aug 2026 15:37:00 +0000

Large language models are becoming more capable every year.

They can generate SQL, write code, analyze documents, and interact with enterprise systems through tools.

However, when organizations move AI applications from prototypes to production, a common problem appears:

AI can access enterprise data.

But access does not mean understanding.

Many enterprise AI failures are not caused by weak models.

They are caused by the fact that enterprise data was designed for applications and humans, not for AI systems.

Data Access Is Not Data Intelligence

Modern enterprises already have mature data platforms:

relational databases;
data warehouses;
data lakes;
BI systems;
metadata management platforms.

These systems solve an important problem:

How do we store and access data?

AI introduces a different challenge:

How does AI understand and use this data correctly?

A database can tell an AI system:

this is a customer table;
this is a revenue column;
this field contains an identifier.

But it usually cannot explain:

which customer definition is trusted;
what revenue means in this business context;
how data from different systems should be connected.

The difference is the gap between data access and data intelligence.

Why Traditional Metadata Is Not Enough

Many enterprise AI systems start by providing metadata to LLMs.

For example:

Table: customer

Columns:
customer_id
customer_name
create_time

This information helps AI discover available data.

But it does not provide enough business understanding.

Consider a simple question:

Who are our most valuable customers?

An enterprise may have:

crm_customer

erp_customer

billing_customer

All three tables may contain customer information.

The challenge is not finding these tables.

The challenge is understanding:

Are they the same business entity?
Which one is authoritative?
How should they be related?

Without this knowledge, AI has to guess.

And guessing creates unreliable answers.

Data Intelligence Starts With Business Meaning

Enterprise data contains many ambiguous concepts.

A common example is:

Revenue

It may represent:

sales revenue;
recognized revenue;
invoice amount;
payment amount;
contract value.

From a database perspective, all of these are valid fields.

From a business perspective, they answer different questions.

Humans resolve this ambiguity through experience.

AI needs this business meaning to be explicitly available.

This is why semantic understanding is a fundamental requirement for enterprise AI.

Relationships Are the Hidden Challenge

Enterprise data is not a collection of isolated tables.

Business processes connect data together.

A simple example:

Customer

↓

Order

↓

Invoice

↓

Payment

However, real enterprise environments are much more complex.

Organizations often have:

multiple systems;
duplicated entities;
inconsistent identifiers;
historical data models.

A database may allow many possible joins.

But only some relationships represent real business logic.

A technically valid join does not always mean a business-valid relationship.

For AI applications, trusted relationships matter.

Why Bigger LLMs Are Not Enough

A common assumption is:

"If the model becomes smarter, it will solve enterprise data problems."

Better models definitely improve reasoning capabilities.

But models cannot automatically know enterprise-specific knowledge.

They cannot magically determine:

which data source the company trusts;
which metric definition is correct;
which relationship represents the real business process.

The problem is not only intelligence.

The problem is the intelligence available around the data.

Building an AI-Ready Data Intelligence Layer

Reliable enterprise AI requires more than connecting an LLM to a database.

It requires data intelligence capabilities.

Business Entity Understanding

AI needs to understand important business objects:

Customer;
Product;
Supplier;
Contract;
Project.

Not just as database tables.

As business entities.

Data Semantic Understanding

AI needs to understand:

business terms;
metric definitions;
calculation logic;
organizational language.

The same field name can represent different meanings across organizations.

Trusted Data Relationships

AI needs to understand:

which entities are connected;
which relationships are reliable;
which data paths should be used.

This enables AI to generate answers based on trusted enterprise knowledge.

The Future of Enterprise AI Data Architecture

Traditional data platforms answered:

Where is the data?

AI requires a deeper answer:

What does this data mean?

How is it connected?

Can AI trust it?

The next generation of enterprise data architecture will not replace databases, warehouses, or lakes.

Instead, it will add intelligence that makes enterprise data understandable and usable for AI systems.

Final Thoughts

Enterprise AI is not only a model problem.

It is also a data intelligence problem.

Large language models provide reasoning capabilities.

Data intelligence provides the foundation that allows those capabilities to work reliably.

The future of enterprise AI will not only depend on smarter models.

It will depend on smarter data.

Why Enterprise AI Needs Data Semantics and Relationships

Arisyn — Fri, 31 Jul 2026 14:47:00 +0000

Large language models are becoming increasingly powerful.

They can generate SQL, write code, summarize documents, and reason through complex tasks.

However, when enterprises try to deploy AI systems in production, a common problem appears:

AI can access the data.

But it does not always understand the data.

This is where many enterprise AI projects struggle.

The problem is not only model capability.

It is the missing context behind enterprise data.

## The Difference Between Data Access and Data Understanding

Modern data platforms are excellent at storing and processing information.

They provide:

databases;
data warehouses;
data lakes;
metadata catalogs;
BI systems.

From a technical perspective, AI can retrieve:

table names;
column names;
data types;
sample values.

But enterprise questions are rarely only technical questions.

For example:

What are our top customers this year?

A database can show customer-related tables.

But AI still needs to understand:

Which customer definition should be used?
Which system is the authoritative source?
Does customer mean account, buyer, or contract owner?

The missing information is not stored data.

It is business meaning.

## Data Semantics: Teaching AI What Data Means

One of the biggest challenges in enterprise AI is that business concepts are often ambiguous.

Consider the word:

Revenue

An enterprise may have:

sales_amount
invoice_amount
payment_amount
contract_value

All of these contain financial information.

But they represent different business concepts.

A financial analyst understands the difference.

An AI system does not automatically know.

Without semantic understanding, AI may generate a technically valid answer that is still wrong from a business perspective.

The SQL executes successfully.

The business decision fails.

## Data Relationships: The Hidden Complexity Behind Enterprise Data

Enterprise data rarely exists in isolation.

A simple business process may involve:

Customer

↓

Order

↓

Invoice

↓

Payment

But real enterprise environments are much more complicated.

Organizations often have:

multiple customer tables;
different identifiers;
duplicated entities;
historical schemas;
disconnected applications.

Technically, many joins are possible.

Business-wise, only some relationships are meaningful.

This creates an important distinction:

A possible relationship is not always a trusted relationship.

## Why LLMs Cannot Solve This Automatically

A common assumption is:

"If the model becomes smarter, it will understand enterprise data."

But intelligence does not replace missing information.

A powerful LLM can reason about:

A → B → C

But it still needs to know:

What is A?
What does B represent?
Is this relationship valid?

If enterprise knowledge is not explicitly represented, the model has to guess.

And guessing creates unreliable AI.

## Building More Reliable Enterprise AI

Future enterprise AI systems need more than better models.

They need a stronger connection between AI and enterprise knowledge.

This requires three important capabilities.

### 1. Business Entity Understanding

AI needs to understand core business objects:

customers;
products;
suppliers;
contracts;
projects.

Not only as database tables.

As business entities.

### 2. Trusted Relationship Understanding

AI needs to understand how entities connect.

Not every foreign key or possible join represents business logic.

The system needs to identify trusted paths between data.

*### 3. Business Semantic Understanding
*
AI needs to understand business definitions.

Metrics.

Terms.

Rules.

Context.

Because the same field name can mean different things in different organizations.

## The Next Evolution of Enterprise Data Architecture

Traditional data platforms answered:

Where is the data?

AI requires a different answer:

What does this data mean?

How is it connected?

Can we trust it?

The future enterprise data stack will not replace databases or warehouses.

Instead, it will add a layer that makes enterprise knowledge understandable to AI systems.

## Final Thoughts

The next challenge in enterprise AI is not only building smarter models.

It is reducing the amount of guessing AI has to do.

Data semantics help AI understand meaning.

Data relationships help AI understand connections.

Together, they provide the missing context required for reliable enterprise AI.

Because AI does not only need access to enterprise data.

It needs to understand the business behind it.

The Next Enterprise Data Platform Won't Be Built for Humans

Arisyn — Thu, 30 Jul 2026 14:22:00 +0000

For decades, enterprise data platforms were designed around one assumption:

Humans are the primary users of data.

Data engineers build pipelines.

Analysts explore datasets.

Business users consume dashboards.

Applications execute queries.

The entire data stack evolved around helping people find, transform, and analyze information.

But AI is becoming a new type of data consumer.

And it changes the requirements completely.

The next generation of enterprise data platforms won't only need to store and process data.

They will need to help machines understand it.

Traditional Data Platforms Were Built for Access

The evolution of enterprise data platforms has always focused on improving access.

First came relational databases.

The goal was reliable transaction processing.

Then data warehouses appeared.

The goal became centralized analytics.

Later, data lakes and lakehouses emerged.

The goal was to store massive amounts of structured and unstructured data.

Each generation solved important problems.

But they shared the same assumption:

Someone already understands the business meaning behind the data.

A data analyst knows which table contains the trusted revenue number.

A developer knows which customer table should be joined.

A business expert knows what "active customer" actually means.

The platform provides data.

Humans provide understanding.

AI Changes the Consumer of Data

AI systems work differently.

An analyst can ask a colleague:

"Which customer table should I use?"

An AI agent cannot.

A developer can remember:

"Never join these two tables directly."

An AI agent cannot.

A business user knows:

"Revenue means recognized revenue, not invoice amount."

An AI agent may not.

This creates a new architectural challenge.

Enterprise data platforms were built to answer:

Where is the data?

AI needs them to answer:

What does this data represent?

Schema Is Not Enough

Most AI systems start with metadata:

tables
columns
data types
relationships
descriptions

This information is useful.

But it only describes structure.

Consider a large enterprise with multiple systems:

CRM
 |
ERP
 |
Finance
 |
Supply Chain

Each system may contain customer information.

Each system may use different identifiers.

Each system may have different business purposes.

A human employee understands that these records may represent the same business entity.

A model looking only at schemas sees disconnected tables.

The missing information is not more data.

It is meaning.

The Future Data Platform Needs More Than Storage

If AI becomes a major consumer of enterprise data, future platforms need additional capabilities.

Business Entity Understanding

AI needs to understand important business objects:

Customer
Product
Supplier
Employee
Contract
Project

Not just as tables, but as real business concepts.

Relationship Understanding

Enterprise knowledge is often hidden in relationships.

A customer connects to orders.

Orders connect to invoices.

Invoices connect to payments.

These relationships are not always defined by foreign keys.

Many exist through business rules, historical decisions, and operational experience.

AI needs trusted relationships, not guessed joins.

Business Semantic Understanding

The same word can mean different things across departments.

"Revenue" for finance may differ from "sales" for operations.

"Customer" in marketing may differ from "customer" in accounting.

AI needs business definitions, not only column descriptions.

From Data Platform to AI-Ready Data Infrastructure

This does not mean replacing existing databases or warehouses.

Those systems remain essential.

The change is that enterprises need another layer on top of existing data.

A layer that connects:

Business Concepts

        ↓

Data Relationships

        ↓

Physical Data

        ↓

AI Applications

This layer helps AI move from retrieving information to understanding information.

The Next Competition Will Not Only Be About Models

Many organizations are investing heavily in:

larger models
faster inference
better agents
more powerful infrastructure

These improvements matter.

But model capability alone does not solve enterprise understanding.

Two companies can use the same AI model and achieve completely different results.

The difference is often not the model.

It is the quality of the enterprise knowledge behind the model.

Final Thoughts

For years, enterprise data platforms were optimized for humans.

Humans interpreted the meaning.

Humans connected the dots.

Humans resolved ambiguity.

AI changes that relationship.

The next generation of data platforms will not only answer:

"Where is the data?"

They will help answer:

"What does this data mean, how is it connected, and when can it be trusted?"

The future enterprise data platform is not just a place where data lives.

It is a foundation that allows AI to understand how the business works.

AI Didn't Break Enterprise Data Models. It Exposed Their Blind Spots.

Arisyn — Wed, 29 Jul 2026 15:09:00 +0000

Over the past few years, I've worked with several enterprise AI projects, especially those involving natural language querying and AI-powered analytics.

One pattern keeps showing up.

When an AI system returns the wrong answer, people usually blame the model.

"Maybe we need a larger LLM."

"Maybe the prompt needs more context."

"Maybe SQL generation isn't mature enough."

After digging into these projects, I came to a different conclusion.

In many cases, the model isn't the real problem.

The enterprise data model is.

Enterprise Data Models Were Never Designed for AI

For decades, enterprise databases have been optimized for applications.

Normalization reduces redundancy.

Indexes improve query performance.

Foreign keys maintain integrity.

Data warehouses organize information for reporting.

Everything makes sense because applications already know how the business works.

Business logic lives in source code, service layers, stored procedures, ETL pipelines, and developers' experience—not necessarily in the database itself.

Applications don't need the database to explain what a "customer" is.

Developers already know.

AI doesn't.

Schema Describes Structure, Not Meaning

Most AI systems start by reading metadata.

They can discover tables.

Columns.

Primary keys.

Sometimes foreign keys.

But metadata only tells AI how data is stored.

It doesn't explain what the data actually represents.

For example, imagine an enterprise with three different systems.

CRM stores customers.

ERP stores accounts.

The finance system stores billing entities.

To employees, these often represent the same business entity viewed from different business processes.

To AI, they are simply three unrelated tables.

Without additional business knowledge, every SQL statement becomes an educated guess.

The Hardest Problem Isn't Writing SQL

Modern language models are surprisingly good at generating SQL.

Syntax errors have become much less common.

The bigger challenge appears earlier.

Before generating SQL, AI must answer questions like:

Which customer table should I use?
Which data source is considered authoritative?
Are these two entities actually the same customer?
Which relationship reflects real business rules?

These aren't SQL problems.

They're knowledge problems.

Business Knowledge Lives Outside the Database

One thing I find interesting is that enterprise knowledge is rarely stored where AI can access it.

Developers understand join paths.

Business analysts understand metric definitions.

Database administrators understand physical schemas.

Domain experts understand the business process.

Each group holds part of the knowledge.

Very little of it is represented explicitly in the data model itself.

Humans bridge these gaps naturally.

AI cannot.

AI Has Become a New Consumer of Enterprise Data

This is probably the biggest architectural change we're seeing.

For years, applications were the only consumers of enterprise databases.

Now AI is becoming another consumer.

Unlike applications, AI doesn't read source code.

It doesn't attend design meetings.

It doesn't ask senior developers which table is "correct."

It only sees what the enterprise has documented.

And many enterprises have documented far less than they assumed.

The Future Isn't About Bigger Models

Large language models will continue to improve.

They'll write better SQL.

Reason more effectively.

Handle longer contexts.

But none of these improvements automatically provide business knowledge.

If an enterprise hasn't clearly defined its business entities, trusted relationships, or business semantics, AI has no reliable foundation to reason from.

The model can infer.

It can estimate.

It can guess.

It cannot know.

Final Thoughts

I don't think AI is exposing weaknesses in language models.

It's exposing weaknesses in enterprise data architecture.

For years, our data models were built to support applications.

Today, they also need to support AI.

That doesn't necessarily mean redesigning every database.

But it does mean making business entities, relationships, and business semantics far more explicit than they have been in the past.

The smarter AI becomes, the more valuable well-structured enterprise knowledge will be.