In this article
Three teams are preparing for the retirement of the same service. Operations wants to know which installations still depend on it. Account management needs a list of customers to contact. Finance wants to estimate the revenue associated with those customers.
Imagine that each team builds an assistant. Each assistant can reach the relevant systems, retrieve documents and write queries. Yet before it can do its job, somebody has to explain how a product relates to an installation, whether a CRM account represents one legal entity or a whole group, and why a completed migration ticket does not always mean that the old service is no longer in use.
The teams put those explanations wherever their application needs them: a prompt, a query, a mapping table, some application code. Each local solution may be reasonable. The problem appears when the relationship changes. A product acquires a new dependency, a customer reorganizes its subsidiaries, or the migration workflow gains another status. There are now three interpretations to find and update.
That is a stronger reason to investigate knowledge architecture than a chatbot occasionally getting an answer wrong. The organization is paying repeatedly to reconstruct the same parts of its business, and the results are becoming dependencies in different systems.
The knowledge is already somewhere
It would be wrong to describe this company as lacking a model of itself. Its operational systems contain models. So do its APIs, reports and integration jobs. The issue is that the meanings needed for a cross-system task are distributed across them.
A billing account represents a payment arrangement. A CRM account represents a sales relationship. An installation identifies something deployed for a customer. These concepts overlap without being interchangeable. Creating a universal Customer object can make the picture look simpler while removing distinctions that the work depends on.
For the retirement project, we need to know which installation belongs to which subscription, who the contracting party is, and how that party relates to the account the sales team recognizes. Finance can retain its billing model. Operations can retain its installation model. The shared work is to make their relationships explicit enough that each application can use them without inventing a new interpretation.
That interpretation includes more than a glossary. Writing down that a subscription has a contracting party is useful, but the application also needs an identifier it can resolve, a source for the relationship and a response when two sources disagree. A definition becomes operational when software can use it and someone can correct it.
Retrieval and explicit knowledge belong together
This is sometimes presented as an argument against RAG. I do not think that distinction helps. Retrieval can use structured queries, graph relationships and document search together; Microsoft's GraphRAG is one example of a retrieval approach that builds graph-based representations from text.
For the retirement project, the useful question is what a retrieved result means. A passage stating that a customer planned to migrate is evidence of an intention. A deployment record showing that the replacement is running is evidence of a different kind. A graph extracted from the passage should not silently turn the intention into an operational status.
We can retain both. The planned migration gives an agent somewhere to investigate, while the deployment record supports a conclusion about the installed system. Explicit knowledge is valuable here because it preserves the distinction rather than forcing the model to rediscover it from the wording of every document.
The same principle applies to relationships. A source can mention two organizations together without establishing that they are the same legal entity. A proposed match may deserve attention without yet being suitable for joining their contracts. The system needs somewhere to keep the proposal, its evidence and its review state.
What should survive the application?
I would start with the knowledge that several applications need and that somebody is prepared to maintain. In this example, that might be the identity mappings between installations, subscriptions and parties, the meaning of required dependencies, and the conditions under which a migration counts as operationally complete.
Once those relationships and conditions are available through a defined interface, the three assistants can do different work with the same underlying interpretation. Operations can investigate technical exposure. Account management can prepare communications. Finance can apply its own revenue definition to the resolved subscriptions.
The applications need not return identical answers: they are answering different questions. What they should share is an inspectable account of the relationships they have in common. When a result differs, the team can identify whether the difference comes from the business question, the source version or a genuine disagreement in the model.
This is an established ambition of knowledge engineering. Ontology development has long concerned shared vocabulary, explicit assumptions and the reuse of domain knowledge between people and software. It does not require starting with a complete model of an enterprise.
The practical opportunity is to turn a repeatedly reconstructed interpretation into a maintained capability. That capability might be implemented through relational views and domain services, a graph with rules, or a combination. A database choice follows from the workload; it does not define the ambition.
Would a better model make the layer unnecessary?
A sufficiently capable model may reconstruct these relationships accurately from the available evidence. It may also suggest a better domain model than the first one the team designed. Those are capabilities worth using, rather than treating model limitations as a permanent foundation for the architecture.
But there is still a decision about what happens to the result. When an agent discovers that two customer records should not have been merged, should that correction remain in its conversation? Should the reporting service continue using the old mapping? How does another agent learn that the distinction has been checked?
A shared representation gives the discovery a destination. It also allows an agent to inspect a prior interpretation, challenge it and propose a replacement. The agent gains an environment it can investigate and improve, rather than a collection of facts it must accept unquestioningly.
This is why I find the connection between knowledge engineering and agentic systems interesting. Explicit knowledge can extend what the agent can do. A reusable dependency model lets it explore the consequences of a proposed service change. Versioned rules let it compare policies. An evidence trail helps it identify what to revisit when a source changes.
None of those capabilities requires claiming that language models will always be unable to work them out. The value is in making the organization's adopted interpretations available across executions and applications.
Where I would draw the boundary
There is a real cost to sharing knowledge. Somebody must maintain the mappings, support the interfaces and handle changes that affect more than one consumer. A central model can become a bottleneck if every team needs permission to represent something new.
I would therefore avoid creating a central approval process for all enterprise meaning. Domain teams can own their models. The shared layer should make the relationships between them explicit and provide stable interfaces for the capabilities that cross those boundaries. An exploratory interpretation can remain local until there is a reason to promote it.
For a single assistant searching a well-maintained handbook, the extra machinery may not pay for itself. For three systems independently resolving the same customer and subscription relationships, there is a concrete opportunity to test.
The first comparison should include the cost of maintaining the shared capability, not just whether it produces a better answer. Can the next application reuse the mappings? Can a corrected dependency reach all three consumers? Can an engineer explain why one customer appeared on the notice list without opening several prompts and integration jobs? Those are outcomes we can evaluate before expanding the scope.
I would begin by taking one interpretation that the company currently repeats and making it explicit, executable where useful, and owned. The first application should earn its keep on its own. The second should need less work because the organization has retained something from building the first.
Sources and scope · 18 September 2026
- Microsoft, GraphRAG documentation.
- Natalya F. Noy and Deborah L. McGuinness, Ontology Development 101.
- The service-retirement scenario is a worked example, not a client case study. The references support the discussion of retrieval and ontology development; the proposed architecture and trade-offs are the argument of this article.