{"slug": "how-to-build-efficient-context-for-your-ai-client-to-handle-incidents", "title": "How to Build Efficient Context for Your AI Client to handle incidents", "summary": "A developer explains that the bottleneck in AI coding or operations assistants is not the model but the context, which requires three components: rules, knowledge, and retrieval. Rules define behavioral constraints, knowledge provides system-specific documentation, and retrieval offers real-time data from tools like PagerDuty or Datadog. The post warns that manually assembled context does not scale beyond a single person and moment.", "body_md": "Most teams that adopt an AI coding or operations assistant eventually reach the same conclusion:\n\n**The model is rarely the bottleneck. The bottleneck is context.**\n\nA 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.\n\nSo the practical question is not only:\n\nWhich model should we use?\n\nIt is also:\n\nWhat should the context contain, and how should we build it?\n\nA useful context needs more than a large prompt or a folder full of documents. It needs three distinct components:\n\nEach component solves a different problem.\n\nRules contain your team’s specific expectations about how work must be performed.\n\nExamples include:\n\nRules operate differently from general reference material.\n\nKnowledge tells the AI what is true. Rules tell it what it is allowed and expected to do.\n\nA general-purpose model cannot automatically know your team’s boundaries, escalation paths, safety requirements, or architectural conventions. Those constraints have to be provided explicitly.\n\nBecause 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.\n\nThis is often the highest-leverage part of a context, and it is also the part most likely to be missing.\n\nKnowledge is the standing material that explains your systems and operational practices.\n\nIt commonly includes the following categories.\n\nTroubleshooting guides capture service-specific diagnostic knowledge that experienced engineers often carry in their heads:\n\nRunbooks describe the actions needed to operate a system:\n\nThese documents explain information that may be obvious to your team but invisible to a general model:\n\nThis knowledge is specific to your organization, and it changes over time.\n\nA 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.\n\nGood context therefore treats knowledge as a **living, versioned source**, not as something permanently embedded into a model and forgotten.\n\nRules and standing knowledge are not sufficient for many real engineering tasks.\n\nDuring an investigation, the AI may also need to answer questions such as:\n\nThis information already lives in the tools your team uses:\n\nA good context should not attempt to copy all of this information into one giant document.\n\nInstead, it should provide the AI with a **scoped, preferably read-only way to retrieve the specific information required for the current task**.\n\nThe three parts of context therefore answer three different questions:\n\n| Context component | Question it answers |\n|---|---|\n| Rules | What am I allowed and expected to do? |\n| Knowledge | How does this system work? |\n| Retrieval | What is true right now? |\n\nAn assistant without retrieval reasons from stale assumptions.\n\nAn assistant without rules may perform the wrong action very efficiently.\n\nAn assistant without domain knowledge may produce advice that sounds reasonable but does not apply to your systems.\n\nFor dependable results, you need all three—and they should be scoped to the task at hand.\n\nA single engineer can assemble a useful context without adopting a new platform.\n\nFor example, you can:\n\nThis approach works well.\n\nIt 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.\n\nAnyone who has used an AI coding assistant seriously has probably already done some version of this.\n\nThe problem is not that manually assembled context is wrong.\n\nThe problem is that it does not scale beyond one person and one moment.\n\nSeveral failure modes appear as soon as context becomes a team practice.\n\nThe runbook copied into a prompt last month may have since been updated.\n\nNobody remembers to replace the old copy, so the AI continues reasoning from instructions that no longer reflect reality.\n\nThis creates the same danger as outdated documentation, except the outdated material is now being used to generate confident recommendations.\n\nA carefully assembled context may exist only in one engineer’s:\n\nWhen the next engineer goes on call, they have to rebuild it.\n\nTwo engineers may assemble slightly different versions of “the payments context.”\n\nAs a result, they can ask the same question and receive different answers—not because the model changed, but because the inputs did.\n\nPasting a log excerpt is easy once.\n\nRepeating that process for every question creates ongoing overhead. Engineers have to remember:\n\nIt is also easy to paste either too little information or far more than the AI should receive.\n\nWhen an answer turns out to be wrong, it may be difficult to determine what the model was actually given.\n\nWas it using the current runbook?\n\nDid it see the deployment history?\n\nWhich directories were available?\n\nWhich rules were active?\n\nWithout a record of the context, debugging an AI answer becomes guesswork.\n\nThese are not primarily model problems. They are organizational problems.\n\nAd hoc context works for one engineer working on one task. It does not hold up as a durable team practice.\n\nOver time, teams need a way to define, version, scope, and share context without migrating all of their knowledge into another heavyweight platform.\n\nThis is the problem we are working on with [NeatContext](https://www.neatcontext.com/).\n\nNeatContext 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.\n\nA domain profile is a Markdown-based definition of a team’s:\n\nThe relevant profile is connected for a specific task so that the AI works within the boundary defined by that team.\n\nRunbooks, troubleshooting guides, architecture notes, and other documents stay as local or version-controlled source files.\n\nThey are not permanently baked into a model.\n\nWhen a runbook changes, the source changes. There is no retraining step and no hidden copy inside model weights that can silently become stale.\n\nInstead of copying every external system into a context document, teams can connect scoped, read-only extensions for tools such as:\n\nThe context defines which extensions are available for a particular task.\n\nCredentials remain in the operating system’s credential storage rather than being placed directly into prompts.\n\nA production incident does not need access to every document, repository, and tool in the company.\n\nFor each task, you can choose the relevant:\n\nThis reduces background noise, unrelated information, and signal dilution.\n\nA team can define its context once and reuse it across investigations.\n\nThe next engineer on call receives the same rules, knowledge, and retrieval boundaries instead of rebuilding them from memory.\n\nNeatContext’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.\n\nNeatContext keeps a local activity log showing what context was handed to the AI.\n\nWhen an answer needs to be reviewed, engineers can trace it back to its inputs instead of trying to reconstruct the context afterward.\n\nOne design choice is important to clarify:\n\n**NeatContext does not contain an AI model.**\n\nIt does not read your documents, rank them, or summarize them before your assistant receives them.\n\nInstead, it defines the context boundary and connects the selected profiles, folders, and read-only tools to the AI client you already use, such as:\n\nThe approved AI client performs the actual reading and reasoning.\n\nThe context is explicitly defined by a person rather than inferred by a second model.\n\nIn other words, NeatContext turns the useful habits behind manually assembled prompts into something durable:\n\nThe following demonstration shows how the same incident can require different actions from different teams when each team provides its own domain context.\n\nEfficient context is not simply a bigger prompt.\n\nIt is a deliberate combination of:\n\nAll three should be scoped tightly to the task.\n\nYou 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.\n\nBut if AI-assisted engineering is going to become a team practice rather than a personal trick, context needs to become:\n\nThat is the problem we are working on with [NeatContext](https://www.neatcontext.com/).\n\nYou can also try the [hands-on NeatContext demo on GitHub](https://github.com/XTSoftwareLabs/neatcontext-demo).\n\nHow 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.", "url": "https://wpnews.pro/news/how-to-build-efficient-context-for-your-ai-client-to-handle-incidents", "canonical_source": "https://dev.to/xtsoftwarelabs/how-to-build-efficient-context-for-your-ai-client-4fnd", "published_at": "2026-07-23 17:32:48+00:00", "updated_at": "2026-07-23 18:04:32.844554+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools", "ai-agents", "ai-infrastructure"], "entities": ["PagerDuty", "Datadog"], "alternates": {"html": "https://wpnews.pro/news/how-to-build-efficient-context-for-your-ai-client-to-handle-incidents", "markdown": "https://wpnews.pro/news/how-to-build-efficient-context-for-your-ai-client-to-handle-incidents.md", "text": "https://wpnews.pro/news/how-to-build-efficient-context-for-your-ai-client-to-handle-incidents.txt", "jsonld": "https://wpnews.pro/news/how-to-build-efficient-context-for-your-ai-client-to-handle-incidents.jsonld"}}