What is a company ontology? One model of the business for mid-market companies

A company ontology is one model of how a business works. It defines the things the company deals with, such as customers, contracts, jobs, orders, products and people, sets out how they relate to each other, and captures the rules, judgment calls and actions around them. It connects the systems the company already runs and records which one holds the truth for each fact. People, AI agents and apps then work from that one model, which is what lets leaders trust the numbers and act on them.

Palantir made the idea famous. Its software for governments and large enterprises is built around an ontology, and its engineers build one inside each customer before building anything else. The idea works for the middle market too. What has to change is the delivery. This guide covers what goes into a company ontology, why it does more than another dashboard or a data warehouse, how agents and apps sit on it, and how a mid-market company in field services, manufacturing, distribution or SaaS can build one.

An ontology knows what each number belongs to, which version is true and what should happen next.

What is a company ontology, in plain terms?

Every company already has an ontology. It lives in people’s heads. The finance lead knows that the customer called “ABC Mechanical” in the CRM is “ABC Mech Svcs LLC” in the accounting system. The operations manager knows that one region logs travel time as billable and another does not. The controller keeps a spreadsheet that explains why three contracts are invoiced off a different rate card. None of this is written anywhere a machine can read, and when one of those people leaves, a piece of the business’s understanding of itself goes with them.

A company ontology writes that understanding down in a structured form. It has five parts.

Entities. The things the business deals with. A field services company has customers, sites, contracts, jobs, crews and invoices. A manufacturer has products, bills of materials, plants, production orders and suppliers. A distributor has SKUs, warehouses, purchase orders and routes. A SaaS company has accounts, subscriptions, usage and support tickets.

Relationships. How those things connect. A job belongs to a site, which belongs to a customer, which is governed by a contract, which sets the price on the invoice. Once those links are explicit, software can follow them without guessing.

Rules. The logic the business runs on. Which rate applies to overtime. What counts as a late delivery. When a discount needs approval. These rules often exist only as habits, or in one spreadsheet that one person maintains.

Judgment calls. The decisions experienced people make that are not quite rules. Which customers are worth chasing on a disputed invoice. Which supplier to trust when two lead times conflict. An ontology cannot replace that judgment, but it can record the inputs to it and the outcomes, so the reasoning becomes visible and repeatable.

Actions. What happens as a result. Raise a credit note, reassign a crew, reorder stock, flag an account for review. When actions are part of the model, AI can propose them inside the workflow and write them back to the system that carries them out.

The word “ontology” comes from philosophy and has an academic ring to it. In practice it means a shared, precise answer to the question “what are the things in this business, and how do they fit together?”

Why does an ontology beat another dashboard or a data warehouse?

Most mid-market companies have tried a version of this already. Usually it took the form of a business intelligence project: pull data from the main systems into a warehouse, then build dashboards on top. That work is useful. It still leaves three gaps.

The first gap is meaning. A warehouse stores tables. It can hold the customer list from the CRM next to the one from accounting, but it cannot tell you which rows are the same customer, which contract applies to which invoice, or why the totals disagree. Someone has to work that out each time, and the answer usually lives in a spreadsheet next to the dashboard.

The second is action. A dashboard shows that margin slipped in the northeast region last month. It does not say which jobs caused it, what the contract allowed, or what to do about it, and it cannot do anything itself. The analysis and the follow-up still happen by hand, in email.

The third is timing. Dashboards tend to be built for the monthly review, so problems surface after the month closes. By then a billing error has become a customer dispute.

An ontology addresses all three because it holds the meaning, the rules and the actions alongside the data. It does not replace the warehouse. A good warehouse is often the best source to build from, and many of our clients keep theirs. The ontology is the layer on top that turns stored data into a model of how the business operates.

There is a second comparison worth making, because most AI tools take a different route. They skip structure altogether and search across documents and systems each time someone asks a question. That finds text that looks relevant. It does not know that this figure belongs to this job, that this contract was amended in March, or that four of the five files marked FINAL are out of date. A model reasoning over an ontology fetches the specific facts a question needs and can cite each one, which makes answers faster, cheaper to produce and far easier to check. We go into the retrieval argument in connectors or foundations and the versioning problem in why AI needs a system of record.

How do agents and apps sit on the ontology?

Once the ontology exists, everything built on it reads from the same model. That changes what AI can do inside a business.

An agent working on the ontology can start from a customer and know, without guessing, which contracts govern it, which jobs were done last month, what was invoiced and what the contract said should have been invoiced. It can compare those, flag the difference, show the evidence and route the case to the person who decides whether to re-bill. Because the rules are in the model, the agent applies the company’s own logic rather than a generic one. Because the actions are in the model, it can draft the credit note or the corrected invoice for a person to approve. For the mechanics of the agent itself, the loop, the API and MCP connections and a worked weekly operations review, see how AI agents actually work inside a mid-market company.

Custom apps work the same way. A crew productivity view, a contract review screen or a weekly operations summary are all different windows onto one model. Finance and operations see the same numbers because they come from the same definitions. When a definition changes, say the company decides travel time is billable everywhere, it changes once and every app and agent picks it up.

Directing several of these agents from one place, with a person approving what they write back, is what we mean by AI orchestration, and that post walks through a weekly operations review built this way.

This is also why each new workflow costs less than the one before. The first build has to connect the systems and define the core entities. The second reuses most of that work. By the fourth or fifth, the team is mostly building the workflow itself.

Some examples of what this looks like across industries:

Industry	Entities in the model	A workflow on top	The decision it serves
Field services	Customers, sites, contracts, jobs, crews, invoices	Contract review that compares agreed pricing with actual billing	Which accounts to re-bill or renegotiate
Manufacturing	Products, bills of materials, plants, orders, suppliers	Margin by product line using actual material and labor costs	Which products to reprice or discontinue
Distribution	SKUs, warehouses, purchase orders, routes, customers	Stock and lead time alerts across warehouses	What to reorder, and from whom
SaaS	Accounts, subscriptions, usage, tickets, renewals	Renewal risk scoring from usage and support history	Which accounts need attention before renewal

The table is illustrative. Each company’s model is its own. The pattern holds: entities and rules underneath, a workflow on top, and a named decision at the end.

How does the ontology tie to forward-deployed engineering?

An ontology is only as good as the understanding behind it. That understanding comes from the people who run the business. Somebody has to sit with finance while they close the month, ask the operations manager why one region’s numbers look different, and turn the answers into definitions that hold up. That is the work of forward-deployed engineering: engineers embedded with the company’s team until what they build runs in production.

The two go together for a practical reason. Defining the ontology in a workshop and handing it to an implementation team rarely works, because the edge cases only appear once real data flows through a real workflow. An embedded engineer finds that the same customer has three names, or that a contract amendment explains a billing exception, while building the first workflow. The fix goes into the ontology on the spot, and every later workflow benefits.

At DealSage this follows four steps.

1. Connect. Plug into the systems the company already runs: ERP, accounting, CRM, operations, HR and documents.
2. Centralize. Bring them into one model of the business, the company ontology, with each fact traced to its source.
3. Implement. Build the agents, apps and AI workflows on top, with our engineers embedded until people use them.
4. Decide. Leaders make better, faster decisions, and can act on them inside the same tools.

The ontology is step two, but it is shaped by all four. The decision picked at the start determines which entities and rules the model needs first. You can see how the layers fit together on the platform page.

How did Palantir popularize the ontology, and what changes for the middle market?

Palantir put the ontology at the center of its commercial software. Foundry connects an organization’s systems and builds the model; AIP puts AI to work on top of it, so agents act on real business objects. Palantir describes the ontology as bringing together the data, logic and actions behind a decision, which is close to the five parts described above. Its forward-deployed engineers build the ontology inside each customer and then build the applications that run on it.

The approach works. It is also priced for governments and the Fortune 100. Palantir’s UK government price list charges £150,000 per engineer per quarter and £3 million a year for an organization-wide Foundry license. Our guide to Palantir alternatives for mid-market companies sets out the full costs and the other options.

For a company with tens or hundreds of millions in revenue, three things change.

The scale is smaller, which helps. A mid-market company might run a handful of core systems where a large enterprise runs hundreds. The ontology can be built faster and kept simpler, and the people who understand each part of the business are often in the same building.

There is rarely a data team to build it. A large enterprise that buys a platform usually has data engineers who can do the modeling. Most mid-market companies do not. Their IT team is already busy keeping the existing systems running. So the engineers who build the ontology have to come with it, and they have to stay through production.

The return has to show up sooner. A mid-market company cannot spend a year on a foundation before seeing a result. The ontology has to be built in the order the decisions need it, starting with one workflow worth enough to pay for itself, and extended from there.

DealSage was built for this. Our co-founder and CTO, Ben Amor, spent nearly ten years at Palantir, and the team includes alumni of J.P. Morgan. We apply the same model at a scale and price that fits the middle market. We are not affiliated with Palantir. Nothing here implies that Palantir endorses our work.

What does building a company ontology look like in practice?

With one PE-backed field services company, the work started by connecting the data warehouse, finance, billing, HR and every customer contract. The team sized the opportunity by area of the business and built in the order the numbers suggested.

A contract review app compared customer agreements with actual billing and flagged accounts where pricing had drifted from the contract. A crew productivity view gave operations managers and finance a shared set of numbers. Finance reporting ran from the model, and an agent wrote the weekly operations review before the Monday leadership meeting. All four drew on the same ontology of customers, contracts, jobs, crews and invoices, which is why the later builds came faster than the first.

A PE-backed multi-region services business followed a similar path. Its operating, billing and accounting systems were reconciled into one ontology, with demand, margin and risk models on top. Problems that used to appear in the monthly review now surface as alerts while there is still time to act, and the business reports 30% fewer quality and billing incidents.

The order matters in both cases. Neither company started by modeling everything. Each started with a decision that cost money when it went wrong and built the part of the ontology that decision needed.

Do you need to fix your data before you roll out AI?

This is the question we hear most from operators and investors. Everyone knows their data is messy: old spreadsheets, systems that disagree, definitions that vary by team. The instinct is to clean it all first and start on AI afterwards. That plan tends to stall. A company-wide cleanup has no deadline a business cares about, it is expensive, and nothing useful ships while it runs.

The better order is to start from a decision. Pick one the business makes every week, such as which jobs to staff, which customers are at risk or where margin is leaking. Connect the systems that decision depends on, as they are today. Clean the fields that decision needs, define them once and write the definitions into the ontology. Then build the app or agent that supports the decision.

The data work and the first AI use case become one project, with a result inside weeks. The second use case reuses the entities, definitions and connections the first one built, so it starts with less cleanup to do. Over time the ontology becomes the clean, shared model of the business that the cleanup project was meant to produce, built in the order the business actually needed it.

What should go into the ontology first?

Start with a recurring decision that has a measurable consequence and an owner. Recovering missed revenue, cutting the time it takes to close the books, or finding work that was done but never billed are all good candidates, because the business can describe the problem and put a figure on fixing it.

Then work backwards. Which entities does that decision touch? Which systems hold them? Where do those systems disagree, and who knows why? That list is the first version of the ontology. It might be five or six entities and a dozen rules, which is enough to put one workflow into production and test whether people trust it.

From there, each new workflow adds what it needs. A company two years into this has a model of its business it did not have at the start, and one its competitors do not have at all. The AI models it runs are rented and roughly the same for everyone, an argument we make in the AI model doesn’t matter. The ontology is what makes the AI specific to the business, so it should be owned by the business. If it lives inside a vendor’s product, the company is renting back its own knowledge.

How does this work for investment firms and their portfolio companies?

Investment firms need an ontology at two levels.

The first is the firm’s own. A private equity firm, a venture fund or an investment bank has its own entities: deals, companies, funds, people, documents, and the relationships between them. Its knowledge sits in data rooms, models, inboxes and the memory of senior partners. An ontology turns that into one record the firm can query. One lower-middle-market PE firm turned five years of scattered deals into one queryable foundation, so a question like “have we seen this before?” gets an answer cited to source instead of a half-day of searching folders. Our guide to AI for investment firms covers the firm side in more depth, including diligence through to the investment memo and notetaker compliance.

The second level is the portfolio. Each portfolio company runs its own systems and reports in its own format, so the firm rebuilds the picture every month from spreadsheets and board packs. When each company has its own ontology, its operating data arrives at the firm already defined and traceable. One mid-market PE firm got back about 40 hours a month by reconciling portfolio P&Ls automatically, and a SaaS growth fund now gets one clean record per company whatever format founders send. AI portfolio monitoring covers that side.

This is also why PE firms are a common route in for us. A sponsor that sees the ontology work at one portfolio company can carry the integrations and definitions to the next, and each deployment starts further along than the last.

How DealSage builds company ontologies

DealSage connects the systems a mid-market company already runs, brings them into one model of the business on our platform, and builds the agents and apps that run on it, with forward-deployed engineers embedded until the work runs in production. The company owns the ontology and the data, which is what lets it swap AI models as they change (what to own and what to rent). We start with one decision and build what it needs.

If your team spends more time assembling numbers than acting on them, talk to us about the decision that matters most and what getting it right would be worth.