This article is based on an interview with Matthew Wimberly, CTO and co-founder at Chiri.
The word “ontology” shows up constantly in AI product pitches. Few companies explain what it means in practice. Fewer still explain why it decides whether an AI system produces useful output or expensive noise.
Matthew Wimberly, Chiri’s CTO and co-founder, starts with the simplest version of the idea. “An ontology is a really fancy way of saying it’s a map, a bunch of circles with lines in between that map the relationship between entities,” he says. He offers a personal example: “An ontology of myself and my wife being married would be me and her and a line that says married. Simple.”
A company is not that simple. But the structure holds. An ontology is a map of a business’s real entities and the named relationships between them. It is not a data dictionary, and it is not a taxonomy. A dictionary defines terms. A taxonomy sorts things into categories. An ontology records what is actually connected to what, and names the connection.
Where the map comes from
Wimberly describes the process in two stages, which he calls funnels.
The first funnel is data ingest. Chiri connects to the places a company’s information already lives: Google Drive, OneDrive, SharePoint, Slack, Teams, and similar sources. That includes unstructured material, such as a Google Meet recording of someone walking through their own work on screen.
The second funnel is data enrichment. The system reads what it ingested and starts to classify it. Is this a core value the company holds? Is this the name of a workflow, such as the steps for sending a contract? The enriched data is then checked against everything else the system has already seen, and relationships get drawn between them.
This is not a one-time import. “This is a continuous feed,” Wimberly says. “We’re always pulling in information from these data sources and we’re feeding this continuously growing graph.” He describes the result as functioning like a company’s long-term memory: the relationships between people, the work that got done, the meetings held, the messages sent, the documents created. A running history of the value the company has produced.
Over that graph, Chiri layers the places people actually work: Slack, Teams, a web interface, a browser extension, a desktop app, a phone app. That layer is where a person talks to the ontology.
The reason this matters for output quality is grounding. “A lot of the time when people use new AI tools, and we’ve been guilty of this in the past, they come off as though they’re naive,” Wimberly says. “The reason that they’re naive is because they don’t live inside of your head. They don’t have the same experiences that you do.” An ontology is the mechanism that gives an AI system the context of a specific business, instead of a generic model of business in general.
Why building one is hard
Wimberly is direct about the difficulty. “First and foremost, ontologies are hard to build, just because there’s a lot of tech involved, and it’s a build-versus-buy question,” he says. Few vendors sell an ontology on its own. Most companies land in a gap: “I’m too big for Copilot, I’m too small for Palantir and Accenture. Where do I fit in the middle?”
He points to a pattern he sees across companies. Boards, founders, and executives issue a mandate to enable the organization with AI. That mandate passes down through directors and managers to individual contributors, most of whom were never trained for it. The result is a wide range of ability and effort across the company, with no shared foundation underneath any of it.
Underneath that mandate sits an older problem. Companies have been accumulating data for twenty years without a plan for it. The moment generative AI became widely usable, three years ago, that backlog turned into a liability. Wimberly puts it plainly: “These companies have been shoving data in their closet for the past 20 years, and then GPT moment happened three years ago, and everyone turns around and says, what have I been putting in my closet? Because I guess I need it.”
The 153-to-5 story
Wimberly’s own history runs directly through this problem. He describes what he saw at a previous company, before he joined Chiri, when he took over its data platform team. The company had 110 people. It also had 153 separate data sources.
“When I ended up taking over the data platform team, we had 153 data sources in a company of 110 people,” Wimberly recalls. Over roughly 14 months, he led the work to consolidate that sprawl down to five sources. “It almost killed me, but it was very worthwhile to the company,” he says.
Matthew Wimberly, Chiri CTO and co-founder
This is Wimberly’s own recollection of his professional history at a company that goes unnamed in the interview. It is not an audited case study with a published methodology. It is offered as a personal account of what the cleanup actually took, and it lines up with the pattern he describes seeing across other companies since.
What he took from it was a confirmation of a phrase most technology teams already know and few act on. “The classic phrase garbage in garbage out is very true,” he says. “If you’re not taking care of the data that you have in house, the quality that you get out in terms of output from AI will be absolutely rubbish.”
Don’t stall at the starting line
The 153-to-5 project ran 14 months, and Wimberly is careful to say that scale of effort is not the starting requirement for every company. He has watched the opposite failure mode too: companies that hear “garbage in garbage out” and freeze, treating data cleanup as a yearlong prerequisite before any AI work can begin.
“Sure, garbage in garbage out, but don’t paralyze yourself at the starting line and say that we need to work on data quality for the next year,” he says.
His suggested first move is small and specific. Find the person in the company who knows the data best, whether that is a business person or a technical one. Pair that person with someone who can query it out of a database. Then use AI to surface the heuristics: what exists, where the quality gaps sit, what is already causing problems.
“I promise, within two to three days, you could get an answer for getting your arms around the problem of what data do we have, where are the quality gaps, and what are we starting to have problems with,” Wimberly says. The full consolidation may take months. The diagnosis does not have to.
Three systems, three speeds
Wimberly frames the rest of the picture using three categories: systems of record, systems of engagement, and systems of action.
A system of record is something like Salesforce or QuickBooks. It moves the slowest of the three, and it moves slowly on purpose. “I don’t get to just go make up revenue numbers if I want better revenue numbers,” Wimberly says. Accuracy takes precedence over speed, because the system of record holds the company’s history and its financial position.
He gives a concrete example of the cost of that slowness. At a previous company, a new SaaS feature shipped three months late. The feature itself was finished. The delay came from Salesforce and NetSuite not connecting, and a custom billing integration that was not ready in time to bill for the feature. “We had to spend three months getting ready to bill for the feature before we even launched it,” he says.
A system of engagement is the opposite: mutable, fast-moving, and built for interaction. A Google Doc, a Word file, a Slack message. These can be edited or deleted with little formal audit trail beyond minor version history.
A system of action sits over both. Wimberly describes the gap it fills: “These systems are separate, and they also have quite a few different nuances with interacting with them.” He points to where value actually gets created: in the space between interfaces, when a person carries context from one tab into another, synthesizes it, and writes it down somewhere new. Chiri’s system of action is built to take roughly 10,000 actions across 2,000 apps on a person’s behalf, from drafting emails to updating records in Salesforce, QuickBooks, and Workday, without requiring someone to log into each system manually.
An infrastructure problem, not a cleanup project
The reason to build an ontology is not to finish a one-time data cleanup. Wimberly’s own 153-to-5 project shows the labor a full consolidation demands, and few companies will run that exact project. What every company can do is start building the ongoing structure that keeps new data from piling back into the same closet.
Wimberly describes the payoff in terms of what a company keeps when a person leaves. Tacit knowledge, the workflows an experienced employee holds only in their own head, usually walks out the door with them. A continuously updated ontology, paired with workflow mapping and an auditable record of actions taken across a company’s apps, is built to hold that knowledge inside the company instead.
That is the argument for treating an ontology as infrastructure. A one-time cleanup solves today’s mess. An ontology that keeps ingesting, enriching, and mapping relationships is built to keep the mess from re-forming.
This lands differently depending on where you sit
For a CTO or data platform lead: The 153-to-5 story is a warning about scope, not a template to copy exactly. Start with a two-to-three-day diagnosis pairing a data subject matter expert with someone who can query the systems, before committing to a multi-month consolidation.
For a CEO or board member issuing an AI mandate: A mandate to “enable the organization with AI” without a data foundation underneath it produces uneven results across teams. The ontology work is the foundation, not a side project that competes with the mandate.
For an operations or RevOps leader: The systems of record, engagement, and action framework explains why AI tools that only touch one system, such as a chatbot layered on a CRM, tend to underdeliver. Value sits in the gaps between systems, where a system of action is built to operate.
For a company evaluating build versus buy: Wimberly names the market gap directly: too large for a tool like Copilot, too small to justify a Palantir or Accenture engagement. That middle segment is where a dedicated ontology and system of action platform is meant to fit.
Where does your own company’s data actually live, and could two people answer that question in an afternoon?