DevRev: What AI Knowledge Management May Need Is a Garbage Collector

Introduction

When introducing DevRev, customers always ask me the same question.

"So what exactly is DevRev's strength?"

In this article, I'll use "Garbage Collection (GC)" as an analogy to explain DevRev's strengths.

When it comes to AI adoption, attention tends to focus on model performance and prompts, but in actual business operations, there's a bigger problem that comes a step before that. It's the question of what you feed to the AI. Connecting internal documents, inquiry histories, tickets, specifications, FAQs, and meeting minutes increases the information AI can reference. However, even with more information available, answer quality doesn't necessarily improve. This is because things like outdated specifications remaining, past temporary workarounds appearing to be official procedures, internal information mixing into customer-facing responses, and multiple similar articles making it unclear which one is correct can all happen.

This is the Garbage In, Garbage Out problem — that is, "if input quality is low, output quality will be low too." Even if AI becomes smarter, if the information it references is outdated, it will return plausible-sounding answers based on that outdated information.

When looking at the problem of how to organize cluttered knowledge, GC came to my mind — that mechanism in programming that automatically reclaims memory no longer used by a program, keeping the memory space healthy. In this article, I'll explore the strengths of viewing DevRev as a "GC-like execution platform 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 Knowledge Base and Articles, it allows AI to treat the knowledge it references as managed objects with owners, states, visibility scopes, and related information.

Target Audience

• Those who want to explain DevRev's strengths to engineers
• Those who feel challenged by managing knowledge fed to 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 analogy of GC or 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++ will understand the difficulty of memory management.

Once memory is allocated, it must be released 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 lifespan. If that lifespan is not handled correctly, programs become unstable.

On the other hand, in runtime environments like Java or C#, GC takes on the responsibility of reclaiming objects that are no longer needed. GC detects objects that have become unreachable from the program and reclaims their memory.

Of course, having GC doesn't mean you can completely ignore memory. Holding onto large objects for a long time increases memory usage. Keeping references means objects that are no longer truly needed won't be reclaimed. GC is not magic.

Nevertheless, the existence of GC has shifted part of the responsibility for memory management from application code to the runtime environment. Rather than developers handling everything manually, the runtime environment now takes on part of the lifecycle management.

And right now, something similar appears to be happening with the knowledge fed to AI.

Knowledge Fed to AI Also Has a Lifespan

Business knowledge also has a lifespan.

An article that was correct when 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 directly as current standard answers.

The problem here is not the mere existence of outdated information.

Past information has value for audits and investigations. It may be necessary to review past circumstances. The problem is that information which should not be used for current answers remains as a basis for AI responses.

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

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

What GC primarily looks at is reachability — that is, whether an object can be reached from the program. However, for AI knowledge, reachability alone is not enough. Whether the information is still correct, whether it can be shown to customers, who is responsible for it, and whether it contradicts other information — these perspectives are important.

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

Viewing DevRev as an Execution Platform for AI Knowledge

This brings us back to DevRev.

DevRev is a SaaS for treating knowledge fed to AI not as a mere collection of text, but as information with business context. It manages knowledge in the form of Knowledge Bases and Articles, which can be used as information sources for AI responses and search.

DevRev console Knowledge Base management screen

The important point is that it doesn't merely store knowledge. For example, Articles can carry management information such as owner, status, visibility scope, and related product information. This makes it easier to treat the information AI references not as plain documents, but as managed objects with a lifespan.

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 holds responsibility for updating that knowledge — these are unavoidable questions when adopting AI.

If it's just about integrating 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 information ready for AI to use reliably are separate problems. DevRev's value lies in this post-connection problem.

Treating the information AI references as managed objects with owners, states, visibility scopes, and related information. This allows knowledge to be handled on the product level, rather than relying solely on individual memory or ad-hoc operations. In that sense, I think DevRev is less the GC itself for AI knowledge, and more an execution platform that enables GC-like lifecycle management.

DevRev Is Not a Magic GC

However, this analogy requires some caution.

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

This is similar to how design still matters even in languages with GC. GC helps with reclaiming objects that are no longer needed. However, what data structures to use, what scope to hold references in, and how much memory usage to tolerate — these are still things developers need to think about.

The same is true for AI knowledge management. Which information to treat as official knowledge, who reviews the content, what range of users to make it visible to, how to retire outdated information — the responsibility for these judgments remains with humans.

DevRev's role is not to eliminate human responsibility. It is to place information that needs to be owned in a visible location, and to make it possible to manage status, owners, and visibility scopes. It is to enable knowledge management that previously relied on individual, ad-hoc operations to be handled in a form that AI can reference.

Therefore, it is not appropriate to describe DevRev as a product where AI automatically selects only the correct information. Rather, I feel it is easier to convey the product's strengths by describing it as a platform for managing the lifecycle of information fed to AI.

Summary

In AI adoption, not just the model and prompts, but also the state of the knowledge fed to AI affects answer quality. Because DevRev allows knowledge to be treated as managed objects with owners, states, visibility scopes, and related information, it is well-suited for lifecycle management of the information AI references. This is similar to how GC shifted part 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 content that humans need to judge in a manageable location. I hope this article is helpful to those struggling with managing the information fed to AI.