AI in Knowledge Management: Modular Knowledge Assets (Concept)
In organizations right now, everyone is racing to build custom AI conversational assistants. We connect them to team drives, upload training manuals, and expect LLMs to "be an expert."
Behind that, these agents are choking on your data. They skip critical sections of Word documents, get confused by conflicting and implicit information, and require users to write complex, multi-paragraph prompts just to get a straight forward, formatted response.
Over the last 6 months, my role in Knowledge Management (KM) has shifted. I went from figuring out how humans record and share documentation to figuring out how my team can use AI to document, share, and communicate institutional intelligence.
Building on top of knowledge-routing frameworks and data-loading theories pioneered by other AI innovators, I've been looking at how data hits the models that my company uses internally. What I've come up with is a conceptual blueprint that addresses these cracks. It's still a working theory right now but it represents a structural shift in how we think about "AI knowledge."
Defining the Boundary
There are conversations happening in the KM space right now about how our roles will evolve with AI. Everything I am reading says the same thing: KM is more critical now than ever.
We'll continue organizing text, facilitating knowledge flows, and handling change management, but now we'll also build machine-ready knowledge. This new landscape (chatscape??) forces us to become leaders in defining knowledge scope.
Anyone managing knowledge for AI is sitting in a crucial position where they must delineate between tacit knowledge (nuanced, human intuition and empathy) vs explicit knowledge (structured facts and formats we can hand over to AI as data).
WHY: Problems
Traditional documentation is written by humans, for humans. We like narrative flow, shared assumptions, and conversational context. Humans are great at filling in the blanks.
AI models are not. They require explicit, literal connections to interpret data correctly without making things up. When we try a "half-and-half" approach of serving documentation to both human and machine users, we fail both.
On top of that, expecting casual, everyday users to type expert prompts with persona constraints, style guidelines, and strict boundaries is unrealistic. Most humans don't prompt like engineers; they have casual conversations with chat. If your data infrastructure isn't built to handle that reality, the AI tools using it will generate generic fluff that "sounds right" but contains no context or depth.
HOW: Solution (in theory)
The core idea of this architecture is modular separation of knowledge assets. Instead of shoving instructions, facts, and formatting guidelines into one giant, messy document, break your intelligence into distinct, reusable building blocks.
- The "What" (Domains): Facts and technical baselines (e.g., how your company uses Microsoft).
- The "How" (Skills): Action-oriented templates and style guides showing how information should be structured (e.g., delivering guidance on how your company uses Microsoft as an SOP vs email).
- The "Context" (Modifiers): Special guardrails that tweak the output based on who is asking (e.g., shaping the details of how your company uses Microsoft for an executive vs new hire).
This concept is designed for scalability: it can layer into different workflows, AI tools, and requirements. It's also structured on foundational concepts of how LLMs work so as the technology advances, the framework will require improvements (not entire overhauls).
By keeping these blocks separate, a conversational agent can interpret a user's short, casual chat, by grabbing the exact "ingredient" files it needs behind the scenes to assemble a good response. ("Good" being subjective: Here I mean that it requires minimal structural or accuracy editing, though it may still require nuance reviews.)
WHERE: Centralized Repository
For this to work at scale, the files cannot be trapped inside individual AI tools or scattered across teams. They must live in a centralized, shared repository, like an enterprise cloud directory or structured documentation library.
This ensures as "single source of truth." When a policy changes, the SME updates the single file in the central directory, and every conversational agent across the department or company that references that file is updated (timelines depend on tools and data syncing processes).
WHO: Roles Involved
For this to be a success, it requires support and consistency from three distinct human roles:
Subject Matter Experts (SMEs) & KM Operators: The authors who own the knowledge assets. They don't need to know how to program an AI, but they need to establish workflows to manage and maintain knowledge files (domains, skills, and modifiers). They decide what processes are stable enough to be made explicit and set strict boundaries on what AI tools cannot do with the knowledge.
Agent Creators: The teams or individuals assembling the conversational bots or agents. They need clear guidance from the SMEs regarding what information a file actually contains (and what it doesn't) so they don't misconfigure their AI tools.
End Users: The everyday employees. They shouldn't have to change their behavior at all; outside of the Human-in-the-Loop (HTIL) review, the system absorbs the burden of compliance so the user can have a natural conversation with expected results.
Caveats & Considerations: Because this relies on building separate files with rigid templates, it requires vigorous quality checking and testing by SMEs and Agent Creators. When you mix different knowledge blocks together like this, they can occasionally collide or contradict one another. Human oversight is vital to ensure the machine interprets the combined rules correctly. In addition to testing, establish clear feedback loops so all involved roles can report confusing experiences.
WHAT: The Solution in Practice
In practice, this turns your AI agent into a true conversational partner rather than an annoying, hallucinating robot.
- Imagine an overworked support group or a strained training department. Instead of an agent autonomously pushing buttons, the agent acts as a companion sitting on the employee's screen.
- When a worker chats with the agent, the system silently pulls the verified factual blocks and layout guidelines, helping the employee handle basic discovery, note structure, and standardized responses.
- The worker is completely in control. They provide the final validation, empathy, and strategic sign-off, while the infrastructure handles the heavy lifting of compliance and formatting.
My internal tools aren't equipped for autonomous actions yet, but this concept could be expanded as needed.
WHEN: Before It's Needed
This is not a solution you complete within a week. This architecture must be developed before it's actually needed. Building a clean, modular repository of knowledge blocks will take time, intentional planning, and serious design consideration. Organizations must invest in setting up data guardrails today if they want their AI infrastructure to be future-ready for whatever technologies arrive tomorrow.
This is still a conceptual framework, but by treating your knowledge as modular architecture rather than static, formatted text, you can stop chasing "the next new tool" and start building a knowledge base that will support your employees' future needs.
This is my attempt at taking an idea I'm doing at work and stripping all the proprietary information and then sharing it. What's left is something that feels like it's lacking in context and specificity.
This isn't really meant to be a "portfolio blog" but I do like that I can use this space to learn how to write to that end. I think I'll probably continue writing about this concept as it grows (at work) and see if I can explain it better for a general audience after I've done more concrete work.
The main thing missing from my concept is token considerations - if your knowledge ends up a massive library of files to parse through, I need to figure out how to get AI to ignore what it doesn't need to see for a given prompt.
I would also like to explore more deeply what I've learned from "knowledge-routing frameworks and data-loading theories pioneered by other AI innovators." There's a lot of really interesting stuff happening right now in how people are harnessing this technology. I intentionally generalized for this post because I didn't want it to be too long.