DevRev: AI Knowledge Management May Need a Garbage Collector

Introduction

In discussions about AI adoption, attention tends to focus on model performance and how to write prompts. Of course, those are important, but when actually using AI in business operations, there is a bigger problem one step further back.

That is the problem of what to feed to the AI.

If you connect internal documents, inquiry histories, tickets, specifications, FAQs, and meeting minutes to AI, the AI will be able to reference a lot of information. However, just because there is more information available to reference does not necessarily mean that the quality of answers will improve accordingly.

For example, outdated specifications might still be around. Or a past temporary workaround might appear to be the current official procedure. Internal information might get mixed into customer-facing responses. There might be multiple articles with similar content, making it unclear which one contains the correct current information.

AI also has the Garbage In, Garbage Out problem. Garbage In, Garbage Out is the idea that if the quality of the input information is low, the quality of the output results will also be low. Even if AI becomes smarter, if the information it references is outdated, it will return plausible-sounding answers based on that outdated information.

When I thought about this problem, I was reminded of a garbage collector. In this article, I would like to examine the strengths of DevRev when viewed as an execution platform that functions like a garbage collector for AI knowledge.

What is DevRev

DevRev is a SaaS that connects support, development, and customer information, enabling AI agents and humans to work with the same business information. Through its Knowledge Base and Articles, it allows the knowledge that AI references to be treated as managed objects with owners, statuses, visibility scopes, and related information.

Target Audience

• Those who want to explain DevRev's strengths to engineers
• Those who feel challenged by managing knowledge to feed into AI
• Those interested in information management when using RAG or AI agents in business
• Those who want to understand the value of SaaS through the metaphor of garbage collectors and memory management

References

• DevRev
• Knowledge Base Management for Self-Service
• Computer by DevRev overview
• Explore DevRev's new article creation and article analytics dashboard
• Java Garbage Collection Basics
• C++ reference: Dynamic memory management

Where Does the Responsibility for Memory Management Lie

Engineers who have worked extensively with C or C++ understand the difficulty of memory management.

When you allocate memory, you need to release it when it is no longer needed. Forgetting to release it leads to memory leaks. Conversely, releasing memory that is still in use leads to illegal memory access. In other words, data has a lifetime. If you cannot handle lifetimes correctly, programs become unstable.

On the other hand, in runtime environments such as Java and C#, the garbage collector (GC) is responsible for reclaiming objects that are no longer needed. The GC detects objects that have become unreachable from the program and reclaims their memory.

Of course, just because there is a GC does not mean you can completely ignore memory. If you hold onto large objects for a long time, memory usage increases. If you keep holding references, objects that are no longer truly needed will not be collected. GC is not magic.

Nevertheless, the existence of GC has shifted some of the responsibility for memory management from application code to the runtime environment. Rather than developers handling everything manually, the runtime environment now shares responsibility for lifetime management.

And currently, something similar appears to be happening with the knowledge fed into AI.

Knowledge Fed into AI Also Has a Lifetime

Knowledge used in business also has a lifetime.

An article that was correct when it was created becomes outdated when product specifications change. An FAQ that was valid when published becomes difficult to use as the basis for current answers when pricing plans or support policies change. Past inquiry responses are valuable information, but they cannot necessarily be treated as current standard answers.

The problem here is not simply that outdated information exists.

Past information has value for auditing and investigation purposes. It may be necessary for confirming historical context. The problem is that information that should not be used for current answers continues to remain as a basis for AI responses.

In memory management, when objects that are no longer needed continue to exist, available memory decreases. Similarly, in AI knowledge management, when information that should not be used for current answers continues to remain, it introduces noise into the sources that AI references. As a result, answer quality and reliability tend to decrease.

Furthermore, handling AI knowledge is a bit more complex than memory management.

What the GC primarily looks at is reachability — that is, whether a given object can be reached from the program. However, for AI knowledge, reachability alone is not enough. Perspectives such as whether the information is still correct, whether it is appropriate to show to customers, who is responsible for it, and whether it is consistent with other information are important.

In AI adoption, this management of knowledge lifetimes becomes critical.

Viewing DevRev as an Execution Platform for AI Knowledge

Here we return to the topic of DevRev.

DevRev is a SaaS designed to handle the knowledge fed into AI not as a mere collection of text, but as information carrying business context. It manages knowledge in the form of Knowledge Base and Articles, which can be used as information sources for AI responses and searches.

What is important is that it does not merely store knowledge. For example, Articles can carry management information such as owners, statuses, visibility scopes, and related product information. This makes it easier to treat the information AI references not as mere documents, but as managed objects with lifetimes.

What to show the AI, which information to treat as the basis for current answers, which information is internal and should not be shown to customers, who bears responsibility for updating that knowledge — these are unavoidable questions when introducing AI.

If the only goal is integration with external services, there are various approaches. Using workflow automation tools or API integrations, you can pass a lot of information to AI, but being able to connect and making that information ready for AI to use reliably are separate problems. The value of DevRev lies in addressing this post-connection problem.

Treating the information AI references as managed objects with owners, statuses, visibility scopes, and related information — this makes it possible to handle knowledge on the product level rather than depending solely on individual memory or ad hoc operations. In that sense, I think DevRev is less a garbage collector for AI knowledge in itself, and more an execution platform that enables garbage-collection-like lifetime management.

DevRev Is Not a Magic GC

However, this metaphor requires some caution.

Adopting DevRev does not mean that AI will automatically judge the correctness of all knowledge. It will not automatically find outdated articles and always keep only correct information.

This is similar to how design still matters even in languages with a GC. A GC helps reclaim objects that are no longer needed. However, questions such as what kind of data structures to use, what scope to hold references in, and how much memory usage to tolerate still need to be considered by the developer.

The same applies to AI knowledge management. Which information to treat as official knowledge, who reviews the content, which range of users to make it visible to, how to retire outdated information — these judgments remain a human responsibility.

DevRev's role is not to eliminate human responsibility. It is to place the information that someone needs to be responsible for in a visible location, and to make it manageable in terms of status, ownership, and visibility scope. It is about making knowledge management — which previously relied on individual, ad hoc operations — handleable in a form that AI can reference.

Therefore, it is not appropriate to describe DevRev as a product where AI automatically selects only correct information. Rather, I feel it is more effective to describe it as a platform for managing the lifetime of information fed into AI.

Summary

In AI adoption, not only the model and prompts, but also the state of the knowledge fed into AI affects answer quality. Because DevRev allows knowledge to be treated as managed objects with owners, statuses, visibility scopes, and related information, it is well-suited for managing the lifetime of information that AI references. This is similar to how a GC shifted some of the responsibility for memory management to the runtime environment. However, DevRev is not a magic GC — it is more appropriate to think of it as a platform for placing the content that humans need to judge in an accessible location. I hope this article is helpful for those struggling with managing the information fed into AI.