# How to Build Efficient Context for Your AI Client to handle incidents > Source: > Published: 2026-07-23 17:32:48+00:00 Most teams that adopt an AI coding or operations assistant eventually reach the same conclusion: **The model is rarely the bottleneck. The bottleneck is context.** A capable model with the wrong context produces a confident, generic answer. The same model with the right context can produce something an engineer can actually use. So the practical question is not only: Which model should we use? It is also: What should the context contain, and how should we build it? A useful context needs more than a large prompt or a folder full of documents. It needs three distinct components: Each component solves a different problem. Rules contain your team’s specific expectations about how work must be performed. Examples include: Rules operate differently from general reference material. Knowledge tells the AI what is true. Rules tell it what it is allowed and expected to do. A general-purpose model cannot automatically know your team’s boundaries, escalation paths, safety requirements, or architectural conventions. Those constraints have to be provided explicitly. Because rules change the model’s behavior—not merely the information available to it—a few well-written rules can improve an answer more than several pages of background material. This is often the highest-leverage part of a context, and it is also the part most likely to be missing. Knowledge is the standing material that explains your systems and operational practices. It commonly includes the following categories. Troubleshooting guides capture service-specific diagnostic knowledge that experienced engineers often carry in their heads: Runbooks describe the actions needed to operate a system: These documents explain information that may be obvious to your team but invisible to a general model: This knowledge is specific to your organization, and it changes over time. A runbook may be rewritten after a postmortem. A troubleshooting guide may become incorrect after a migration. An architecture document may stop reflecting the current service topology. Good context therefore treats knowledge as a **living, versioned source**, not as something permanently embedded into a model and forgotten. Rules and standing knowledge are not sufficient for many real engineering tasks. During an investigation, the AI may also need to answer questions such as: This information already lives in the tools your team uses: A good context should not attempt to copy all of this information into one giant document. Instead, it should provide the AI with a **scoped, preferably read-only way to retrieve the specific information required for the current task**. The three parts of context therefore answer three different questions: | Context component | Question it answers | |---|---| | Rules | What am I allowed and expected to do? | | Knowledge | How does this system work? | | Retrieval | What is true right now? | An assistant without retrieval reasons from stale assumptions. An assistant without rules may perform the wrong action very efficiently. An assistant without domain knowledge may produce advice that sounds reasonable but does not apply to your systems. For dependable results, you need all three—and they should be scoped to the task at hand. A single engineer can assemble a useful context without adopting a new platform. For example, you can: This approach works well. It is often the correct first step because it forces you to decide what the AI actually needs. That decision is where much of the value comes from. Anyone who has used an AI coding assistant seriously has probably already done some version of this. The problem is not that manually assembled context is wrong. The problem is that it does not scale beyond one person and one moment. Several failure modes appear as soon as context becomes a team practice. The runbook copied into a prompt last month may have since been updated. Nobody remembers to replace the old copy, so the AI continues reasoning from instructions that no longer reflect reality. This creates the same danger as outdated documentation, except the outdated material is now being used to generate confident recommendations. A carefully assembled context may exist only in one engineer’s: When the next engineer goes on call, they have to rebuild it. Two engineers may assemble slightly different versions of “the payments context.” As a result, they can ask the same question and receive different answers—not because the model changed, but because the inputs did. Pasting a log excerpt is easy once. Repeating that process for every question creates ongoing overhead. Engineers have to remember: It is also easy to paste either too little information or far more than the AI should receive. When an answer turns out to be wrong, it may be difficult to determine what the model was actually given. Was it using the current runbook? Did it see the deployment history? Which directories were available? Which rules were active? Without a record of the context, debugging an AI answer becomes guesswork. These are not primarily model problems. They are organizational problems. Ad hoc context works for one engineer working on one task. It does not hold up as a durable team practice. Over time, teams need a way to define, version, scope, and share context without migrating all of their knowledge into another heavyweight platform. This is the problem we are working on with [NeatContext](https://www.neatcontext.com/). NeatContext provides a structured way to assemble the three parts of context—rules, knowledge, and retrieval—while keeping the source material close to the teams that own it. A domain profile is a Markdown-based definition of a team’s: The relevant profile is connected for a specific task so that the AI works within the boundary defined by that team. Runbooks, troubleshooting guides, architecture notes, and other documents stay as local or version-controlled source files. They are not permanently baked into a model. When a runbook changes, the source changes. There is no retraining step and no hidden copy inside model weights that can silently become stale. Instead of copying every external system into a context document, teams can connect scoped, read-only extensions for tools such as: The context defines which extensions are available for a particular task. Credentials remain in the operating system’s credential storage rather than being placed directly into prompts. A production incident does not need access to every document, repository, and tool in the company. For each task, you can choose the relevant: This reduces background noise, unrelated information, and signal dilution. A team can define its context once and reuse it across investigations. The next engineer on call receives the same rules, knowledge, and retrieval boundaries instead of rebuilding them from memory. NeatContext’s [team library](https://docs.neatcontext.com/features/library#the-team-library-optional-read-only) also allows domain profiles, knowledge, and extensions to be shared read-only across team members. NeatContext keeps a local activity log showing what context was handed to the AI. When an answer needs to be reviewed, engineers can trace it back to its inputs instead of trying to reconstruct the context afterward. One design choice is important to clarify: **NeatContext does not contain an AI model.** It does not read your documents, rank them, or summarize them before your assistant receives them. Instead, it defines the context boundary and connects the selected profiles, folders, and read-only tools to the AI client you already use, such as: The approved AI client performs the actual reading and reasoning. The context is explicitly defined by a person rather than inferred by a second model. In other words, NeatContext turns the useful habits behind manually assembled prompts into something durable: The following demonstration shows how the same incident can require different actions from different teams when each team provides its own domain context. Efficient context is not simply a bigger prompt. It is a deliberate combination of: All three should be scoped tightly to the task. You can assemble this context manually today, and doing so is worthwhile. It helps identify which information actually changes the quality of an AI-generated answer. But if AI-assisted engineering is going to become a team practice rather than a personal trick, context needs to become: That is the problem we are working on with [NeatContext](https://www.neatcontext.com/). You can also try the [hands-on NeatContext demo on GitHub](https://github.com/XTSoftwareLabs/neatcontext-demo). How are you currently providing domain-specific context to your AI tools? I would be interested to hear what works—and where the process starts to break down.