Ask an AI assistant a seemingly simple question:
“What was our revenue last month?”
In many companies, that question does not have one obvious answer.
Sales may think about booked revenue. Finance may look at invoiced revenue. Another function may use recognized revenue. Different systems may contain different versions of the number, each perfectly reasonable in its own context.
A human employee who has worked in the company for ten years may know which definition to use. An AI agent does not.
This was one of the points that stuck with me from a session at the Ai4 conference in Las Vegas, presented by the CTO of SIXT. The company has invested heavily in AI, but one of its early findings was that the difficult part was often not building the AI itself. Much of the effort went into understanding the surrounding enterprise: What does this data mean? Where does it live? How can it be accessed? How does the process work? Which systems are involved, and how do they connect?
That is an important lesson for anyone currently building Retrieval-Augmented Generation systems or AI agents.
RAG can help an AI find information. It does not necessarily help the AI understand what the information means.
And as enterprises move from chatbots that answer questions to agents that take actions, that distinction becomes critical.
Retrieval is only the first layer of context
The basic idea behind RAG is compelling.
Instead of expecting a large language model to know everything, we give it access to relevant enterprise information. Documents are indexed, often converted into embeddings and stored in a vector database. When the user asks a question, the system retrieves relevant information and adds it to the model’s context.
This solves an important problem:
Where can I find information relevant to this question?
But consider our revenue example.
A RAG system may successfully retrieve five documents containing the word “revenue.” Unfortunately, one document discusses booked revenue, another invoiced revenue, and a third recognized revenue.
Retrieval has worked perfectly.
The agent may still produce the wrong answer.
This is not fundamentally a data-quality problem. The numbers may all be correct.
It is a semantic problem.
The SIXT presentation described exactly this kind of ambiguity. Depending on the department and use case, seemingly straightforward business concepts can have different definitions. Determining the correct definition can require considerable organizational knowledge—or, as the speaker effectively described it, a form of corporate archaeology.
We have spent years making enterprise information searchable.
Now we need to make enterprise meaning machine-readable.
The forgotten AI infrastructure: the data dictionary
Data dictionaries are hardly an exciting new technology.
Most organizations have had some version of them for decades. They describe tables, fields, data types, business definitions, ownership and sometimes lineage.
Historically, they have often been treated as documentation: useful for analysts, data engineers and auditors, but not exactly at the center of the technology strategy.
Generative AI changes that.
A properly maintained data dictionary can become part of the context that an AI agent uses to interpret enterprise information.
Imagine an agent encountering a field called booking_revenue.
Rather than guessing from the column name, it could retrieve additional context:
the business definition of booking revenue;
the authoritative source system;
the responsible business domain;
applicable currencies and conversion rules;
related KPIs;
known exclusions;
the owner responsible for the definition.
Suddenly, the dictionary is no longer passive documentation.
It becomes runtime context for AI.
That shift may make investments in data governance that previously felt bureaucratic surprisingly valuable.
But even a very good data dictionary only gets us so far.
A dictionary gives AI a vocabulary. An ontology gives it a worldview.
Defining individual terms is useful.
Understanding how those terms relate to each other is much more powerful.
This is where ontologies enter the picture.
An ontology describes the important concepts of a domain and the relationships between them. In a car-rental business, simplified relationships might look something like:
Customer → makes → Booking
Booking → fulfilled at → Branch
Booking → generates → Invoice
Invoice → contributes to → Revenue
Now the AI has more than definitions. It has a model of how the business fits together.
The SIXT approach described in the session goes in this direction. Metadata and KPI definitions are combined with an ontology representing major enterprise concepts such as countries, branches and customers, including how data and KPIs relate to those concepts.
That provides an agent with something much closer to a map.
It can potentially understand not merely that two documents both contain the term “branch,” but what a branch represents in the organization and how it relates to customers, bookings, systems and KPIs.
This becomes especially important when questions span multiple domains.
Consider:
“Identify branches where revenue declined by more than 10 percent and recommend corrective actions.”
Before an agent can answer reliably, it needs to resolve a surprising number of questions.
Which definition of revenue?
Compared with which period?
Which branch—the booking branch or the return branch?
Which currency?
Are cancelled bookings included?
Which system contains the authoritative value?
Which operating procedures should be considered before proposing an action?
A vector search alone cannot reliably provide all of those answers.
The agent needs context about the enterprise itself.
From RAG to an enterprise context layer
This was perhaps the most interesting architectural aspect of the SIXT presentation.
The company is not limiting this contextual information to structured data. There is additional knowledge covering processes and operating procedures, application landscapes and dependencies, as well as engineering standards and non-functional requirements.
Together, these components form what SIXT’s CTO described as an enterprise context layer that can be reused by different AI use cases.
I think this term is useful because it broadens the discussion beyond RAG.
An enterprise context layer might contain:
Data context: schemas, metadata, lineage, ownership.
Semantic context: definitions, KPIs, business terminology.
Ontological context: relationships between business concepts.
Process context: procedures, responsibilities and operating models.
Technology context: applications, interfaces and dependencies.
Governance context: security policies, coding standards and architectural constraints.
Instead of every AI project independently rediscovering these things, agents can draw on a common contextual foundation.
The architecture therefore starts to look less like:
User → LLM → Vector Database → Documents
and more like:
User → Agent → Enterprise Context Layer → Data, knowledge, systems and policies
That is a significant difference.
Agents make semantic ambiguity dangerous
For a traditional chatbot, getting the wrong definition of revenue is annoying.
For an autonomous agent, it can be an operational problem.
Imagine an AI agent with permission not only to analyze performance but to change pricing, contact customers, modify a booking process or deploy software.
The better our agents become at taking action, the more dangerous ambiguity becomes.
This is why agent governance cannot consist solely of permissions, approval workflows and audit logs.
Agents also need a governed understanding of the environment in which they operate.
We often ask:
What is this agent allowed to do?
We should increasingly also ask:
What does this agent believe our business concepts mean?
If every agent maintains its own collection of prompts, documents and interpretations, enterprises risk creating hundreds of slightly different machine-readable versions of themselves.
That is not scalable governance.
The AI bottleneck may not be AI
There is an uncomfortable conclusion here.
Many companies are currently investing heavily in models, vector databases, agent frameworks and orchestration platforms.
Those technologies matter.
But the limiting factor for enterprise AI may increasingly be much older problems:
inconsistent terminology, undocumented processes, unclear ownership, incompatible data models and several competing definitions of the same KPI.
Generative AI did not create those problems.
It simply makes them harder to ignore.
The good news is that work invested in solving them does not benefit only one AI project.
The SIXT speaker closed with exactly that lesson: investment in these foundations creates compounding results across use cases.
That may be one of the more important architectural shifts created by agentic AI.
Companies that prepared their data for dashboards built data platforms.
Companies that prepare their semantics for machines may be building something even more valuable: the operating context for their AI agents.
Since the early days of data warehousing, the demand for data dictionaries has been present to avoid misunderstandings and misinterpretations. Good to see that they now serve a new and even more fundamental purpose.