Enterprise Context and Ontology, and the role of the Cogentiq Context Layer
A perspective on why ontology, the oldest question in philosophy, has become the foundation of trustworthy enterprise AI, and how Cogentiq Context layer is addressing it.
June 2026
Author
Abhijeet Guha
Client Partner
The oldest question in the age of AI
Thousands of years before AI, databases, or even modern science existed, human beings were already wrestling with a profound question: What kind of world are we living in? It sounds deceptively simple. Yet it led some of history's greatest thinkers down an intellectual path that continues to shape how we think today. The ancient Greeks gave this inquiry a name: Ontology, the study of what exists and how the things that exist are connected to one another.
As philosophers observed the world around them, they began to notice something curious. Some things seemed undeniably real: trees, rivers, mountains, and people. But what about a nation? A law? A corporation? A marriage? These influence our lives every day, yet they cannot be touched or pointed to in the same way as a rock or a tree. What kind of existence do these things have? And how are they related to one another?
Ontology emerged as the attempt to answer these questions. Alongside it grew other foundational branches of philosophy: Epistemology, which asked how we know something is true; Logic, which explored how we reason correctly; and Ethics, which examined how we ought to act. Together, these disciplines formed humanity's earliest effort to make sense of reality.
At first glance, these questions may seem far removed from the modern enterprise paradigm of AI. Yet something remarkable is happening today. As we build increasingly autonomous agents, we are discovering that intelligence alone is not enough. Before an agent can reason, decide, or act, it must first understand the world it operates in. It must know what exists, what those things mean, and how they relate to one another.
In many ways, the ontologies and enterprise context layers emerging in AI are a continuation of this ancient pursuit. They are not trying to model all of reality, as philosophers once attempted. Instead, they seek to model a bounded reality, the world of an enterprise, a business function, or a specific problem domain. They are, in essence, an attempt to answer the same timeless question within a much smaller universe:
Why intelligence needs a model of reality
Ontology mattered to philosophers because they recognized a simple truth: intelligence cannot exist without understanding a model of reality. Before one can reason, decide, or claim to know anything, one must first grasp what exists and how things relate. A physician, a merchant, a scientist, a student, a teacher, a CEO, an employee navigates the world not by processing isolated facts but by carrying an internal ontology; a mental model of people, objects, events, causes, and consequences, built over a lifetime through experience, language, and culture.
Inside an enterprise, people simply know that customers buy products, that products generate revenue, that revenue contributes to profit, that employees staff projects, and that projects create outcomes. This shared, largely unspoken understanding is what allows humans to navigate complexity, make decisions, and collaborate even when the information in front of them is incomplete.
AI agents arrive without it. They can process information and reason over data, but they lack the underlying model of the world that gives data meaning. An agent may register that a revenue figure has moved; unless it understands concepts such as customer, product, invoice, margin, and business unit, and the relationships among them, it cannot reason about why the change happened or what to do about it. This is precisely why ontologies and enterprise context layers are becoming foundational to agentic AI. They give an agent the same conceptual map a person uses to navigate an organization. In effect, the enterprise context becomes the agent’s model of reality.
The challenge will not remain inside the enterprise. As AI evolves from software agents into embodied systems, robots will need to navigate the physical world much as humans do. Understanding not only a table, a cup, or a door, but also their purpose, their relationships, and the social context in which they sit. Just as philosophers sought to understand the structure of reality, we are now compelled to formalize that structure for non-human intelligence. The growing importance of ontology in AI may therefore be far more than a technical trend; it may be the first systematic attempt to teach machines to understand and navigate the digital world (perhaps the physical world soon too) in the same way humans always have.
Two worlds, one need
To make this concept tangible, let us explore two narratives: one rooted in daily life, the other in the modern enterprise
Jason in a new supermarket
Jason, a student, walks into an unfamiliar supermarket with her mother. “Go get me a bottle of ketchup,” says her mother. Jason has never set foot in this store, yet he usually manages to fetch the bottle. He does it not from a memorized floor plan, but from an internal model of the world. The world that he has built since childhood. Jason knows, from experience, that ketchup is a kind of food, that food lives in grocery aisles, that aisles sit inside supermarkets, and that products rest on shelves. That small web of relationships is an ontology, and he navigates reality simply by following its edges.
Now replace Jason with a robot and leave the instruction unchanged. Without an ontology, it sees only pixels, sensors, and words. It may even recognize a bottle and a shelf. But does it understand that ketchup is a condiment, that condiments are food, that food is stocked in grocery aisles, and that aisles exist within the store? Without that understanding, it stalls. The problem was never intelligence; it was understanding. Humans navigate the world through an implicit ontology. Machines require an explicit one.
A CFO and a decline in revenue
Now let’s move to an enterprise. A CFO asks a deceptively simple question: “Why did revenue decline in Europe?” A seasoned analyst does not begin with tables and databases. They begin by navigating an internal map of the business: revenue is generated by invoices; invoices are generated by orders; orders are placed by customers; customers belong to regions; and customers buy particular product lines. The analyst never consciously summons this graph; years of experience built it. They know where to look because they understand how the business works.
Give the same question to an agent without context, and it sees two numbers: revenue this quarter, revenue last quarter. It sees magnitudes, not meaning. Give it an enterprise ontology, and it can trace exactly the path a human would: from revenue to customer segment, to European customers, to product line, to the point where sales fell away. The ontology becomes the agent’s mental model of the enterprise.
This is how human experts have always worked. A doctor diagnosing a patient, a lawyer interpreting a contract, a manager running a business. Each is navigating an internal ontology built over the years. The only difference is where the model lives. In people, it is implicit; for agents, it must be made explicit. That is the work of the enterprise context layer: not a metadata repository, but the enterprise’s representation of reality.
The Cogentiq context
If an ontology is a model of reality, then the Context Layer is the mechanism through which that reality is captured, organized, governed, and made accessible to AI agents. Just as Jason relies on an internal understanding of the world to find the ketchup, an agent needs a structured understanding of the enterprise before it can reason and act. Cogentiq provides exactly that. It sits between an organization’s systems of record and the agents that serve its people, binding to the systems below, and grounding and governing the agents above.
A CFO and a decline in revenue
It is tempting to think of a Context Layer as something that can be designed once, implemented, and then forgotten. In reality, nothing could be further from the truth. Enterprises are living systems. New products are launched, policies evolve, organizational structures change, systems are modernized, acquisitions happen, and entirely new business questions emerge every day. The enterprise reality that an agent must understand today will not be exactly the same reality it needs to understand a year from now.
This is why we describe the Context Layer as a mechanism for capturing, organizing, and governing enterprise reality. These are not sequential implementation steps; they are ongoing responsibilities. Much like a city that expands and adapts as its population grows, an enterprise context must continually evolve as the organization does. A context layer that remains frozen at the point of creation will gradually lose relevance and eventually become just another repository of outdated documentation that nobody trusts. Cogentiq, therefore, treats context not as a static artifact to be built, but as a living asset to be continuously refined. The value of the Context Layer lies not only in how accurately it represents enterprise reality today, but also in how effectively it keeps pace with the enterprise reality of tomorrow.
Cogentiq models enterprise reality across three interconnected layers of context. Each answers a different question, and together they move an agent from universal understanding to situation-specific action.
Three layers of reality
When we think about reality, we often imagine a single world. In practice, humans navigate at least three different realities simultaneously.
The first is physical reality. It consists of tangible objects and events like the chair you are sitting on, the coffee cup on your desk, and the keyboard beneath your fingers. This is the world of things and actions.
The second is social reality. A piece of paper is a physical object, but a currency note is something more. A building is a physical structure, but a bank is a social institution. A person is a biological organism, but a CEO, doctor, customer, or employee are social roles that exist because we collectively agree they do. Much of human society operates within this shared layer of meaning.
The third is conceptual reality. Here live the abstract ideas that help us make sense of the world. Concepts such as ownership, trust, justice, supply and demand, disease, revenue, or education are not physical objects and do not belong to any single organization. They are enduring patterns and abstractions that help humans reason about reality itself.
Humans move across these layers of reality so naturally that we rarely notice it. Consider a doctor treating a patient. At one level, there is the immediate reality of the situation: a patient sitting in front of her, symptoms being described, test results being reviewed, and a treatment decision that needs to be made. But the doctor is also operating within a broader social reality. One person is recognized as a doctor, another as a patient; hospitals, medical licenses, and standards of care exist because society collectively accepts them. At an even deeper level, the doctor relies on concepts that transcend any individual patient or hospital: disease, diagnosis, treatment, prognosis, anatomy, and physiology. The doctor's intelligence comes not from operating in any one of these realities, but from seamlessly navigating across all three.
Enterprises work in much the same way. When a CFO asks, "Why did revenue decline in Europe?", the question begins with a very specific situation a particular quarter, a set of customers, products, transactions, and decisions that need to be understood. This is the reality captured by the Solution Context. Yet the answer cannot be found without understanding the organization itself: its business units, reporting structures, KPIs, governance processes, systems, and policies. This is the reality captured by the Organizational Context. And beneath both lies a more fundamental layer of understanding; concepts such as customer, invoice, revenue, margin, forecasting, and profitability that exist across companies and industries. This is the reality captured by the Domain Context. Just as humans reason by moving effortlessly between the situational, the organizational, and the conceptual, AI agents require the same layered understanding to reason effectively within an enterprise.
The Cogentiq Context Layer mirrors the way humans naturally understand the world. The Solution Context captures the immediate reality of a specific problem. The Organizational Context captures the reality of a particular enterprise. The Domain Context captures the conceptual reality of the business domain itself. Together, these layers provide agents with the similar bounded multi-layered understanding of an enterprise that humans use every day to navigate the world around them.
Domain context
The Domain Context captures the fundamental reality of a business domain, independent of any particular company. Consider finance. Whether an organization runs on SAP, Oracle, or a spreadsheet, the underlying concepts remain largely the same: customers buy products, products generate orders, orders generate invoices, and invoices ultimately create revenue. An experienced finance analyst understands this reality intuitively. The Context Layer makes that understanding explicit for an agent. The Glossary defines what concepts such as customer, invoice, revenue, and EBITDA mean. The Ontology describes how those concepts are connected. Data Bindings identify where the corresponding information resides. Rules and Policies capture the principles and constraints that govern the domain, such as when revenue may be recognized. Tool Bindings provide access to the systems and actions available to the agent. Skills and Prompts encode the reasoning patterns of experienced practitioners. Together, these artifacts provide an agent with something humans acquire through years of experience: an understanding of how the world of finance works.
Organizational context
The Organizational Context captures how a particular enterprise interprets and governs that reality. While the underlying concepts of a domain may be universal, every organization develops its own understanding of them. Two companies may both speak of “customers,” yet one may define a strategic customer as any account generating more than one million dollars in annual revenue, while another may set the threshold at ten million. One organization may treat Salesforce as the source of truth for customer information, while another relies on a different system. Approval workflows, reporting structures, governance policies, business unit hierarchies, and performance metrics vary from one enterprise to the next. When a new employee joins a company, a significant part of their learning journey involves absorbing these organizational nuances and understanding how things are done here. The Organizational Context performs the same function for an AI agent. The Glossary captures the enterprise's specific vocabulary and definitions. The Ontology describes how clients, business units, products, regions, and functions are organized and related. Data Bindings identify the enterprise's systems of record. Rules and Policies define governance, approvals, and operational constraints. Tool Bindings expose applications such as Salesforce, SAP, Workday, and ServiceNow. Skills and Prompts encode the organization's preferred ways of operating and making decisions. Together, these artifacts teach an agent something that domain knowledge alone cannot: how this particular enterprise works.
Solution context
The Solution Context captures the reality of a specific problem. Consider the question, "Why did revenue decline in Europe?" This is neither a general finance question nor merely an organizational question. It is a concrete problem that exists in a specific moment, involving a particular set of customers, products, transactions, forecasts, and business decisions. To answer it, the agent must adopt a specialized view of reality. It needs to understand concepts such as revenue leakage, pipeline conversion, forecast variance, and customer churn. It must know which datasets are relevant, which systems to query, which analytical tools to invoke, and which policies and confidence thresholds govern the analysis. Most importantly, it must reason the way an experienced CFO or financial analyst would; moving from symptoms to causes, identifying patterns, eliminating possibilities, and ultimately arriving at a recommendation. The Solution Context provides this situational understanding. It teaches the agent not merely what the enterprise is, but how to solve a particular problem within it.
Seen through a philosophical lens, these three contexts represent nested layers of reality. The Solution Context lies closest to the immediate reality of action; the specific situation, decision, or problem at hand. The Organizational Context represents the social reality of the enterprise, encompassing its structures, policies, roles, and shared understanding. The Domain Context represents the conceptual reality that transcends any individual organization the enduring concepts and relationships that define a business domain. Human intelligence operates effortlessly across these layers, moving from abstract concepts, to organizational understanding, to situation-specific action. The Cogentiq Context Layer is designed to provide agents with the same capability: the ability to navigate multiple layers of reality and use them together to reason, decide, and act.
The six context artifacts
Within each layer, context is expressed through six artifacts. Together, they answer the six questions any capable actor, human or machine, must be able to answer in order to operate competently in a domain.
Figure 6. Six artifacts, six questions; the cognitive scaffolding the Context Layer gives every agent.
To see how these artifacts work together, return to our finance analyst investigating a decline in revenue. Before the analyst can reason about the problem, they must first understand the language of the domain. When they hear the word revenue, they already know what it means. The Glossary provides this same understanding to an agent, establishing a shared vocabulary for concepts such as revenue, customer, invoice, and EBITDA.
But understanding individual concepts is not enough. The analyst also understands how those concepts relate to one another. Customers place orders, orders generate invoices, and invoices create revenue. The Ontology captures these relationships, providing the agent with a navigable model of the business world rather than a collection of isolated definitions.
Next comes the question of truth. Knowing that revenue exists is one thing; knowing where the authoritative revenue data resides is another. An experienced analyst knows which systems to trust. The Data Bindings provide the same guidance to the agent, connecting business concepts such as revenue and customer to their systems of record, whether those happen to be SAP, Salesforce, or another enterprise platform.
Of course, expertise is constrained by rules. A finance professional cannot simply interpret numbers however they choose. Revenue recognition policies, approval requirements, compliance controls, and accounting principles define the boundaries within which decisions are made. The Rules and Policies artifact encodes these constraints, ensuring that the agent operates within the same governance framework as its human counterparts.
Understanding and governance alone do not create outcomes. The analyst must also be able to act. They may run a report, query a system, perform an analysis, or generate a forecast. Tool Bindings provide these capabilities to the agent by exposing the actions available within the enterprise.
Finally comes expertise itself. Two analysts may have access to the same information and tools, yet arrive at different conclusions because one possesses deeper experience. The Skills and Prompts artifact captures this expertise, encoding the reasoning patterns used by experienced professionals to investigate anomalies, identify root causes, evaluate alternatives, and recommend actions.
Together, these six artifacts transform a collection of data into a coherent understanding of the finance domain:
| Artifact | The question it answers | In the finance domain |
|---|---|---|
| Glossary | What does it mean? | Revenue is income earned from goods and services sold to customers. |
| Ontology | How is it connected? | A customer places an order, an order generates an invoice, an invoice creates revenue. |
| Data Bindings | Where is the truth? | Revenue resolves to a finance table in SAP; customer data lives in Salesforce. |
| Rules & Policies | What is allowed? | Revenue may be recognised only once an invoice has been issued. |
| Tool Bindings | What can I do? | Query SAP revenue, generate a financial report, analyse a variance. |
| Skills & Prompts | How should I think? | Apply the reasoning an analyst uses to run root-cause analysis on a revenue variance. |
The six artifacts give an agent the same scaffolding people use every day. They define what exists, how things are connected, what information can be trusted, what actions are permitted, and how expertise should be applied. In doing so, the Cogentiq Context Layer translates a centuries-old philosophical project, the study of being, and of how we come to know it into a practical framework that enables non-human intelligence to understand and navigate enterprise reality.
Before an intelligence can reason, it must first understand the world it inhabits. Humans acquire this understanding gradually through experience, education, culture, and shared knowledge. Agents must acquire it through context. The Enterprise Context Layer is, therefore, far more than a technical construct. It is a machine-readable representation of how an organization understands itself. And as AI evolves from software agents to autonomous systems operating in the physical world, these models of reality may become as fundamental to machines as language itself is to humans.
Perhaps the ultimate challenge of AI is not creating intelligence, but teaching it what is real.
At Fractal, our conviction is straightforward: the enterprises that invest now in a governed model of their own reality will be the ones whose AI can be trusted to reason and act within it.
Context resolution
When a query reaches an agent, Cogentiq resolves the right context before any answer is attempted. The same six artifacts across 3 layers can be invoked two ways: independently, where each artifact is its own tool and the solution designer decides which to call and when, or orchestrated, where this exact sequence runs end to end as a single, pre-determined pipeline.
Independent search
In the independent model, each of the six context artifacts, Glossary, Ontology, Data Bindings, Tool Bindings, Rules & Policies, and Prompts is exposed to the agent as its own separate tool. The agent (or, more precisely, the solution designer who builds it) decides which of these tools to call, in what order, and how many times, based on the problem at hand. One solution might call only the Glossary and Data Bindings; another might loop between Ontology and Glossary several times before touching anything else. The orchestration logic lives outside Cogentiq, in the agent's own reasoning and in how the designer has wired the skill. This gives maximum flexibility; the agent uses only what it needs, when it needs it, and the resolution path can adapt to each query at the cost of putting the responsibility for sequencing, efficiency, and correctness on the solution designer.
Orchestrated search
In the orchestrated model, Cogentiq exposes the entire resolution process as a single tool that runs a fixed, predetermined sequence end-to-end. The agent simply hands over the query and receives a fully grounded context back; it does not decide which artifact to call or when. Internally, the pipeline always runs the same steps: a first glossary pass to expand the query's terms, an ontology lookup to pull the most relevant connected concepts (deduplicated and ranked), a second glossary pass to expand again using what the ontology surfaced, a prompt search over the now-enriched query, an LLM synthesis step that fuses everything into rich context, and finally a parallel resolution of data bindings and tool bindings before returning. Because the sequence is built and governed by Cogentiq rather than chosen at runtime, it is consistent, repeatable, and optimized, trading the flexibility of the independent approach for reliability and a single, predictable contract.
Where to begin: A recommended path for an enterprise
Every enterprise that begins building a Context Layer eventually reaches the same crossroads: Should we define the enterprise ontology up front, or allow it to emerge through real-world use cases? It sounds like an architectural decision. In practice, it is often the difference between momentum and paralysis. Top-Down or Bottom-Up?
In theory, a top-down approach is appealing. If the goal is to create a model of enterprise reality, why not begin by defining the entire enterprise upfront? One could imagine mapping every business function, process, concept, relationship, policy, and system before a single AI solution is ever built.
The challenge is that enterprises rarely understand themselves that completely. Ask five different departments to define a customer, a product, or even revenue, and you may get five slightly different answers. Much of an organization's ontology is not documented; it exists in conversations, habits, exceptions, and the accumulated experience of its people. Attempting to model all of it up front often becomes a large-scale modeling exercise that struggles to keep pace with a business that continues to evolve beneath it.
A more practical path is to let the ontology emerge through use. Start with a high-value business problem. As the organization works to solve it, it is forced to answer fundamental questions: What concepts matter? How are they connected? Which systems contain the truth? What policies apply? What actions are allowed? How do experts reason about this problem? The answers become context assets.
As more solutions are built, patterns begin to emerge. A customer defined for a sales use case is reused in a service use case. Revenue defined for a finance use case appears again in forecasting. Product, employee, supplier, patient, inventory, engagement, and margin gradually become shared concepts rather than solution-specific ones. What initially appeared to be a collection of isolated contexts slowly reveals itself as a coherent model of the enterprise.
Over time, solution contexts converge into organizational contexts, and organizational contexts converge into domain-level understanding. The enterprise ontology is not discovered all at once. It emerges incrementally, shaped by real business problems, validated through use, and refined through experience. Much like human understanding itself, it grows one problem, one insight, and one connection at a time.
The context maturity journey
A practical way to think about this journey is as a gradual expansion of understanding. You do not begin with an enterprise ontology. You begin with a problem.
Imagine a company building its first AI agent: a collections assistant responsible for chasing overdue invoices. To make that agent useful, the organization must define what an invoice is, what "overdue" means, what the collection process looks like, and under what circumstances a customer should not be contacted. These concepts, policies, data mappings, tools, and reasoning patterns form the Solution Context. They are narrowly scoped, highly specific, and designed to solve a single problem.
Months later, the company builds a credit-approval agent. Suddenly, many of the same concepts reappear: customer, invoice, payment history, credit standing, and approval policies. Rather than redefining them, the finance function consolidates them into shared definitions. There is now a single understanding of a customer, a single definition of a strategic account, a common source of truth for receivables, and a governed set of approval rules. What began as solution-specific knowledge evolves into the Organizational Context; the company's own understanding of how its business operates.
As additional agents emerge across sales, finance, supply chain, and customer service, a deeper pattern begins to reveal itself. Regardless of the organization, customers place orders; orders generate invoices; invoices generate revenue; and revenue contributes to profit. These concepts and relationships are not unique to any one company; they belong to the business domain itself. Over time, they become part of the Domain Context; the shared reality of the domain, independent of any particular enterprise or technology stack.
What is remarkable is that none of this was designed up front. The organization did not begin by attempting to model its entire reality. Instead, it discovered reality through repeated problem-solving. Each solution contributed a small piece of understanding. Governance identified what could be shared. Over time, isolated solution contexts converged into organizational understanding, and organizational understanding converged into a domain ontology. The enterprise ontology did not emerge from a design exercise; it emerged from experience.
The right mental model is a city. No city is built by first designing every street, building, and neighborhood in perfect detail. Cities emerge over time, shaped by the needs of the people who inhabit them. Planning and governance play an important role, but they do not create the city; they guide its evolution. Enterprise context develops in much the same way. It grows around real business problems, expands through repeated use, and is refined through governance.
The most successful Context Layers are therefore not engineered entirely up front. They are discovered through use cases, validated through experience, and curated through governance. Each solution contributes a small piece of understanding. Over time, those pieces accumulate into a coherent model of the enterprise and, eventually, the domain itself.
The practical advice is simple: resist the temptation to model everything at once. Start with a problem that genuinely matters. Build its context well. Reuse what proves valuable. Govern what becomes shared. Allow understanding to grow organically. Reality is rarely understood all at once; it is discovered through interaction with the world. Enterprise context is no different.
Build the intelligent content supply chain
Accelerate HCP engagement intelligently
