back
Joshua Sum
Founder, Morphic
8 min read
An AI agent can retrieve the correct document and still misunderstand the business.
It may recognize that a customer approved a budget without identifying which opportunity the approval concerns.
It may retrieve an earlier stakeholder assignment after ownership has changed.
Addressing them requires an explicit representation of what the business knows, how its concepts relate, and which evidence supports its conclusions. Knowledge graphs provide that representation. Custom ontologies define its meaning. Together, they can give agents a more precise foundation for retrieval, validation, and action.
For Morphic, a revenue agent built on top of a knowledge graph, this is particularly relevant to opportunities whose context develops across months of conversations, decisions, and changing requirements.
Knowledge Graphs and Custom Ontologies
A knowledge graph represents entities as nodes and relationships as edges. In a revenue system, entities might include people, accounts, opportunities, meetings, requirements, and commitments.
An ontology defines the concepts used to describe those entities and relationships. It specifies what an Opportunity represents, how it relates to an Account, and what it means for a person to hold a buying role.
The distinction is between a definition and an assertion:
Ontology: A champion relationship connects a person to an opportunity.
Graph assertion: Maya is the champion for Acme’s expansion opportunity.
Evidence: A particular conversation or confirmed record supports that assertion.
An ontology may also define class hierarchies and logical relationships. The graph database stores and queries the representation. Selecting one does not automatically establish the meaning, accuracy, or evidential quality of its contents.
Building an ontology means making an organization’s business definitions explicit enough for software to use consistently.
The starting point is the set of questions and decisions the system must support. For a revenue agent, these might concern qualification, stakeholder coverage, unresolved requirements, or readiness to advance an opportunity.
The organization then defines the concepts necessary to answer those questions.
Modeling Decision | What the organization specifies |
|---|---|
Entity types | Opportunities, evaluations, commitments, buying roles, and other business objects |
Relationship semantics | What ownership, influence, approval, or dependency means |
Scope | Whether an assertion applies to an account, opportunity, product, or agreement |
Identity | How records from different systems map to the same entity |
Time | When an assertion became valid and when it was superseded |
Evidence | What supports an assertion and whether it is inferred or confirmed |
Validation | Which combinations of data satisfy operational requirements |
Evolution | How definitions change without erasing historical meaning |
Consider a buying role. A contact field might label someone as a champion. A more precise model can represent a BuyingRoleAssignment connecting a person, an opportunity, a role, a validity period, and supporting evidence.
This structure becomes useful when one person participates in several purchases or changes responsibilities. It preserves distinctions that a generic contact label would collapse.
The ontology also requires mappings from source systems. A CRM identifier, meeting participant, and email address may refer to the same person. Entity resolution establishes that identity; the ontology determines how the resulting entity participates in the business model.
Building an ontology is continuing engineering work. New concepts require definitions, mappings, validation, and regression tests. Graph flexibility does not eliminate schema governance.
Why companies want their own ontologies
A custom ontology makes team specific distinctions available to the agents and workflows using the shared representation.
The original text is retained alongside the enrichment, so the system clarifies ambiguity without discarding evidence.
More precise retrieval
Consistent interpretation across systems
Detectable semantic errors
Knowledge that persists across model changes
Why Revenue Agents need Context Graphs
Morphic layers on top of the CRM a team already runs rather than replacing it. Our revenue agent reads from HubSpot, Salesforce or Pipedrive, from meeting recorders, email, Slack and the team's knowledge base, and acts on that context: pre-call research, account intelligence, follow-ups, CRM updates and enforcement of the deal stages and exit criteria each team defines. Every one of those actions depends on retrieving the right context at the moment of decision. HydraDB is where that context lives.
We model each Morphic customer as a HydraDB tenant and each team member as a sub-tenant. A rep's personal memory stays scoped to that rep, while organization-wide knowledge, such as the shared CRM and knowledge base, sits at the default sub-tenant level and is visible to everyone in the account. Because HydraDB enforces access metadata during traversal rather than after it, the agent cannot surface context to a user who is not entitled to see it.
CRM records (companies, people, deals and custom objects), activity history, knowledge-base documents and tasks are all ingested as typed entities. When an integration syncs data in, we preserve its original source, so the agent knows whether a fact came from a recorded call, a HubSpot field or a Notion page, and every answer remains traceable to its evidence. Entity resolution does the rest: an account mentioned in a CRM record, a call transcript and a Slack thread becomes a single node, without manual tagging. Before every agent turn, the agent recalls graph-enriched context (entity paths and related chunks, not just matching passages), and agent conversations are written back so that memory compounds with use.
Choosing the Appropriate Graph Model - Public Benchmarks
Choosing the Appropriate Graph Model - Public Benchmarks
Revenue data has a particular shape. It is relational (contacts belong to accounts, accounts to opportunities, opportunities to competitors and objections), temporal (stages advance, champions leave, pricing is renegotiated) and permissioned (not every rep should see every account). Each retrieval paradigm captures a different part of that shape. Here's our evaluation and benchmarks and why we chose to use what we use.
Evaluation | Reported result | What the result measures |
|---|---|---|
Enterprise QA, Sequeda and colleagues | 16.7% → 54.2% | Answer accuracy using SQL versus a knowledge-graph representation |
Ontology-based query checking, Allemang and Sequeda | 54.2% → 72.55% | Accuracy after adding ontology checks and query repair |
HydraDB LongMemEval-S | 90.79% overall accuracy | The reported memory-and-answering configuration |
HydraDB BEAM 1M | 82% overall score | Long-term memory at the one-million-token tier |
HydraDB EnterpriseRAG-Bench | 88.7 overall score; 92.0% answer correctness | Retrieval and answering over a synthetic enterprise corpus |
HydraDB FinanceBench | 91.4% Recall@10 in thinking mode | Retrieval of supporting evidence within the top ten results |
Together, these results led us to a temporally versioned knowledge graph with a custom ontology for each team, running on HydraDB. We chose HydraDB because it handles all three properties in the database itself: it combines semantic, keyword and graph search to find the right context, and its open-source core can run in your own cloud. The result is an agent grounded in your business as it actually works, on infrastructure you own.