Business Context Data Models Agents

Business context is the hardest thing for AI agents to get right on data work. Knowing that a 'customer' in billing means something different from a 'customer' in product is what separates a useful agent from a confident liar. This guide walks through four patterns that teach agents business context without guessing.

Technical context (schema, lineage, types) is easy to provide automatically from the catalog. Business context has to be captured explicitly, kept fresh, and injected into agent runs at the right moment.

Pattern 1: The Semantic Layer

A semantic layer defines business-meaningful metrics (MRR, active users, NPS) in a single place, decoupled from the underlying SQL. When an agent is asked about revenue, it queries the semantic layer's definition of revenue rather than inventing its own aggregation. Cube, LookML, and dbt's semantic layer all support this pattern.

Pattern 2: Data Contracts

Data contracts capture the business meaning of a dataset as a versioned artifact: what each column represents, what business rules always hold, and who owns the interpretation. Agents read contracts before querying, which grounds their interpretation in documented intent rather than guessed convention.

Pattern 3: Business Glossaries

• •Term definitions — 'customer,' 'order,' 'ARR' defined once, referenced everywhere
• •Team attribution — which team owns which definition
• •Synonym mapping — users, members, subscribers all map to the same concept
• •Effective dates — definitions change over time, and agents need to know which version applies
• •Deprecated terms — flagged so agents do not use old vocabulary
• •Cross-domain mapping — billing's customer vs product's user, explicitly linked

Pattern 4: Conversation Memory With Business Tags

When an agent learns business context during a conversation ('for this quarter, exclude test accounts'), that context should be tagged and stored in long-term memory. Future conversations with the same team or project re-inject the context automatically. Data Workers' memory layer handles tagging and retrieval automatically. See autonomous data engineering.

Where Agents Still Fail

Even with all four patterns, agents fail on brand-new context that nobody has written down. The fix is a graceful fallback: when the agent hits an ambiguous term, it asks the user instead of guessing. Data Workers' agents are designed to escalate ambiguity rather than hallucinate context. See AI for data infrastructure.

Keeping Context Fresh

Business context drifts constantly. Teams reorganize, products launch, metrics get redefined. A stale semantic layer or glossary is worse than none because agents trust it and produce confidently wrong answers. Run a monthly review of your business context artifacts, and set up alerts when definitions change so stakeholders can sign off.

Measuring Business Context Quality

The best measure is human correction rate. When humans correct an agent's interpretation of business context, that is a signal that your context layer is incomplete. Track corrections over time; a healthy pipeline sees corrections drop as the context layer matures. Ideal target: fewer than 1 correction per 50 agent tasks on established domains.

Business context is the highest-leverage investment you can make in data agent accuracy. Semantic layer, contracts, glossary, memory — the four patterns compound. To see how Data Workers wires them together, book a demo.

One of the best investments a data team can make is in a single canonical business glossary owned by a named person. Without a canonical glossary, every conversation about metrics rediscovers definitions from scratch. With one, agents and humans both reference the same source of truth. The glossary does not have to be fancy — a well-maintained Notion page or a git-tracked markdown file works fine. What matters is that someone owns it, keeps it current, and is the escalation point for definition disputes.

Data contracts are particularly valuable when they cross team boundaries. When the finance team publishes a 'monthly_revenue' data product, the contract captures not just the schema but also the definition ('revenue recognized in the month, excluding refunds, in USD, at the company exchange rate on the last day of the month'). Agents that read the contract get the definition automatically, which means they cannot accidentally use a different definition than the one finance publishes. This eliminates a whole class of cross-team data disputes.

Version control for business context is the operational piece most teams miss. When a definition changes, the change should be captured in git with an author, a date, and a rationale. Agents reading the glossary can then reference the specific version in effect at the time of the query, which matters for historical analysis. Data Workers' glossary storage uses git under the hood so version history is free.

The cross-team alignment work that happens when you build a business glossary is itself valuable. Most teams discover during the glossary exercise that they have been using the same word to mean different things across teams. Surfacing the disagreements and reconciling them is painful but produces real organizational value. Agents benefit from the cleaner definitions, but the humans benefit even more from the alignment conversation.

Semantic layer, contracts, glossary, memory. Four patterns that encode business meaning so agents do not have to guess.