Private equity firms and investment banks regularly need something that, in the age of AI, should be simple: a report summarizing their team’s engagements across LPs, advisors, and portfolio companies. One firm had already connected a frontier model to their system of record through an MCP server. It should have taken seconds.
It didn’t. That firm stored those engagements as a data object called “interaction” – a label that meant something specific inside that firm, but nowhere else. The model had no idea “team engagement” mapped to “interaction”, or how those objects relate to one another. So it did what generic models do when they didn’t know: it guessed, produced something plausible, and waited to be corrected. It took several rounds of prompting to get to the right answer. Every round cost time, tokens, and a little more trust.
Here is the version of that story that actually keeps people up at night. A senior partner drops an AI-generated portfolio summary into an LP meeting. One asset is miscategorized, because the model reached for a generic sector definition instead of the firm’s own taxonomy. The LP asks for a follow-up. The partner can’t explain the number. And the AI never flagged any uncertainty — it just answered, confidently, the way these systems always do.
Most people read that and conclude the model wasn’t ready. I’d argue the opposite. The model was ready. The data foundation underneath it was not. This is not a model failure. It is a data architecture failure — and it is entirely preventable.
Why private capital firms and investment banks are uniquely exposed
Every firm organizes its data differently — from its peers, and from every horizontal tool on the market. “Margin above a threshold” – could refer to EBITDA margin, EBIT margin, or another metric depending on the firm’s taxonomy. “Interaction” could be a call, a due-diligence session, or a fundraising touchpoint. A generic model has no way to know which, so it picks one. In most industries, a confident wrong guess is an annoyance. In private capital, it travels — into an IC deck, an LP report, a regulatory review — and by the time someone catches it, it has already been quoted.
Mid-market firms feel this most acutely because they are the least protected. They typically run lean technology teams with no dedicated Chief AI Officer. The person wiring an AI tool into Intapp DealCloud or a data warehouse is doing it alongside five other jobs, often without deep data-architecture experience. They bought a horizontal assistant, pointed it at the CRM, and assumed it would work. When it quietly misclassifies a deal stage or flags the wrong LP relationship, there is no specialist standing there to catch it.
Mid-market firms feel this most acutely because they are the least protected. They typically run lean technology teams with no dedicated Chief AI Officer. The person wiring an AI tool into Intapp DealCloud or a data warehouse is doing it alongside five other jobs, often without deep data-architecture experience. They bought a horizontal assistant, pointed it at the CRM, and assumed it would work. When it quietly misclassifies a deal stage or flags the wrong LP relationship, there is no specialist standing there to catch it.
Enterprise firms face the same structural problem at greater scale and higher stakes. DealCloud for the deal and relationship data, a portfolio-monitoring system, a data platform like Snowflake, and a mandate from the CEO to connect all of it onto one AI platform so that fifty people can do the work that used to take a hundred. The ambition is real and achievable. But the more complex the stack, the more damage a system that guesses can do. A wrong answer about fund exposure or LP commitment status at a firm managing tens of billions doesn’t stay contained.
The fix isn’t a better prompt or a bigger model. It’s giving the AI your firm’s language before it ever sees the question. That’s what a context engine does, and it’s built as a stack — each layer adding meaning the one below it can’t provide.
The context engine, layer by layer
It’s worth being precise about the pieces, because the terms get used interchangeably and they are not the same thing. Each layer below builds on the one under it, and the AI consumes the result as a single semantic layer.
At the base are entities: the raw objects your firm tracks — deals, companies, funds, contacts. On their own they are just records in a table, with no shared meaning attached.
Glossaries sit on top — the agreed business definitions that fix what a term means, so “margin” or “commitment” resolves to one specific thing across the firm rather than whatever each user happens to assume.
An ontology is the structured map of how those concepts relate: the classes, the relationships between them, and the rules that constrain them. It goes beyond a glossary — a glossary agrees what each word means in isolation; the ontology adds that a fund holds investments, that an LP commits to a fund, that an interaction connects people at companies to a deal, and that certain combinations are not allowed. It is the blueprint.
Your firm model is that blueprint configured to your firm specifically — your taxonomies, your deal stages, your fund vintages. It is held together by data schema contracts: formal, enforced agreements about what each field means, its type, and its permitted values, so the same question cannot return two different answers depending on who filled a field in.
The knowledge graph is the ontology brought to life with your actual records. Entities become nodes, relationships become edges, and the result is a navigable network of who relates to what — this LP, across these funds, through these advisors, on these deals. It is the blueprint, populated.
The semantic layer is the whole of it — the unified, governed layer the AI actually consumes. When someone asks a plain-language question, the semantic layer resolves what they mean before the model touches anything, mapping “team engagements across LPs” onto the right objects and relationships instead of leaving the model to reverse-engineer your schema on the fly.
One more concept makes the output trustworthy: provenance — the traceable lineage of any answer, showing exactly which records, fields, and logic produced it. It is what turns an output you have to trust into one you can verify.
Put these together and you have a context engine: the intelligence layer that activates your proprietary data. Here is what changes when it is in place.
Fewer tokens, faster answers, right the first time
Token spend is becoming a real operating cost, and semantic pre-resolution is how firms stop it from spiraling. When the intent is resolved before the model runs, you stop paying for the model to grope around your schema across several rounds of clarifying prompts. That’s consistent with what analysts are seeing industry-wide: emphasizing semantic structure in AI-ready data has been linked to meaningfully higher model accuracy and lower compute costs, according to Gartner, Inc. One well-formed request replaces a back-and-forth. At firm-wide scale, that adds up to a line item a CFO will notice — which makes this a finance conversation, not just an IT one.
Latency improves for the same reason. Every round of “that’s not quite what I meant” is dead time in front of a partner who wanted the answer thirty seconds ago. Pre-resolved intent means the model does less work and returns faster – a pattern that also shows up externally, where recent research on semantic routing for large language models found a 47.1% latency reduction alongside the token savings.
Accuracy stops being probabilistic. A model reading raw fields guesses at meaning. A model reading through an ontology and schema contracts is handed the meaning — so the same question yields the same, correct, reproducible answer whether it’s asked today or next quarter.
The answer you can actually defend
If AI surfaces a recommendation, someone will eventually have to explain why. This is where provenance earns its place. An ontology-grounded output is traceable: you can point to the records and logic behind it. A prompt-engineered output is not — it’s a plausible sentence with no receipts. In an industry that lives with IC scrutiny, LP diligence, and regulators, “the AI said so” is not an answer. “Here is the lineage” is.
Governance runs deeper than auditability. Because the context engine sits between the user and the data, it’s also where permissioning is enforced. The AI should only ever reason over data the person asking is actually entitled to see — deal-team walls, LP confidentiality, information barriers between funds. Bolt an assistant directly onto a warehouse and those boundaries blur. Route it through a governed semantic layer and entitlements are applied before a single token is generated. That same architecture protects data privacy: your proprietary relationships and firm knowledge stay inside your environment, resolved locally, rather than being shipped wholesale to a model provider to figure out on its own.
From answers to a decision system
Everything so far assumes AI is answering questions. The larger shift is AI that acts — recommending the next step, drafting the IC memo, flagging the LP whose commitment is lapsing, moving a deal to the next stage. That is a decision system, not a chatbot, and it raises the stakes on everything above it. A wrong answer wastes a few minutes; a wrong action, taken automatically, propagates before anyone reviews it. A decision system is only ever as trustworthy as the model of the firm beneath it — the same ontology that grounds an answer is what lets an agent decide and act reproducibly, inside the permissions it has been granted, with every decision traceable to the reasoning behind it. The firms that treat AI as a decision system, rather than a search box, are the ones that will safely let it touch real work.
Build on a platform you own, not a model you rent
One last point, because it’s the decision that compounds. The AI landscape is moving too fast to bet your intelligence layer on a single provider. We don’t know which model will be best — or cheapest — a year from now. If you build your skills and workflows directly on one LLM, you’ve tied your firm’s institutional knowledge to that vendor’s roadmap and token pricing, and switching later means rebuilding everything.
Build the context engine on a model-agnostic platform instead, and your ontology, skills, and playbooks stay portable. You can route each task to the most cost-efficient model that does the job well, and swap providers as the frontier moves — without touching the layer that makes your firm your firm.
Because that’s the real point. The ontology is not the moat. Your method, your judgment, your institutional knowledge — that’s the moat. The ontology is what finally makes it usable by AI — and a decision system built on it doesn’t just answer with your firm’s knowledge, it acts with your firm’s judgment. Most firms connected a model to their CRM and assumed that was enough. It never was.
See what’s possible when AI speaks your firm’s language.
Explore how Intapp DealCloud’s data foundation gives AI the context it needs to act with your firm’s judgment — not just answer questions.
Take the AI readiness assessment
Ten questions, thirty seconds. Find out where your firm stands.
Talk to the team