Build Your First Demand-Driven Context Base: Let AI Agents Tell You What They Need

IKEA’s Delivery and Services domain spans more than 100 engineers and six product teams, according to staff software engineer Raj Navakoti.

In Memento, a skilled protagonist repeatedly consults notebooks and tattoos to reconstruct what he was doing. Raj Navakoti describes this as a fifteen-minute memory limit and uses it to introduce a familiar agent problem: impressive capability does not supply the context needed to act. An agent may reason, calculate, and generate code well while lacking the institutional knowledge that makes its answer useful inside a particular company.

The tooling has advanced quickly: prompt engineering, retrieval-augmented generation, MCP connections, multi-agent systems, and deep agents. Raj illustrates that speed with a playful Replit example: a full-stack application in ten minutes, supposedly ready by the time the instant noodles are done. The million-dollar-app punch line captures the optimism surrounding prototypes. Enterprise delivery poses a harder question.

If agents can generate applications, review pull requests, and investigate incidents, why are Jira tickets and epics still sitting on the board? Those work items represent business delivery, not just generated output. Raj invokes McKinsey’s adoption-versus-impact gap, reporting that 88% of companies use AI but see only ‘6% of value creation’; the workshop does not establish how that value-creation figure is defined or measured. The useful question is what prevents a capable agent from completing an actual enterprise ticket.

Four sample tickets separate their requirements into three colors:

Completing a ticket requires all three. Strong performance on the green and orange requirements cannot compensate for a missing red requirement. Raj is optimistic enough about coding agents to speculate that the first AGI could be one; his concern is the knowledge surrounding their work.

The conventional architecture connects model quality, an agent and its harness, a retrieval layer, and institutional sources such as Confluence, Jira, SharePoint, and GitHub. Retrieval is supposed to carry the missing knowledge into the agent’s working context. Raj mentions a 40% factual-accuracy figure for RAG or knowledge graphs over documented knowledge, but supplies no task, baseline, or definition that makes the percentage interpretable. The architectural dependency is clearer: retrieval needs useful knowledge to retrieve.

Raj describes enterprise setups with ten to twenty MCP servers and recognizes his own earlier approach in them: connect everything, then expect the agent to finish the tickets. Yet a connection returning output does not establish that its output is reliable or useful. He describes retrieved data as nondeterministic, unreliable, and insufficiently tested, and criticizes checking whether a tool returned something instead of evaluating whether it helped solve the task.

His own attempts left him supplying missing facts repeatedly. He recalls accuracy in the ten-to-thirty-percent range, as an informal account rather than a measured evaluation. The rest felt like data entry for the agent. Trying to write the entire domain context by hand only moved the burden: instead of filling gaps during each task, he exhausted himself trying to anticipate them all.

The source collection itself is the problem. Raj’s illustrative knowledge chart describes outdated, unreliable, duplicated, and tribal information. He gives 20% outdated, 20% unreliable, corrects the duplicated category to 10%, and assigns 40% to tribal knowledge; those spoken figures do not form a complete partition. The central category is knowledge that people possess but have never written down. Even a hundred MCP servers cannot retrieve that.

The organization must turn its knowledge monolith into usable context blocks. Raj compares that work to breaking a legacy application into microservices and moving from waterfall to agile. Model providers can improve models, agent builders can improve harnesses, and retrieval vendors can improve access—he describes a multibillion-dollar retrieval market—but none of those actors can supply an organization’s unwritten facts. He introduces Demand-Driven Context, the March preprint accompanying the approach, as a method explored through dataset experiments.

Consider how a new employee learns a domain. After an initial orientation and some documentation links, the employee receives work. Nobody requires them to graduate from the entire company knowledge base first. The task makes particular gaps visible, and the employee asks colleagues for what they need. Demand-driven context applies that sequence to an agent: assign work, let it request missing information, and have it document the answers in reusable context blocks. The framework mediates between the source monolith, the agent, the human expert, and the curated knowledge.

One cycle has a concrete order:

1. Give the agent a task and access to the existing knowledge base.
2. Let it attempt the task and identify where the available context is insufficient.
3. Obtain a checklist of the facts required to proceed.
4. Have a domain expert supply those facts.
5. Use the answers to solve the task and curate reusable knowledge.
6. Repeat with another task, allowing this agent and other agents to reuse what was learned.

The durable output is more than a successful conversation: the next session starts with knowledge that the previous session lacked.

The analogy to test-driven development explains the scope of each addition. A failing test identifies missing behavior; the developer adds enough code to make it pass. Here, a failed work attempt identifies missing context; the expert supplies the necessary facts, and the agent preserves them. Repeated tasks gradually build a useful context base without demanding an exhaustive rewrite of institutional documentation upfront.

The terminal demonstration assembles this behavior from skills, rules, agents, hooks, and somewhere to store knowledge. Raj uses Copilot at work and Claude Code for the workshop; the method does not depend on either product. Separate panes show the workflow, the existing knowledge collection, and live additions. Flat files represent material that would otherwise live in Confluence, Slack, and GitHub.

The assigned task is incident root-cause analysis. Its context deliberately combines documented facts, outdated material, and information that was never recorded. The agent first searches the existing collection. That is still retrieval; demand-driven context adds what happens afterward. When the retrieved material does not answer the question, the agent must expose the missing information and continue the investigation with an expert.

Raj reports an initial confidence score near 1.5. The agent points to terminology and business logic it does not understand, turning a vague documentation problem into specific requests. This is the value of a task as a probe: asking someone to document everything in their head is unbounded, while asking for the facts needed to investigate this incident is answerable. Raj supplies a prepared, high-level answer. The live run also asks an unexpected clarification about a fictional name, which had not appeared during rehearsal.

New entities then appear in the live knowledge view. Raj clarifies that the filesystem is a demonstration choice: existing MCP or RAG connections can still access material in Confluence or Slack. He describes roughly 56 initial entities, six undocumented entities surfaced by the problem, and another five or six entities curated after his answer. These approximate counts illustrate discovery and persistence, rather than a requirement that each incident produce a fixed number of records.

Across the fourteen-incident demonstration, Raj reports confidence rising from 1.5 to 4.4 as expert answers are collected and documented. No scoring rubric or calibration is supplied, so this trajectory shows the demo’s reported confidence, not independently measured incident-resolution accuracy. The intended change in responsibility is nevertheless concrete: the agent becomes a knowledge manager as well as a consumer. After repeatedly supplying answers by hand, Raj found the interaction too laborious. Archived Jira items, incidents, and support tickets offer a way to automate the discovery work.

The batch demonstration uses a preset platform-operations scenario with twenty recent incidents. Markdown or JSON files contain the incident descriptions and comments; other files represent the knowledge base. The scanner asks how well that knowledge supports each incident: what is usable, what is questionable or outdated, and what is missing. Its pipeline generates probes, runs them against the available knowledge, and analyzes the resulting gaps. The displayed interface shows probe generation and testing complete while gap analysis is still running.

A notification service that fails to send customer SMS messages makes the mechanism concrete. The agent can understand SMS in general while knowing nothing about this company’s notification service. Searching for that service may reveal no documentation at all. Alternatively, it may find an old or incomplete Confluence page and ask whether the page is still trustworthy. A year-old page is a reason to investigate its status, not proof that its content is wrong.

The scanner then moves from individual incidents to a consolidated backlog:

1. Extract demand: identify the information required by each incident.
2. Consolidate gaps: group findings around systems, APIs, business processes, and other domain entities.
3. Classify evidence: distinguish clean, stale, incomplete, entirely missing, and tribal information.
4. Prioritize repair: assign critical, high, or medium priority and create Kanban work items.

Frequency matters. In Raj’s example, a missing notification-service description that recurs across twenty incidents should be addressed early because it blocks repeated work. Repaired knowledge is saved in the context lake, and the scanner provides a place to inspect how the knowledge base changes as the backlog is addressed.

Once agents curate information, where should it live? Raj prefers a GitHub repository. Multiple teams, domain experts, and agents may contribute to the same knowledge base, so conflicts and review become normal requirements. Pull requests and reviews provide an existing workflow for proposing changes and resolving disagreements. Curated material can subsequently be published to Confluence or Slack. Direct Confluence integration is also possible; the repository is his implementation preference, not part of the definition of demand-driven context.

A meta-model supplies the navigation structure. It describes how business processes relate to systems, how systems relate to APIs, and where business and technical terms belong. A directory structure can represent those entity types, while the records express their relationships. Instead of confronting an undifferentiated pile of files, the agent gets a map of the domain.

That map also helps with change impact. When asked to fix a system, an agent can look for the business processes that depend on it and the APIs that might need to change. Raj strongly recommends this structure, while explicitly treating it as an add-on: a task can reveal missing facts without a meta-model, but relationships make the resulting knowledge easier to navigate and reuse.

From his experience and feedback from others, Raj identifies two benefits: surfacing knowledge that was never documented, and assigning the management of that knowledge to agents. Historical work items give documentation repair a concrete basis, instead of producing an endless Miro board of speculative missing pages. Experts still supply facts, but the agent can discover requests, organize answers, and preserve them.

The approach has less to offer a small team whose documentation is already good. It is also early, and the manual cycle is best treated as an experiment rather than a sustainable way to operate. Raj’s preferred path is automation once the team understands the loop and its outputs.

Architecturally, curated context sits between the knowledge monolith and the retrieval layer. Raj compares it to a cache: keep frequently useful information close at hand, with links back to deeper sources for unusual cases. His 80/20 rule is a prioritization heuristic—the most useful portion of the documentation may serve most recurring needs—not a measured cache-hit rate. The agent should revisit the wider source collection when the curated blocks do not contain enough information.

The workshop offers three entry points: try the preset scanner, inspect the DDC framework repository and starter guide, or give an existing agent a single work item and ask it to assess the supporting knowledge. Raj invites participants to remix the approach and contribute. The hosted exercise has a speaker-funded, first-come budget; it is a workshop demonstration rather than a promise of ongoing hosted availability.

The smallest exercise needs no new retrieval infrastructure. Use the agent’s existing MCP connections, provide one Jira ticket or incident, and ask which parts of the required context are usable, doubtful, or absent. This Markdown prompt expresses the exercise for a notification-service incident:

# Work item
Investigate why the notification service is not sending customer SMS messages.

# Knowledge assessment
Inspect the connected knowledge sources for the information needed
 to investigate this incident.

For each required fact, report:
- What information the investigation needs.
- Which source, if any, supplies it.
- Whether the information is clean, potentially stale, incomplete,
  or missing from the available sources.
- Which question a domain expert must answer before you can proceed.

Return a prioritized checklist of the gaps.
Do not fill missing institutional facts with assumptions.

Inspect the missing-information findings first. They turn a general request to improve documentation into specific questions an expert can answer.

The first audience challenge asks whether the approach has worked at scale. Raj says it has not. He narrowed his experiments from enterprise scope to a domain and then to a small team’s tickets, incidents, and Confluence pages. Smaller scope made the work faster and more useful. A broader domain can require several experts because no individual knows enough to answer all the questions.

That limitation is operational, not just technical. An audience member compares relentless agent follow-ups to a denial-of-service attack on the team. Historical tickets may also omit the details the scanner needs. Raj agrees with both concerns and acknowledges that obtaining dedicated expert time from leadership is difficult. His expectation that organizations will increasingly fund context repair as people become agent managers is a prediction about future work, not evidence that the staffing problem has been solved.

Adding source code raises another problem: which source has authority when code and documentation disagree? Raj reports good experiences with code alone and prose alone, but mixed results when combining them. An agent can infer behavior from a GitHub repository that conflicts with Confluence. He proposes explicit ranking rules—prefer the code evidence, consult Confluence when that evidence is absent—but says this combined-source behavior is still being worked on.

The next question asks whether a failure should improve the agent’s skill as well as its knowledge base. Raj’s implemented skills are static; evolving them is an untried extension. His immediate priority is moving context repair before live operations. He initially repaired context while an agent was attempting a current task, but the interruptions demanded too much time and patience. He suggests that a narrowly scoped team with a strong domain expert could improve documentation substantially over a short effort; this remains an estimate, later qualified during the discussion.

An audience member asks about the latency and context cost of reading several documents from a repository. Raj reports an average consolidated domain size of around 96K tokens in his experiments. For those domains, he found putting the whole context into the window more useful than his graph-RAG experiments, and suggests additional retrieval mechanisms when the collection approaches a million tokens. He supplies no measured head-to-head evaluation. The million-token announcement he invokes was available before the workshop; Claude Code inclusion specified Opus 4.6 on Max, Team, and Enterprise plans, rather than every Claude Code configuration.

A question about the preprint then turns to domain knowledge versus strategy knowledge. Raj tentatively contrasts demand-driven context with Agentic Context Engineering, or ACE, recalling improvements derived from conversation history and operational interaction. His intended distinction is the emphasis on institutional domain knowledge, including facts that must be elicited from experts. ACE itself also includes curation and both offline and online context optimization, so it should not be reduced to conversational memory alone.

Remote documents need more than their text. Raj’s Confluence extraction includes creation and update dates and creator metadata. A date threshold can flag a page for review, but a human decides whether it is actually stale: an old document may still be important and correct. Curated records carry dates and states such as stale, active, or clean, allowing the agent to avoid material already marked stale and look for newer evidence.

Access control belongs to the implementation. Raj relies on GitHub’s read, write, and merge permissions for the repository-based version. The workshop scanner uses presets because he does not want participants uploading proprietary information. A hosted product would need its own access design; the demand-driven method does not itself guarantee that permissions from upstream sources are preserved in curated copies.

An audience member asks whether agents could discover gaps in internal tools as well as documentation. The example is a platform CLI that abstracts Kubernetes: a team with many resources should not need a separate call for each one when a bulk operation would serve the task better. Raj initially distinguishes the method from the tools used to implement it, comparing an agile approach with choices such as Scrum, Kanban, or Lean. After the question is clarified, he accepts tool and business-process gap discovery as possible extensions. Missing bulk operations and performance improvements are suggestions from the discussion, not capabilities demonstrated by the scanner.

The strongest maintenance challenge follows one fact through time: today the answer is B, tomorrow B1, and later C. If all three survive in different documents, the knowledge base must recognize their relationship and stop serving superseded answers. Raj says the scanner flags duplicates and treats a single human-updated document as the latest source of truth. The audience pushes further: finding one changed word across several large documents is a search and synchronization problem, with recurring costs.

Freshness metadata does not establish correctness. A recent document can contain a wrong fact. A context block that helped solve one ticket can therefore produce the wrong answer on the next ticket even though the system considers the gap filled. Raj acknowledges the problem and observes that a person following the same incorrect documentation could make the same mistake. That explains the shared dependency on source quality, but it does not provide an automatic way to detect the error before use. The audience’s remaining question is how often to rescan and what that maintenance will cost.

A separate periodic update process is proposed, followed by a claim that it would cost less than repeated onboarding meetings. Another participant challenges that comparison. Raj reports that none of his tested domains exceeded 100K tokens. He does not think daily scans are necessarily required and tentatively suggests that the workshop scanner’s usage could be inexpensive, but no measured cost analysis is presented. An airline-sized organization with hundreds or thousands of repositories, system documents, and third-party sources would face a different problem. The discussion settles on scope and change rate as the relevant conditions, rather than an enterprise-wide cost conclusion.

Evaluation remains a separate question from report detail. After trying the finance preset, an audience member asks how to know the recommendations are sufficient or actually improve the result. Raj explains that the underlying output is much more detailed than the interface: he reports roughly 100–150 lines of Markdown findings per ticket. Those reports can help someone inspect the reasoning, but the answer does not supply an outcome-validation method for deciding that the knowledge base is now good enough.

The final exchange revisits whether a finite collection of Jira tickets can eliminate the tribal-knowledge gap in a few weeks. Raj makes a consequential correction: the short, team-scoped effort is about discovering gaps, not guaranteeing that all of them have been filled. His proposed sequence is to run one or more initial scans, understand the state of the knowledge base, repair it before operations, and continue agent-and-skill cycles afterward. Finding the work is different from completing the repair.

An audience member then offers another source of answers: the knowledge-transfer conversations that already happen when someone joins the organization. Zoom or Teams onboarding calls, chats, and problem-solving discussions can contain the facts that never reached Confluence. Why ask experts to repeat them if transcripts already exist? Raj initially points out that not every useful exchange is recorded and that indiscriminate meeting ingestion can add a large amount of irrelevant text. The participant proposes compressing those transcripts once and making the result part of the knowledge base.

Raj accepts that option. The right source depends on where the institution’s knowledge actually lives: conversations, written documentation, or both. If onboarding and problem-solving transcripts contain the needed facts, use them and compress them into useful context. Expert questioning can then concentrate on what those sources still cannot answer.