The many places AI agents go for business context

An AI agent can make a remarkably thorough tour of your company before writing a single line of SQL. It can retrieve a process document, query an ERP, inspect a dashboard metric, and follow relationships in an ontology. After all those stops, it may still be guessing what “on-time delivery” means.

A recent VentureBeat Pulse survey puts numbers behind this tour. In August 2026, 67% of respondents reported running, piloting, or building a governed semantic or context layer. Yet only 13% named a governed semantic layer or ontology as their AI agents' primary source of business context.

Where were agents looking instead? Retrieval over documents led at 32%, followed by direct queries to live systems at 21% and loading large inputs into the model's context window at 19%.

The survey asked respondents to select one primary source, so these findings don't mean agents exclusively use one approach. A live query may access governed data, and a retrieval system may surface an approved definition.

But for data engineers working with coding agents, the results raise a more fundamental question: when business context is spread across so many sources, how does an agent know which rules to implement?

RAG can retrieve business context without knowing how to apply it correctly

Internal documentation is often the closest written record of how a company operates. Requirements documents, meeting transcripts, operating procedures, dashboard descriptions, and technical specifications can contain the decisions behind existing data models.

Retrieval-augmented generation (RAG) helps agents find relevant passages without requiring every document to fit into the model's context window.

It can bring these passages to the agent's attention, but doesn't inherently establish which document or passage takes precedence when there’s a conflict.

Consider a coding agent building an on-time delivery model for a distribution company.

A retrieved operations playbook says a delivery is late when it arrives after the original customer promise. Another document describes an exception for expedited replacement shipments. Both passages might be useful. But does the exception still apply? Was it approved for customer reporting or only for internal operations?

Even a well-configured retrieval system with document metadata, permissions, and version information depends on business decisions being recorded in the first place. A recently updated document may describe a local workaround, while an older policy remains authoritative.

Finding a relevant passage is easy to mistake for finding an approved requirement.

Live systems tell agents what happened, with less certainty about what it means

After RAG, the second major route to business context for AI agents is direct access to live systems.

Through SQL, APIs, or Model Context Protocol (MCP) servers, agents can query enterprise databases and applications as they work. A coding agent can inspect source tables, profile records, understand schema relationships, and test assumptions against real data.

For the delivery model example above, the agent might find requested_delivery_date and confirmed_delivery_date in an ERP, alongside delivered_at in a carrier feed.

Those fields provide useful information about delivery events, but don't necessarily explain which date should determine whether the company met its customer commitment.

The agent can inspect the data to understand how these fields behave, but choosing which events count toward a contractual performance metric requires business context beyond their names and values.

Of course, direct access doesn't necessarily mean raw access. An API or MCP tool can expose governed metrics and approved business logic. A coding agent querying a governed service may receive a more authoritative answer than one querying source tables directly.

The question for the data team is what business rules sit behind the interface, rather than which access protocol the agent uses.

A larger context window can hold more conflicting definitions

Yet another approach is to load the available business context directly into the model.

A data engineer might directly provide a coding agent with a requirements document, SQL examples, data dictionaries, meeting transcripts, and screenshots of existing reports. With a sufficiently large context window, the agent can examine substantial amounts of source material in one session.

This approach is particularly useful during the exploration and planning stage. Agents can compare documents, identify missing information, and flag conflicting definitions.

But having every document available doesn't establish which business rule is authoritative. Without explicit direction, the agent may favor the most detailed explanation, the most recent document, or the interpretation that seems most plausible.

Once the agent translates its interpretation into SQL transformations, the assumption becomes harder to notice. Tests generated from the same assumption may pass, even when the business logic is wrong.

A larger context window helps agents examine more evidence but doesn’t automatically provide the authority to settle an unresolved business requirement.

Semantic layers and ontologies give approved definitions a consistent home

Governed semantic layers offer a more structured way to supply business context to coding agents.

Rather than asking agents to infer metrics from tables and descriptions, a semantic layer defines business metrics, dimensions, entities, and relationships for consistent use across applications.

For example, the dbt Semantic Layer centralizes metric definitions in a dbt project and exposes them to downstream consumers. AI agents can access these governed metrics through the dbt MCP server.

Ontologies and knowledge graphs can go further in representing relationships between business entities, concepts, and rules. A curated ontology might describe how customer accounts relate to legal entities, or how shipments, orders, and fulfillment events connect.

These approaches can substantially reduce the amount of business logic an agent has to infer.

But even governed definitions have boundaries.

A company may maintain separate delivery-performance metrics for warehouse efficiency and customer service-level agreements. Both can be correct within their intended scope. The agent still needs to understand which business outcome the requested data pipeline should support.

And if an exception remains unresolved between Operations and Customer Success, a semantic layer can preserve the definitions those teams have approved. It cannot independently establish a new policy on their behalf.

Governed models become especially useful once business decisions are explicit. I explored this relationship in more depth in my article on semantic layers versus context layers.

When context sources disagree, the data team needs a decision

Multiple approaches provide useful access to business knowledge. The difficulty becomes apparent when sources return competing interpretations of the same business requirement.

Each specific business requirement shapes the data model, transformation rules, and tests used to determine whether the output is correct.

In the VentureBeat survey, 64% of respondents said their organizations had traced at least one confidently wrong AI agent answer to missing or inconsistent business context during the previous six months.

The survey covers enterprise AI agents broadly, rather than data coding agents specifically. But the failure mode has a particularly lasting consequence in data engineering: an incorrect interpretation can become version-controlled transformation logic, pass automated tests, and feed downstream reporting.

More access to business context gives agents more evidence to work with. Data teams still need a reliable process for turning conflicting evidence into approved requirements.

Spec-driven development turns scattered business context into buildable requirements for coding agents

The more business context a coding agent can access, the more important it becomes to establish which rules it should follow. Spec-driven development addresses this by moving business discovery and requirements definition ahead of implementation.

Rather than asking an agent to interpret business knowledge as it writes code, data engineers first gather requirements from people, documents, and systems of record. They investigate conflicting definitions, establish source-of-truth rules, and surface decisions requiring human approval. These findings become a tailored, versioned specification containing the agreed business logic, mappings, exceptions, and validation criteria.

A spec gives coding agents a consistent reference for building a data pipeline. It also makes correctness measurable. Instead of relying solely on tests generated from the agent's own assumptions, engineers can validate the output against approved business requirements and trusted figures.

Maxa Autopilot Spec helps data teams carry out business discovery systemically, turning scattered business context from meeting transcripts, dashboard screenshots, documents, and more into a specification. It identifies gaps and contradictions, supports follow-up questions, and preserves the decisions coding agents need to implement business logic correctly.

As agents become better at navigating enterprise data, their ability to find business context will continue to improve. But finding context and establishing what the business requires are different responsibilities. A spec brings those responsibilities together, giving coding agents clear requirements to implement and data engineers a reliable basis for verifying the result.