Knowledge work in support: knowledge that resolves cases instead of sitting in folders

The frustrating thing about many support cases is not that the answer is missing. It exists. The guide sits in Confluence, the solution is in a ticket from eight months ago, a colleague knows the process by heart. But nobody finds any of it in time, and so the same case is solved by hand for the third time.

For people, that is annoying. For AI agents, it is disqualifying: an agent that cannot reliably find knowledge guesses. And a guessing agent is worse in support than no agent at all.

Why an FAQ is not enough for agents

The first reflex is often to pour the existing documents into a search index and put a chatbot on top. That regularly fails at the same point: documents describe facts, but they do not model them. Which error message belongs to which system, which solution path has which prerequisites, who is responsible for which service: all of that sits between the lines.

nara Memory therefore goes one step further and models knowledge as schemas, objects, and relations in a knowledge graph. Symptoms, systems, and solution paths are linked rather than merely tagged. Documents and tickets are imported continuously, and agents and people access the same knowledge layer.

Answers with evidence

The most visible difference in daily work: agents answer cases from Memory and the knowledge graph and point to the source instead of guessing. Whoever reads the answer can check what it is based on. And when the knowledge is insufficient, not knowing is a result: the agent routes the case to the right expert and documents the answer so that it exists next time.

Finding gaps: checking the knowledge base against real demand

Most knowledge bases have grown historically. What got written was whatever came up, or whatever someone felt responsible for, not what is needed most often. Whether the knowledge base matches actual demand can be measured: by comparing ticket history with existing articles.

An anonymized analysis for a European manufacturing group, based on 43,676 ServiceNow incidents, shows what that can look like. The existing knowledge base contained 85 articles. Comparing it with the real ticket volume made visible which frequent cases had no guides at all. For the largest gaps, nara generated 20 article drafts, which the team then reviewed and approved. The result was not prettier documentation but a prioritized list: which knowledge is missing, and what should be written first.

Agents may draft, only people approve

The step from a resolved case to a knowledge article is diligent routine work, which is exactly why it so often does not happen. Agents can take it over: resolved cases and ticket history become article drafts, fully structured and linked to the underlying cases.

That does not make new knowledge valid yet. Every draft goes to the team for review and approval. Without this step, an unreviewed individual case would become a general rule, and the knowledge base would quickly be worth less than before. Approving knowledge remains human work, just as approvals, payments, and personnel decisions generally stay with people.

Knowledge is infrastructure, not a filing cabinet

Anyone who wants to automate support builds the knowledge layer first. It determines whether an agent answers with evidence or merely sounds plausible, and it determines what can be automated at all. What holds up in your environment is validated per stack, not promised across the board.

The most sober starting point is a look at your own data: which cases occur most often, and which of them does your knowledge base cover today? That is exactly the comparison we run in a ticket analysis. It shows the largest gaps and the order in which writing pays off. The ticket analysis page describes the approach in more detail.