# Demand-Driven Context: A Methodology for Coherent Knowledge Bases Through Agent Failure Raj Navakoti, IKEA | AI Engineer Europe 2026 | 1:08:15 Source: https://www.youtube.com/watch?v=_QAVExf_1uw Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/demand-driven-context-a-methodology-for-coherent-knowledge-bases-through-agent Published: 2026-05-05 Tags: context-engineering, human-in-the-loop, memory, rag ## TL;DR - Enterprise agents handle general and taught knowledge well, but often fail on undocumented institutional knowledge. - Demand-driven context gives agents real work, uses their failures to expose missing information, and records the answers as reusable context blocks. - A context gap scanner can test past incidents against a knowledge base, classify stale or missing information, and turn the gaps into documentation work. ## Summary Raj Navakoti argues that enterprise AI is limited by institutional knowledge rather than model capability. Companies often respond by adding retrieval systems, MCP servers, and knowledge graphs, but these systems retrieve information that may be stale, duplicated, unreliable, or absent. His demand-driven approach starts with real work items such as incidents or Jira tickets. An agent attempts the task, reports what it could not find, asks for the missing domain knowledge, and documents the answer in a structured repository. Repeating this cycle gradually turns failures into context blocks that agents can reuse. Navakoti demonstrates the method with incident root cause analysis, then shows how past incidents can be scanned automatically to identify missing, stale, duplicated, and tribal knowledge. He recommends starting with a small team or domain, storing the curated context in GitHub, and adding a model of relationships between business processes, systems, APIs, and terminology. He is candid that manual elicitation is painful and that freshness, cost, permissions, and conflicting sources still need attention. ## Key ideas ### Agent capability has grown faster than enterprise delivery [03:41](https://www.youtube.com/watch?v=_QAVExf_1uw&t=221s) Navakoti contrasts the rapid progress from prompt engineering to RAG, MCP, multi-agent systems, and deep agents with the slow movement of enterprise Jira epics. Agents can generate code, build applications, review pull requests, and help with incident management, yet those capabilities do not automatically produce business delivery. He cites a McKinsey figure that 88% of companies use AI while only 6% see value creation. His explanation is that models are strong at general reasoning, computation, and code generation, while company-specific knowledge remains difficult to access and trust. ### Institutional knowledge is the red part of an enterprise task [05:33](https://www.youtube.com/watch?v=_QAVExf_1uw&t=333s) Navakoti divides the knowledge needed for a ticket into three colors. Green knowledge is general information that the model already knows, such as API standards. Orange knowledge is information the company must teach, including instructions about how to perform a task in its own way. Red knowledge is institutional knowledge held by teams and individuals. An agent may handle the green and orange parts of a ticket, but it struggles when completing the work requires unwritten business rules, system history, or local terminology. A task succeeds only when all of these parts are available. ### Retrieval cannot repair a damaged knowledge monolith [10:11](https://www.youtube.com/watch?v=_QAVExf_1uw&t=611s) Enterprise knowledge is often spread across Confluence, Jira, SharePoint, GitHub, Slack, and people's memories. Navakoti describes the stored information as a monolith containing outdated, unreliable, duplicated, and tribal knowledge. Adding more RAG systems or MCP servers does not fix the underlying material. In his own experiments, only 10% to 30% of retrieved results were accurate, and he spent the rest of the time filling gaps and answering questions. He compares the required work to breaking a legacy monolith into smaller context blocks that agents can use. ### Demand-driven context pulls knowledge out through real work [11:24](https://www.youtube.com/watch?v=_QAVExf_1uw&t=684s) Instead of pushing the whole company knowledge base into an agent, Navakoti starts with a problem. He compares the process with onboarding a new employee: give an initial orientation, assign a task, and let the person ask questions while working. The agent follows the same pattern. It searches existing sources, attempts the task, lists what it could not find, receives answers from a domain expert, and writes the new information into a more useful location. The work item creates the demand that reveals which knowledge matters. ### Agent failure becomes a repeatable documentation cycle [14:48](https://www.youtube.com/watch?v=_QAVExf_1uw&t=888s) The first attempt is expected to fail. The agent reports missing documentation, unclear terminology, and absent business logic, then creates a checklist of information required to finish the task. A human fills the checklist, after which the agent completes the work and curates the new knowledge for reuse. Navakoti compares this with test-driven development: write a failed test, identify the missing code, and gradually build the product around those failures. With repeated problems, the knowledge base becomes more complete and the agent can handle more work semi-autonomously. ### Repeated incidents can measure and expose knowledge gaps [24:05](https://www.youtube.com/watch?v=_QAVExf_1uw&t=1445s) In the demo, one incident exposes six entities that were never documented. Navakoti then shows 14 incidents processed through repeated cycles. The displayed confidence level rises from roughly 1.4 or 1.5 to 4.4 as the agent receives answers and records new entities and relationships. He presents this as a change in the agent's role. The agent is no longer only consuming a knowledge base. It also discovers gaps, asks for information, and manages the resulting documentation. ### Past work items can automate the initial knowledge audit [26:27](https://www.youtube.com/watch?v=_QAVExf_1uw&t=1587s) Manual questioning becomes painful after many incidents, so Navakoti proposes scanning work items that already exist in Jira, incident archives, or customer support systems. The scanner takes incident descriptions, comments, and related knowledge sources, then generates probes, runs them, and analyzes the gaps. It can report whether information is clean, stale, incomplete, duplicated, tribal, or entirely missing. It can also group findings by systems, APIs, and priority, then create a Kanban board for documenting the missing pieces. Re-running the scan shows how the knowledge base changes. ### GitHub and a domain map provide control over shared context [33:01](https://www.youtube.com/watch?v=_QAVExf_1uw&t=1981s) Navakoti prefers GitHub for the curated repository because several agents, teams, and domain experts may contribute to the same files. Pull requests, reviews, permissions, and merge processes provide a way to handle those contributions. The repository can later publish information to Confluence or Slack. He also recommends a meta model that links business processes to systems, APIs, and business or technical terminology. This model gives agents a map for navigating the files and estimating which processes may be affected by a system or API change. ### Curated context should cover common work while preserving deeper links [39:02](https://www.youtube.com/watch?v=_QAVExf_1uw&t=2342s) Navakoti places demand-driven context between the raw institutional knowledge monolith and the retrieval layer. He describes the resulting context blocks as a cache. In his view, 20% of documentation is most useful for agents, while the rest covers corner cases. The common material should be made easy to retrieve, and the remaining material can stay available through links when an agent needs to investigate further. He recommends fixing the context before operational retrieval where possible, starting with a small team or domain rather than attempting the whole enterprise. ## Notable quotes - "Unless we break down that monolith knowledge base into some kind of a context blocks which are useful for agents, then only we can actually make it useful for them." (10:59) - "When you give a problem, it actually surfaces what is not documented." (21:19) - "In this one we are moving agent from consumer to a knowledge manager." (25:05) - "I prefer it has to go to a GitHub repository because eventually somebody will actually come up with a 20 million seed funded SaaS solution for you." (33:37) - "So, rather than giving 100% of things, you need to figure out of what is my 20% of that, that is super helpful for agent and have it like a cache database, the context block of it using it." (39:48) ## Tools & references mentioned - IKEA - Memento - GitHub - Confluence - Jira - SharePoint - Slack - GitHub Copilot - Claude Code - Replit - MCP - RAG - TDD - McKinsey - context gap scanner ## Who should watch - You are building enterprise agents that retrieve plenty of information but still need people to fill in missing answers during real work. - Your team has incident reports, Jira tickets, or support cases that could be used to test whether documentation is complete and current. - You need a practical starting point for organizing domain context and want to understand the limits around scale, maintenance, permissions, and cost. ## Related talks - [Stop Babysitting Your Agents](https://aietalks.com/talks/stop-babysitting-your-agents) (Brandon Waselnuk, Unblocked, 18:54) - [On AI and Knowledge](https://aietalks.com/talks/on-ai-and-knowledge) (Pablo Castro, Microsoft, 17:35) - [Agentic Search for Context Engineering](https://aietalks.com/talks/agentic-search-for-context-engineering) (Leonie Monigatti, Elastic, 1:03:13) - [Context Is the New Code](https://aietalks.com/talks/context-is-the-new-code) (Patrick Debois, Tessl, 27:14) - [Building Agents Is Trivial Now, Context Is the Next Frontier](https://aietalks.com/talks/building-agents-is-trivial-now-context-is-the-next-frontier) (Jeff Ng, Unblocked, 13:22)