The oldest question in the age of AI
Long before AI, databases, or modern science, humans wrestled with a fundamental question: What kind of world are we living in? The Greeks named this inquiry ontology: the study of what exists and how those things are connected.
The question was never only about physical things such as trees, rivers, mountains, and people. It also concerned things that shape our lives but cannot be touched in the same way: nations, laws, corporations, contracts, marriages, and roles. What kind of existence do these things have, and how are they related?
Ontology emerged to answer that question. It sat alongside epistemology, which asks how we know something is true; logic, which examines valid reasoning; and ethics, which asks how we ought to act. Together, these disciplines formed humanity's earliest framework for making sense of reality.
At first glance, this may seem far from enterprise AI. Yet the connection is direct. As we build autonomous agents, we are learning that intelligence alone is not enough. Before an agent can reason, decide, or act, it must understand the world it operates in: what exists, what those things mean, and how they relate.
Modern enterprise ontologies and context layers continue this ancient pursuit in a bounded form. They are not trying to model all of reality. They model the reality of an enterprise, a business function, or a specific problem domain so agents can operate inside that smaller universe with confidence.
Why AI needs a model of reality
Ontology matters because intelligence requires a model of reality. Before anyone can reason, decide, or claim to know something, they must understand what exists and how things relate. A physician, merchant, scientist, teacher, CEO, or employee does not process isolated facts; each navigates the world through an internal ontology, a mental model of objects, events, causes, consequences, roles, and rules built through experience, language, and culture.
Inside an enterprise, people simply know that customers buy products, products generate orders, orders produce invoices, invoices create revenue, and revenue contributes to profit. This shared, largely unspoken understanding enables humans to navigate complexity and collaborate even when information is incomplete.
AI agents do not arrive with that enterprise model. They can process information and reason over data, but without concepts such as customer, product, invoice, margin, business unit, and the relationships among them, a moved revenue number is only a number. Enterprise context gives agents the conceptual map people use to understand why change happened and what action to take. In effect, it becomes the agent's model of reality.
The need will extend beyond software agents. As AI moves toward embodied systems, robots will also need to understand objects, purposes, relationships, and social context. The growing importance of ontology in AI is therefore more than a technical trend; it is an early attempt to teach machines to navigate digital, and eventually physical, reality the way humans do.
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 visited the store, but he usually succeeds because he is not relying on a memorized floor plan. He uses an internal model of the world: ketchup is food, food sits in grocery aisles, aisles sit inside supermarkets, and products rest on shelves. That small web of relationships is an ontology.
Now replace Jason with a robot. Without an ontology, it sees pixels, sensors, and words. It may recognize a bottle or a shelf, but unless it understands that ketchup is a condiment, condiments are food, food is stocked in aisles, and aisles exist in stores, it stalls. The limitation is not raw intelligence; it is understanding. Humans navigate with implicit ontology. Machines need an explicit one.
Figure 1: Jason’s implicit ontology: a small model of the world that turns “find the ketchup” into a navigable path.
A CFO and a decline in revenue
Now move to an enterprise. A CFO asks, 'Why did revenue decline in Europe?' A seasoned analyst does not start with random tables. They navigate a mental map of the business: revenue comes from invoices, invoices from orders, orders from customers, customers belong to regions, and customers buy product lines. Years of experience tell them where to look because they understand how the business works.
Without context, an agent sees two figures: revenue this quarter and revenue last quarter. It sees magnitude, not meaning. With an enterprise ontology, it can trace the same path a human would: revenue to customer segment, European customers, product line, and the point where sales fell away. The ontology becomes the agent's mental model of the enterprise.
Figure 2. The analyst’s enterprise ontology, the path a human traces instinctively, is made explicit so an agent can follow it.
This is how human experts work. Doctors, lawyers, analysts, and managers all navigate internal ontologies built over years. In people, the model is implicit. For agents, it must be explicit. That is the role of the enterprise context layer: not a metadata repository, but a machine-readable representation of enterprise reality.
The Cogentiq context
If ontology is a model of reality, the Cogentiq Context Layer is the mechanism that captures, organizes, governs, and exposes the reality of an enterprise to AI agents. It sits between systems of record and the agents that serve people, binding to the systems below while grounding and governing the agents above.
Figure 3. The Cogentiq Context Layer sits between systems of record and AI agents ; the enterprise’s model of reality, expressed across three nested contexts.
A living layer, not a static one
A Context Layer cannot be designed once and forgotten. Enterprises are living systems: products launch, policies change, structures evolve, systems modernize, acquisitions happen, and new business questions emerge. The reality an agent must understand today will not be identical a year from now.
For that reason, capture, organize, and govern are not sequential implementation steps; they are ongoing responsibilities. Like a city that expands and adapts with its population, enterprise context must evolve with the business. If it remains frozen, it becomes another outdated repository. Cogentiq treats context as a living asset whose value depends on both current accuracy and continuous renewal.
Figure 4. The Context Layer is a living asset; continually renewed through a Capture, Organize, and Govern lifecycle as the enterprise’s reality changes.
Cogentiq models enterprise reality across three interconnected layers of context. Each answers a different question and moves an agent from broad understanding to situation-specific action.
Three layers of reality
Reality is not a single layer. Humans routinely navigate several realities at once.
The first is physical reality: tangible objects and events such as a chair, coffee cup, keyboard, transaction, shipment, or customer interaction. It is the world of things and actions.
The second is social reality: roles and institutions that exist because people collectively recognize them. A building becomes a bank; a person becomes a CEO, doctor, customer, or employee; a document becomes a contract; a policy becomes an authority.
The third is conceptual reality: abstractions that help us reason, such as ownership, trust, disease, revenue, margin, risk, supply and demand, and education. These are not physical objects, yet they shape decisions every day.
A doctor treating a patient moves across all three layers. There is an immediate situation: symptoms, tests, and a treatment decision. There is a social reality: doctor, patient, hospital, license, and standard of care. There is a conceptual reality: disease, diagnosis, prognosis, anatomy, and physiology. The doctor's intelligence comes from navigating across these layers, not from any one layer alone.
Enterprises work similarly. When a CFO asks why revenue declined in Europe, the question begins with a specific situation: a quarter, a set of customers, products, transactions, and decisions. That is Solution Context. The answer also depends on how the enterprise works: business units, reporting structures, KPIs, governance, systems, and policies. That is Organizational Context. Beneath both lie domain concepts such as customer, invoice, revenue, margin, forecasting, and profitability. That is Domain Context.
The Cogentiq Context Layer mirrors this human pattern. Solution Context captures the immediate problem. Organizational Context captures the reality of a specific enterprise. Domain Context captures the conceptual reality of the business domain. Together, they give agents a bounded, layered understanding of the enterprise they must serve.
Figure 5. Three nested contexts mirror how humans understand the world; from the physical reality of a concrete problem, through the social reality of an enterprise, to the conceptual reality of a domain.
Domain context
The Domain Context captures the fundamental reality of a business domain, independent of any single company. In finance, the core concepts remain stable whether the organization uses SAP, Oracle, Snowflake, or spreadsheets: customers buy products, products generate orders, orders generate invoices, and invoices create revenue. Cogentiq makes this domain understanding explicit through the six artifacts: Glossary defines concepts such as customer, invoice, revenue, and EBITDA; Ontology connects them; Data Bindings locate the corresponding information; Rules and Policies capture domain constraints such as revenue recognition; Tool Bindings expose available actions; and Skills and Prompts encode expert reasoning. Together, they give the agent an understanding of how finance works.
Organizational context
The Organizational Context captures how a specific enterprise interprets and governs that domain reality. Two companies may both use the word customer, but define strategic customer differently. One may treat Salesforce as the source of truth, another may rely on a different system. Approval workflows, business-unit hierarchies, governance policies, reporting structures, and performance metrics vary by enterprise. Cogentiq captures these differences through enterprise-specific vocabulary, ontology, systems of record, governance rules, tools such as Salesforce, SAP, Workday, and ServiceNow, and the preferred operating patterns of the organization. This teaches the agent how this enterprise works, not just how the domain works in general.
Solution context
The Solution Context captures the reality of a specific problem. For example, 'Why did revenue decline in Europe?' is not only a finance question or an organizational question. It is a concrete situation involving a period, customers, products, transactions, forecasts, and business decisions. The agent needs the right concepts, datasets, systems, analytical tools, policies, confidence thresholds, and reasoning path. The Solution Context teaches the agent how to solve that problem inside that enterprise.
Seen together, the three contexts form nested layers of reality. Solution Context is closest to immediate action: the problem or decision at hand. Organizational Context represents the enterprise's social reality: structures, policies, roles, systems, and shared meaning. Domain Context represents the conceptual reality that transcends any one company. Cogentiq enables agents to move across these layers as humans do: from abstract concepts, to enterprise understanding, to specific action.
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.
Return to the finance analyst investigating a revenue decline. Before reasoning begins, the analyst must understand the language of the domain. When they hear revenue, customer, invoice, or EBITDA, they know what those terms mean. The Glossary gives the same shared vocabulary to an agent.
Definitions alone are not enough. The analyst also knows how the concepts connect: customers place orders, orders generate invoices, and invoices create revenue. The Ontology captures these relationships so the agent receives a navigable business model rather than isolated definitions.
The next question is truth. Knowing that revenue exists is different from knowing where authoritative revenue data resides. Data Bindings connect business concepts to trusted systems of record, such as SAP, Salesforce, or other enterprise platforms.
Expertise is also bounded by rules. Revenue recognition policies, approvals, compliance controls, and accounting principles define what is allowed. Rules and Policies encode these constraints so the agent operates within the same governance framework as people.
Understanding and governance still do not create outcomes. Analysts run reports, query systems, perform analyses, and generate forecasts. Tool Bindings expose those enterprise actions to the agent in a governed way.
Finally, expertise must be encoded. Two analysts with the same data and tools may reason differently because one has deeper experience. Skills and Prompts capture expert reasoning patterns for investigating anomalies, identifying root causes, evaluating alternatives, and recommending action.
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 recognized 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 agents the scaffolding people use every day: what exists, how it is connected, where truth resides, what is allowed, what actions can be taken, and how expertise should be applied. They turn philosophy into an operational framework for enterprise AI.
Before intelligence can reason, it must understand the world it inhabits. Humans acquire this through experience, education, culture, and shared knowledge. Agents acquire it through context. The Enterprise Context Layer is therefore more than a technical construct; it is a machine-readable representation of how an organization understands itself.
Perhaps the ultimate challenge of AI is not only creating intelligence, but teaching it what is real.
At Fractal, our conviction is straightforward: enterprises that invest in a governed model of their own reality will build AI that can be trusted to reason and act within it.
Context resolution
When a query reaches an agent, Cogentiq resolves the right context before an answer is attempted. The same six artifacts across three layers can be invoked in two ways: independently, where each artifact is exposed as a tool the solution designer can call as needed; or through deep resolution, where Cogentiq runs a governed end-to-end resolution pipeline.
Independent resolution
In the independent model, the six artifacts, Glossary, Ontology, Data Bindings, Tool Bindings, Rules & Policies, and Prompts, are exposed as separate tools. The agent or solution designer decides which tools to call, in what order, and how often. One solution may call only Glossary and Data Bindings; another may loop between Ontology and Glossary before calling anything else. This gives maximum flexibility and query-specific adaptation, but places responsibility for sequencing, efficiency, and correctness on the solution designer.
Deep resolution
In the deep resolution model, Cogentiq exposes context resolution as a single governed tool. The agent submits the query and receives grounded context back; it does not decide which artifact to call or when. Internally, Cogentiq runs a fixed sequence: initial glossary expansion, ontology lookup with deduplication and ranking, a second glossary expansion, prompt search over the enriched query, LLM synthesis into rich context, and parallel resolution of data and tool bindings. This trades runtime flexibility for consistency, repeatability, optimization, and a predictable contract.
Figure 7: Cogentiq resolving context
Where to begin: A recommended path for an enterprise
Every enterprise building a Context Layer faces the same question: should the ontology be defined upfront, or should it emerge through real use cases? The answer often determines whether the effort creates momentum or paralysis.
A top-down approach is attractive in theory. If the goal is to model enterprise reality, why not map every function, process, concept, relationship, policy, and system before building solutions?
The challenge is that enterprises rarely understand themselves completely. Different departments may define customer, product, or revenue differently. Much of the true ontology lives in conversations, habits, exceptions, and practitioner experience rather than documentation. Modelling everything upfront becomes a large exercise that struggles to keep pace with a changing business.
A more practical path is bottom-up: start with a high-value problem. Solving it forces the organization to answer the right questions: What concepts matter? How are they connected? Which systems contain the truth? What policies apply? What actions are allowed? How do experts reason? Those answers become context assets.
As more solutions are built, reusable patterns emerge. A customer defined for sales appears again in service. Revenue defined for finance appears in forecasting. Product, employee, supplier, patient, inventory, engagement, and margin begin to become shared concepts rather than solution-specific definitions.
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, validated through use and refined through governance.
The context maturity journey
The maturity journey is a gradual expansion of understanding. An enterprise does not begin with a complete ontology. It begins with a problem.
Consider a company building its first AI agent: a collections assistant for overdue invoices. To make the agent useful, the organization must define invoice, overdue, the collections process, when a customer should not be contacted, which data matters, which tools are available, and how collectors reason. These narrowly scoped assets form the Solution Context.
Months later, the company builds a credit-approval agent. Many concepts reappear: customer, invoice, payment history, credit standing, and approval policy. Instead of redefining them, finance consolidates them into shared definitions, sources of truth, and approval rules. Solution-specific knowledge evolves into Organizational Context: the company's shared understanding of how its business operates.
As agents spread across sales, finance, supply chain, and customer service, a deeper pattern emerges. Across organizations, customers place orders, orders generate invoices, invoices generate revenue, and revenue contributes to profit. These relationships belong to the domain itself. Over time, they become Domain Context: reusable business-domain understanding independent of a specific enterprise or technology stack.
This understanding was not designed upfront. It emerged through repeated problem-solving. Each solution contributed a small piece; governance identified what could be reused; and isolated contexts matured into organizational understanding and eventually domain ontology. The ontology emerged from experience, not from a design exercise alone.
Figure 8. The context maturity journey: context is discovered bottom-up, one use case at a time, and curated through governance, maturing from a single solution to the company’s shared organizational context and finally to a universal domain context.
The right mental model is a city. Cities are not built by designing every street, building, and neighborhood in perfect detail upfront. They evolve around the needs of the people who inhabit them. Planning and governance matter, but they guide evolution rather than create the entire city at once. Enterprise context develops the same way.
The strongest Context Layers are discovered through use cases, validated through experience, and curated through governance. Each solution contributes understanding; over time, those pieces accumulate into a coherent model of the enterprise and eventually the domain.
The practical advice is simple: resist modeling everything at once. Start with a problem that matters. Build its context well. Reuse what proves valuable. Govern what becomes shared. Let understanding grow organically, because enterprise reality, like human understanding, is discovered through interaction.
Context as Enterprise Delta
A common misconception is that agents require every concept, relationship, policy, and rule to be explicitly modeled. If true, enterprise AI would become an endless exercise in ontology engineering.
At Cogentiq, we take a different view.
Modern foundation models already understand much of the generic world. They know what customers, invoices, revenue, products, contracts, and business processes generally are, and how these concepts typically relate. Much of generic business context already exists inside the model.
What the model does not know is what makes an enterprise unique.
It does not know how your organization defines a strategic customer, which system is the source of truth, what your approval policies permit, which operational constraints matter, or how experienced practitioners reason through exceptions.
This is where the Cogentiq context layer comes in.
Rather than modeling the entire world, Cogentiq focuses explicit engineering on enterprise-specific context: governed knowledge, relationships, policies, provenance, and reasoning signals that differentiate the organization from generic world knowledge.
We call this the Enterprise Delta: the gap between what the foundation model already knows and what it must know to operate correctly within a specific business.
The objective is not to teach the agent everything. The objective is to teach it what is uniquely true about your enterprise.
In the Cogentiq architecture, context is not a complete representation of reality. It is the minimal, governed Enterprise Delta that enables agents to operate with enterprise-grade accuracy, trust, and autonomy.
Build AI that knows your business
Activate Cogentiq Context to ground agents in enterprise reality, so they reason, decide, and act with trust.
