Demand-Driven Context: A Methodology for Coherent Knowledge Bases Through Agent Failure

Raj Navakoti, a staff software engineer at IKEA's Delivery and Services domain (comprising 100+ engineers across six product teams), presents a methodology called demand-driven context — a framework for building enterprise AI knowledge bases by observing where agents fail rather than attempting to curate context top-down.

Navakoti opens by framing the central enterprise AI problem through the lens of the film Memento: like the protagonist who cannot retain memory beyond 15 minutes, AI agents excel at general and domain-agnostic reasoning but lack institutional or tribal knowledge. A McKinsey figure he cites illustrates the gap starkly: 88% of companies deploy AI, yet only 6% see measurable value creation. He attributes this to a tripartite knowledge taxonomy — green (general, pre-trained), orange (process-specific, teachable), and red (institutional/tribal, undocumented) — and argues that agents fail almost exclusively on the red category.

The core argument against the prevailing "push" approach is that enterprises build 10–20+ MCP servers and RAG pipelines over their Confluence, Jira, SharePoint, and GitHub sources, but the underlying knowledge base is already broken: roughly 20% outdated, 20% unreliable, 10% duplicated, and 40% tribal — never written down. Plugging more retrieval layers over a broken monolith does not fix it; it merely produces undeterministic, untested, unreliable outputs.

The demand-driven context methodology inverts this. It is a "pull" strategy modelled on how a new employee is onboarded: given real work items immediately, expected to ask questions, and gradually surface gaps through failure. The agent is given an incident or Jira ticket, attempts root-cause analysis, and then produces a checklist of what institutional knowledge is missing — confidence scores from 1–5 mark how much of the required knowledge exists. A domain expert fills the gaps, and the agent curates the new information into structured Markdown context blocks, stored in GitHub for version control, PR-reviewed, and reused by subsequent agent cycles.

Navakoti demonstrates this live using a Claude Code-based framework with skills, rules, agents, and hooks. In one cycle on a fictional incident, the agent surfaced six previously undocumented entities; across 14 sequential incidents, it improved its confidence score from 1.5 to 4.4. At scale, the approach is automated via a context gap scanner: past incidents and Jira tickets are fed in bulk, the agent generates probes (mini tests), runs them against the knowledge base, and produces a Kanban board classifying gaps by criticality (critical, high, medium) and knowledge type (tribal, stale, incomplete, missing). Navakoti estimates average per-domain context fits within approximately 96K tokens — comfortably within a 1M-token context window — meaning full-context retrieval often outperforms RAG for typical domain scopes.

Navakoti's storage recommendation is strongly GitHub-first: multi-agent, multi-team contributions benefit from native PR workflows, branch protections, and access control. A meta-model of domain relationships (business processes → systems → APIs → jargon) is recommended as an optional but high-value addition to help agents navigate the file structure. He frames the 80/20 rule as guiding the end state: curate the 20% of institutional knowledge that covers 80% of agent tasks into cache-like context blocks; leave the remaining long-tail as fallback links.

Q&A surfaces several practical concerns: the risk of scope creep at enterprise scale (his recommendation: start at team, not domain or enterprise level); potential denial-of-service burden on engineers being questioned by agents; the challenge of maintaining knowledge currency as documentation drifts; and combining code-repository and Confluence sources (currently produces source-of-truth conflicts he is still resolving). The approach is published as a preprint on arXiv under the title "demand-driven context."