# The ontology layer.

> Why ontology is the foundation of agentic AI: a shared model of objects, relationships and actions that lets agents work in production.

Canonical URL: https://www.boltcliq.com/ontology
Part of: https://www.boltcliq.com/llms.txt

Agents can only work in production if they understand the business. Ontology is how we teach them.
- Agents can only work in production if they understand the business. A model of the business, built once and shared, is what makes that possible.
### Philosophy: the study of being
- Ontology is the branch of philosophy that studies being. It asks what exists, what kinds of things there are, and how those things are related. The word comes from Greek roots meaning “being” and “study”. Philosophers have argued about it for more than two thousand years.
- Notice what the discipline does. It does not collect facts about particular things. It sorts reality into categories, and then asks how the categories behave. Is a person the same as the roles they play? Is a company a thing, or a set of agreements? Is a late delivery a thing, or something that happens to one? These questions sound abstract until you try to build a system that must answer them.
- Every database encodes answers to these questions, usually without saying so. A “customer” table decides what a customer is. A status column decides what states a thing can be in. The choice is made one project at a time, and the choices disagree. An enterprise ontology makes the choice once, on purpose, and writes it down.
### The categories of being, mapped to the enterprise
**Particulars and universals**
- Individual things and kinds
- A particular is one individual thing, such as this loan or this clinic. A universal is a kind that many particulars share, such as “loan” or “clinic”. In an enterprise model, particulars are instances (the loan with this identifier) and universals are object types (Loan). Keeping them apart lets you define a type once and create many instances.
**Concrete and abstract**
- What has a place and what does not
- Concrete things can be located in space and time: a truck, a field, a patient. Abstract things cannot: a policy, a credit limit, a tariff. A good model holds both. A truck is an asset with a location. A tariff is a rule that applies to it. Mixing them without care produces confusion in reports.
**Substances**
- Things that persist
- A substance is something that exists in its own right and persists through change. A customer remains the same customer when their address changes. In the enterprise these are the core object types: Customer, Account, Asset, Facility. Identity is the hard part. Deciding when two records are the same customer is most of the work.
**Properties**
- How things are
- Properties are the qualities a thing has: a balance, a weight, a risk rating, a status. They belong to something and can change. In the ontology they are typed attributes with units, allowed values and rules. A balance is not just a number. It has a currency, a time and a source.
**Relations**
- How things connect
- Relations hold between things: owns, supplies, reports to, is guarantor of. They are not afterthoughts. Most business questions are about relations, such as which clients depend on a supplier. In the ontology these are links with a direction, a meaning and sometimes their own properties.
**States of affairs**
- How things stand
- A state of affairs is a way things are arranged at a moment: this account is overdrawn, that shipment is held at customs. It is what a dashboard reports. In the ontology it is the current set of property values and links, with the history of how they got there.
**Events**
- What happens
- An event is something that occurs and changes a state of affairs: a payment received, a sensor alarm, an approval. Events have times and participants. Modelling events well gives you audit, replay and the ability to ask what changed and why. Actions in Zeus are the governed way to cause events.
### From philosophy to engineering
- Computing borrowed the word. In knowledge representation, an ontology is an explicit specification of the concepts in a domain and the relationships between them. Engineers have used the idea in many forms: data dictionaries, entity-relationship diagrams, knowledge graphs, semantic layers.
- We use the word in the plain enterprise sense. What are the things in this business? How do they relate? What can be done with them, and by whom? Customers, accounts, shipments, machines, patients and contracts are not rows. They are objects with meaning and with rules about how they behave.
- The difference between a diagram on a wall and an ontology in production is that the second one is executable. It is stored, versioned and enforced. Applications read from it. Agents act through it. Changes go through review. That is what makes it a layer and not a document.
### Why agents need it
- Agent on a raw database
- Agent on an ontology
- The agent guesses which table is the source of truth.
- Each object type has one defined source, with lineage.
- It cannot tell what a late shipment implies.
- Rules state what a delay means and what should follow.
- Permissions are all-or-nothing database credentials.
- Access follows objects, purposes and the requesting person.
- Actions are free-form API calls.
- Actions are named, governed operations with approvals.
- After the fact, nobody can say why it acted.
- Every action leaves a record of inputs, rule and approver.
### What an ontology contains
**Objects**
- The entities of the business with their properties and states. Example: a Loan with amount, tenor and status. Example: a Cooperative member with plot size and crop.
**Relationships**
- How objects connect: ownership, dependency, sequence, hierarchy. Example: a Loan belongs to an Applicant and is secured by an Asset. Example: a Delivery goes from a farm to a buyer.
**Logic**
- Rules and constraints that say how the business works. Example: a loan above a limit needs two approvals. Example: produce must be graded before a payment is released.
**Actions**
- Governed operations that people and agents can perform, with full traceability. Example: request documents. Example: release payment, with an approver and a record.
### A worked example: a late loan application (illustrative)
**Objects**
- A bank models Applicant, Application, Account, Document and Branch. An Application has a status, a submitted date and a requested amount. It is linked to one Applicant and many Documents.
- Application #A-1042 (illustrative)
**Rule**
- The bank states a rule: an application that has waited longer than its service level without a decision is “late”. The service level differs by product and branch, and the rule says which applies.
- Late if waiting beyond product service level
**Action**
- An action named “Request missing documents” is defined. It can be performed by a loan officer or by an agent acting for one. It sends a message through the customer’s preferred channel and logs the request.
- Action: Request documents
**Agent proposal**
- An agent sees the late application, checks which documents are missing, and proposes the action. The officer reviews, edits and approves. The decision, the rule and the approver are recorded.
- Human approves, record kept
### Common mistakes
- The first mistake is treating the ontology as a diagram. A picture that no system reads goes stale within a quarter. The model must be stored and used by applications, or it is documentation.
- The second is trying to model everything. Start with one decision. Model only the objects, links and actions it needs. Extend as the next use case demands.
- The third is leaving it to one team. The people who know what a “late” application means are in operations, not IT. The ontology works when process owners help define it and review changes.
- Store and enforce it, do not just draw it
- Start with one decision
- Make process owners co-authors
### In Boltcliq: Zeus
- It holds the objects, relationships, rules and actions, with versioning and review, and exposes them to analysis, workflows and agents.
- The other products refer to Zeus objects by identifier. Odin decides who may touch an object. Monolith limits what an agent may load and remember about it. Argus runs the workflows and stores the data. Cyclopes records what happened to it. Nobody keeps a private copy of “customer”.
- Read more about Zeus
- See how the five products fit
- Or start with a conversation about your first decision
### How we build the ontology layer on our stack.
- Select any layer, or press play to watch the platform come together from your data up to the agents that use it. The figure is a general pattern; each layer shows which Boltcliq product builds it.
**Data foundation**
- The systems and records a business already runs on: databases, documents, events and files. An ontology starts here, because every object it describes has to come from something real. We connect the systems you already run into one governed foundation, and leave the data where it lives. Each source is mapped to the object it feeds, with an owner and a lineage, so nothing in the model is a guess.
- Start small: Take the sources behind one decision, not the whole estate.
- Connect in place: Read from the systems of record instead of copying everything.
- Map to objects: Every field belongs to an object and has a named owner.
- Keep lineage: Record where each value came from, so it can be explained.
**Logic and action services**
- Where the logic runs and where actions are carried out: workflows, functions, integrations and the stores that hold the state of the model. Argus is where agents and workflows run and where their data lives, inside your boundary and portable by design. It runs the workflows the ontology defines and stores the ontology itself.
- Inside your boundary: Run in your cloud or on your own infrastructure.
- Hold the model: Store the ontology and its history next to the data it describes.
- Callable actions: Expose each action as a named operation other layers can call.
- Portable: Move between environments without redesigning the platform.
**Security and governance**
- The rules for who and what may see data and take actions: identity, permissions, policy and approvals. In an agent platform this layer matters as much as the model. Odin decides who may act, with one policy engine for people, services and agents. Monolith governs what an agent may know, remember and do: its context, memory and permissions.
- One identity: People, services and agents are all known to the same system.
- Access by object: Access follows objects, purposes and the person asking.
- Agent limits: What an agent may load, remember and do is set in policy, not in a prompt.
- Approvals: Sensitive actions wait for a named person to approve them.
**The ontology engine**
- A shared model of the business: its objects, the links between them, the rules that say how it works, and the actions people and agents may take. It is stored, versioned and enforced, not drawn on a wall. Zeus holds one ontology that people and agents work from. We start with one decision, model only the objects, links and actions it needs, and extend as the next use case demands. Process owners define and review changes.
- Objects: The things in the business, with properties and states.
- Links: How objects connect: owns, supplies, depends on.
- Rules: What a delay, a limit or a status means, written down once.
- Actions: Named operations with approvals, available to people and agents.
**Apps, workflows and agents**
- What people and agents actually use: applications, workflows, analytics and agents. They read from the ontology and act through its governed actions instead of reaching into raw databases. Apps and agents are built on the ontology, so they share one definition of the business. An agent proposes an action, a person approves where policy says so, and the record keeps the inputs, the rule and the approver.
- Read objects: Dashboards and apps ask for objects, not tables.
- Act through actions: Agents use named, governed actions instead of free-form calls.
- Human in the loop: A person reviews where policy requires it.
- Agree by design: Every app uses the same model, so their answers match.
**Observation across every layer**
- A record of what systems, people and agents actually did, kept across every layer so it can be explained later. It is not a layer on top of the others. It runs through all of them. Cyclopes records what happened at every layer and makes it explainable: which data, which rule, which approver and which result. It is how a decision made by an agent can be reviewed after the fact.
- Every action: Inputs, rule and approver recorded with each action.
- End to end: Trace one request from the agent down to the data and back.
- KPIs and lineage: Measures and lineage defined over the same objects.
- Audit evidence: Evidence ready for review, without reconstructing it later.
### The graph, drawn
- This is the shape of an ontology: a hub of core objects with typed entities and links. Edges carry meaning, and the model is the thing every other system reads.
- We use real sector starting points to avoid a blank page. Banking, health, agriculture, public sector and logistics each have a template you adapt rather than invent.
- Illustration: an ontology graph with a hub and typed entities.
### Who owns the ontology
- An ontology is not finished. The business changes, and the model must change with it. That needs ownership. We recommend a small group of modelers, with named owners for each object type and a review step for changes.
- Changes move through environments like code: draft, review, test, promote. Agents and applications read the promoted version. When a rule changes, you can see which workflows and agents depend on it before you ship.
### Questions
- Is an ontology the same as a knowledge graph?
- They overlap. A knowledge graph stores facts as nodes and edges. An ontology adds the definitions, rules and actions that give the graph meaning and make it usable by systems and agents.
- Is it the same as a data warehouse?
- No. A warehouse stores history for analysis. An ontology defines what things are and what can be done with them. A warehouse can be one of its sources.
- Do we need one ontology for the whole company?
- Eventually you want shared definitions for shared objects. In practice you start with one domain and one decision, and let the model grow as use cases arrive.
- How long does it take to build one?
- It depends on scope and data. A first useful slice is measured in engagement stages, not years. We scope it with you around one decision.
- Who builds it?
- Forward deployed engineers work with your process owners and data teams. The model is yours, and your people learn to maintain it.