Building Reliable Data Context for Multi-Step AI Agents

Why semantic meaning, relationship evidence, and analytical grain must survive every step of an AI workflow.

An enterprise AI agent can now do more than generate a SQL query. It can retrieve data, calculate growth rates, run additional analyses, create charts, and draft recommendations.

That sounds like progress—and it is. But a longer workflow introduces a subtle problem: a mistake in the data context at the beginning can contaminate every subsequent step.

A valid query does not guarantee a valid business metric. Correct Python does not guarantee the underlying dataset is correct. A persuasive narrative does not guarantee that the joins preserved the right grain.

The reliability of a multi-step agent is constrained by the reliability of the context it carries forward.

One question, several hidden decisions

Imagine a sales executive asks:

Why did European revenue decline last quarter?

Before the agent can calculate anything, it must resolve several business decisions:

• Does revenue mean booked, invoiced, or recognized revenue?
• Does Europe refer to the customer's country, sales territory, or legal entity?
• Is last quarter a calendar or fiscal quarter?
• Which tables represent the metric and dimensions?
• Which relationship path preserves the intended analytical grain?

An agent may execute SQL correctly while answering a different question from the one the executive intended.

Business question
      ↓
Business meaning
      ↓
Physical data mapping
      ↓
Relationship selection
      ↓
Query and aggregation
      ↓
Python / additional analysis
      ↓
Business conclusion

Each arrow is a boundary where context can be lost, changed, or misinterpreted.

The fanout trap: valid joins, wrong results

Consider one order with two lines and three payment records.

Order lines

Payments

The total line amount is 150. The total paid amount is also 150. But this SQL is wrong for calculating line totals:

SELECT SUM(ol.amount) AS line_total
FROM order_lines ol
JOIN payments p ON p.order_id = ol.order_id
WHERE ol.order_id = 42;

Each order line is repeated for every payment. The result is 450, not 150.

This is not a SQL syntax error. It is a grain and cardinality error.

If the agent then feeds the inflated figure into a Python script, the script may calculate trends and rankings flawlessly—using incorrect inputs.

A safer pattern aggregates the two facts independently before combining them at a shared grain:

WITH lines AS (
  SELECT order_id, SUM(amount) AS line_total
  FROM order_lines
  GROUP BY order_id
),
payments_by_order AS (
  SELECT order_id, SUM(paid_amount) AS payment_total
  FROM payments
  GROUP BY order_id
)
SELECT l.order_id, l.line_total, p.payment_total
FROM lines l
JOIN payments_by_order p ON p.order_id = l.order_id
WHERE l.order_id = 42;

This fixes the fanout issue. It does not establish that line_total is the approved definition of recognized revenue. That still requires business semantics.

The four layers of reliable data context

For multi-step agents, I find it useful to separate context into four layers.

1. Business semantics: what are we measuring?

The agent should resolve business language into governed metrics, dimensions, and rules rather than selecting columns by name similarity alone.

{
  "metric": "recognized_revenue",
  "dimension": "sales_region",
  "period": "previous_fiscal_quarter",
  "metric_owner": "finance"
}

This is an illustrative contract, not a vendor-specific API.

2. Physical mapping: where does that meaning live?

The agent must map the metric and dimensions to actual fields, including date semantics and filters.

Recognized Revenue → revenue_fact.recognized_amount
Sales Region       → territory.region_code
Recognition Date   → revenue_fact.recognition_date

A similar-looking column is not automatically an equivalent business concept.

3. Relationship context: how can the data be connected?

Relationship discovery can identify plausible joins, including paths through bridge tables. But a structurally plausible relationship is not necessarily an analytically safe join.

The agent should distinguish:

Relationship candidate
        ↓
Join-key evidence
        ↓
Cardinality and grain checks
        ↓
Approved analytical path

The checks are essential. A relationship graph can tell you which tables connect; the query plan must still determine whether a join multiplies a metric.

4. Execution context: what assumptions must remain stable?

Once the initial query has been validated, downstream tools must retain the same metric, filters, time range, and units.

For example, a forecasting step should not silently switch from recognized revenue to invoiced revenue. A chart should not change from fiscal quarters to calendar quarters without an explicit decision.

Carry a context contract across the workflow

Instead of handing every step only a DataFrame or SQL string, preserve a structured context object:

{
  "question": "Why did European revenue decline last quarter?",
  "metric": {
    "id": "recognized_revenue",
    "owner": "finance"
  },
  "dimensions": ["sales_region"],
  "period": "previous_fiscal_quarter",
  "grain": "revenue_event",
  "relationships": [
    "territory -> customer",
    "customer -> revenue_fact"
  ],
  "checks": {
    "metric_definition_reviewed": true,
    "join_cardinality_validated": true,
    "time_window_validated": true
  }
}

These validation flags must be populated by real checks, not invented by an LLM. The schema is a suggested engineering pattern, not a claim that a particular product already implements it.

The context contract should accompany every downstream analytical step, alongside the query and dataset identifiers.

Where semantic and relationship platforms help

This architecture highlights two complementary capabilities.

Semora provides business-semantic definitions, terminology, mappings, metric/dimension context, ambiguity handling, and natural-language query generation and validation. IntaLink focuses on discovering candidate relationships between tables and fields and making relationship paths available as context.

Conceptually:

Question
   ↓
Semora: interpret business concepts and map them to data
   ↓
IntaLink: provide candidate relationship paths
   ↓
Semora: construct and validate the query
   ↓
Data result

Semora manages its own data connections; the corresponding source is mapped to IntaLink by data-source ID for relationship context. IntaLink is not the execution connection manager for Semora.

This is a foundation for more reliable querying, not a claim that Semora or IntaLink already performs sandboxed Python execution, forecasting, automated fanout prevention, or full multi-step error propagation analysis. Those are separate engineering concerns.

A practical validation strategy

For a production analytics agent, I would test the following before enabling longer autonomous workflows:

Also test a repair scenario: after a user corrects the metric or relationship, the agent should rerun affected calculations—not simply rewrite the final narrative.

Measure more than SQL success

Useful production measures include:

• Metric resolution accuracy: Did the agent select the intended business definition?
• Join/grain validation coverage: Were cardinality and aggregation risks checked?
• Context consistency: Did every step use the same metric, period, and filters?
• End-to-end analytical correctness: Does the final conclusion agree with a trusted reference analysis?
• Correction recovery: Can the workflow rerun downstream steps after an upstream correction?

A high SQL execution success rate can coexist with poor business accuracy. Both must be measured.

The broader lesson

As AI analytics moves beyond SQL into code execution and multi-step reasoning, the sophistication of the final analysis becomes less meaningful if the starting context is wrong.

Business semantics tell the agent what a metric means. Physical mappings locate the right data. Relationship evidence shows how tables may connect. Grain and validation checks determine whether the proposed query is analytically sound. Context contracts keep those decisions stable across steps.

Better reasoning cannot repair an incorrect understanding of the data.

The next generation of enterprise data agents will need more than powerful models and tool orchestration. They will need reliable data context that survives the entire analytical workflow.