Why AI agents need clear business definitions

Most companies I’ve worked with have plenty of data. What they’re short of is the meaning, written down somewhere a machine can use it.

Here’s a test you can run this week. Ask three teams what an “active customer” is. You may get three answers, each useful inside its own system. People often bridge the gap by knowing which report to trust and which colleague to ask. An agent needs those distinctions made explicit. Otherwise, it can give a confident answer using a definition the person asking never intended.

That gap matters when an answer becomes a decision: who receives an offer, which orders count toward a target, or what a customer gets when an item is out of stock. Business teams need to own the definitions and policies. Technology teams need to connect them to data, check that they work, and give agents an agreed scope.

I’ve been studying this on my own time, with synthetic data, because I kept running into it at work and wanted to sort out the vocabulary. This first post lays out the concepts. Later posts explore them through experiments you can repeat.

I’ll use one illustrative example throughout. A grocer fills online orders. A customer ordered oat milk, the shelf is empty, and somebody has to decide what to offer instead. A replacement can look similar and still conflict with the customer’s preferences, a declared allergy, or the agreed price limit.

There are two parts to getting that decision right: what holds the meaning, and what keeps it trustworthy as products, policies and data change. I separate the first into six responsibilities. They can share tools and platforms; the distinction is about what each one contributes to the decision.

What holds the meaning

Ontology: defining the business

An ontology describes the kinds of things in a domain, their relationships, and the logical definitions that give them meaning.

The question it answers is what exists, how does it relate, and what does it mean?

I start with three lists to make the model and its business policies easy to review.

• Concepts. Item, Customer, Allergen, Substitution Group, Substitution.
• Relationships. An Item contains Allergens. A Customer declares an allergy to an Allergen. An Item belongs to a Substitution Group. A Substitution replaces an ordered Item with an offered Item.
• Business rules. In this example, the customer must allow substitutions. The offered item must be in the same substitution group, pass the declared-allergen checks, and stay within the agreed price tolerance. It must also be available when the decision is made.

Those rules turn “a reasonable substitute” into conditions people can agree on and systems can check. Writing them down is only the first step. The system evaluating the substitution must enforce them.

For technical readers, OWL expresses logical definitions and supports inference; SHACL validates data against stated conditions. Operational policies may also need a rule engine or application checks. An ontology alone doesn’t enforce every business rule.

People often ask how this differs from a data model. A conceptual data model can also describe business meaning. The useful comparison here is with a physical schema for an application.

	Physical schema	Shared ontology
Main concern	How an application stores data	What concepts and relationships mean across systems
Example	Product keys, columns and tables	What counts as an Item and how it relates to an Allergen
A change to review	A column is renamed or a table is split	The business changes the definition of a substitution group

The ontology supplies the definitions in this example. The current stock of oat milk at store 114 comes from operational data.

Terminology: consistent names and meanings

A terminology gives concepts consistent names and records how names and concepts relate. It distinguishes an equivalent name from a related concept.

The question: do these names refer to the same thing, or to things that are related?

Two systems might use “barista oat drink” and “barista oat milk” for the same product. The terminology records the approved names against its identifier. A taxonomy organizes broader and narrower categories, such as “plant-based milk” and “oat milk”. Matching product identifiers across systems also needs an identity mapping.

Healthcare illustrates why the distinction matters. RxNorm names fully specified clinical drugs by ingredient, strength and dose form. It links generic and branded drug concepts to each other and to their ingredients. Those relationships carry more information than a list of synonyms.

Similarity search can suggest a match. Establishing that names are interchangeable needs an authoritative mapping or review by the people responsible for the meaning.

Knowledge graph: connected facts

A knowledge graph records particular things and their relationships. In a governed graph, those facts use agreed definitions such as the ones in an ontology.

The question: what do we know about this thing, and what is it connected to?

The illustrative graph records that a particular barista oat milk belongs to the plant-based barista substitution group, and that a customer declared an almond allergy in March. Its allergen information comes from an identified product source. A missing allergen entry must not be treated as proof that the item is free of that allergen. In this example, incomplete information means the agent withholds the recommendation.

If the ontology is the blueprint, the graph records the things described by it. You can explore data in a graph while developing the model. Before an agent relies on it, the definitions and relationships used for its decisions need review and validation.

For this example, the graph could hold product reference data and relationships, with links to orders and inventory in their existing systems of record. What belongs in the graph depends on the workload, freshness requirements and platform capabilities.

Semantic layer: agreed calculations

A semantic layer defines metrics, dimensions and the relationships used to calculate them. A dimension is a way to group or filter a result, such as store or week.

The question: how is this number computed?

For our example, substitution acceptance rate is accepted replacement offers divided by all replacement offers, by store and the week the offer was made, excluding orders cancelled before picking started. Count each offer once. If there are no offers, report no rate.

Changing the denominator or date can change the number while leaving its label unchanged. Shared definitions let dashboards and agents calculate the same metric from the same data.

Semantic layers encode business logic through filters, joins and metric definitions. Here, they handle measurement, while the substitution checks decide whether an item may be offered. Both need agreed definitions of “offer” and “acceptance”.

Bindings: connecting definitions to data

Bindings map the concepts and relationships to the data that supplies them: tables, columns, identifiers, files or APIs.

The question: where do we get the data for this concept?

An Item might get its identity from a product table, its allergen information from an attribute feed, and its availability from an inventory service.

Bindings record how the sources join, which source is authoritative, and any relevant units, transformations and freshness requirements. “Available” means little without knowing when stock was checked.

When a source changes, the team can update and validate its mapping while keeping the business definition consistent across dashboards and agents.

Context layer: what an agent sees and uses

A context layer assembles the definitions, evidence and tools a particular agent needs for a task, within the caller’s permissions.

The question: what should this agent see and use right now?

The substitution agent working on an order at store 114 gets the relevant rules, the order’s preferences, approved product and allergen data, and current stock information. It has no reason to receive supplier cost or unrelated customers’ records.

A prompt or a retrieval index can contribute to that context. The responsibility also includes choosing the relevant definitions, checking permissions, and preserving the source and version of the information supplied. Access controls must be enforced by the data services and tools themselves; omitting information from a prompt is not an access control.

The context layer depends on the quality of those inputs. It cannot make an incorrect definition or stale stock reading trustworthy.

The decision behind the vocabulary

The grocer still needs to answer a few practical questions. Are two product names referring to the same item? Which alternatives belong to the agreed substitution group? Is the allergen information complete? How fresh is the stock reading? Does the customer permit this replacement?

Each concept helps make one part of that decision explicit. The system still has to check the evidence and policy before presenting a recommendation. Measuring acceptance later requires another agreement: what counts as an offer, and when does it count as accepted?

These are questions business and technology teams need to settle together before choosing an implementation.

What keeps the meaning trustworthy

A business changes: new products arrive, policies change, and metrics are redefined. An agent can start answering differently even when its model and prompt stay the same. Four habits help make those changes visible.

Changes are reviewed by the people who own the meaning

Meaning should change the way code does: someone proposes a change, the person responsible for that meaning reviews it, and an approved version is released.

A model can read documents and schemas and suggest concepts, relationships and mappings. The business owner still needs to decide whether a returned purchase counts toward “active customer”, or which items belong in a substitution group. The record should say who made that decision, who approved it, and when it took effect.

Before approval, show what the change touches: metrics, mappings, tests and agent tools. A small definition change can affect several reports and decisions.

Answers are tested against questions with known answers

A successful demo doesn’t establish that the model handles the cases that matter.

I write down the questions the model has to answer in the words a person would use. For each one, I build a small synthetic dataset where I know the right answer, and plant near misses that fail exactly one condition. Then I check the results again whenever the meaning changes.

For the grocer, tests should cover an item in the wrong substitution group, an item outside the price tolerance, missing allergen information, stale stock, and a customer who declined substitutions. The checks need to test refusals as well as recommendations.

Synthetic tests make the policy testable. Production monitoring must also check whether source data stays complete and current.

Each answer records the definitions and evidence it used

If someone asks in March why an agent recommended an item in January, the useful reply names the policy and definitions in force then, together with the evidence used for that decision.

Keep the released versions and record which ones each answer used. Preserve enough source evidence, or references to retained snapshots, to explain the result. A policy version alone cannot explain a decision that also depended on stock, price and customer preferences.

Versioning makes changes traceable. Detecting unintended drift also needs checks against the current sources and business policy.

Each agent works inside an enforced boundary

An agent needs a written boundary: what it may read, which tools it may call, what it may change, and on whose behalf. Reads still need authorization. Actions need permissions and checks matched to their consequences.

For this example, the agent can propose a replacement; changing the order waits for the required human approval. Other low-risk actions may be preauthorized under an explicit policy. The tools must enforce those limits.

An agent that lacks the evidence to answer should say what is missing and why it matters. Tests should catch both unnecessary refusals and recommendations made without the required evidence.

What your existing tools already cover

You may already have parts of this in a catalog, BI model, graph store or application. A semantic model may define acceptance rate; the ordering application may enforce the price limit; a product feed may carry allergen information.

The question is whether those definitions agree, who owns them, and whether an agent can use them within its permissions. Start by identifying what is already defined and where the gaps are. The six responsibilities can share existing tools; how to implement them depends on the problem.

Which piece answers which question

Question	Main responsibility
What concepts exist, and how do they relate?	Ontology
Do these names mean the same thing, or something related?	Terminology
What do we know about this thing and its connections?	Knowledge graph
How is this number computed?	Semantic layer
Which sources supply the data, and how are they mapped?	Bindings
What should this agent receive for this task?	Context layer

These responsibilities overlap in implementation. Review, tests, version records and enforced permissions apply across all of them.

Where to start

Data warehouses and BI already depend on shared definitions. Agents bring that problem into workflows where an answer may trigger an action. A wrong interpretation of “eligible”, “available” or “acceptable” can change what happens to an order or a customer.

Start with one decision an agent should support. Write down its concepts, policy and data sources. Agree who owns each definition, then test a valid case, a near miss and a case with missing information. Business and technology teams now have something concrete to review together.

For the grocer, the question is simple: what evidence must be present before we offer this customer a replacement? The rest of this series explores how to make questions like that explicit, testable and maintainable.

---

The grocer and its policy in this post are illustrative. This is written for learning purposes only and the views are my own. Find me on LinkedIn.