Most AI projects do not have a data shortage. They have a selection problem. A sales assistant gets a folder of old decks, every help-centre article, a few CRM fields, meeting notes, and a prompt asking it to be useful. Then the team is surprised when the answer is slow, muddled, or too confident. An AI context budget is a better starting point: decide what the agent may see for this job, why it needs each item, and what stays out.
Table of Contents
Context is not free
More context can make a model look more informed in a demo. In a live workflow, it also creates more material to weigh, more places for a stale promise to hide, more sensitive information to expose, and more ways for a reviewer to ask, “Why did it use that?” The cost is not only tokens. It is attention, latency, privacy risk, and the ability to explain an answer.
Think about a visitor asking whether a particular integration is included. The useful inputs may be the current product page, the approved integration list, and the visitor’s stated plan. Last year’s sales deck, every internal call note, and an unrelated customer’s CRM history do not make that answer more trustworthy. They make the system harder to reason about.
This is why an AI context budget belongs alongside the task itself. Before choosing the biggest model or the longest context window, name the smallest working set that lets the assistant do the job well. Smaller is not always safer or better; missing a necessary constraint can be just as damaging. The point is deliberate scope, not austerity for its own sake.
Build an AI context budget
A practical budget fits on one card. It has four parts:
- Job: the specific outcome, such as answering a standard-plan integration question or preparing a handoff.
- Approved evidence: the current sources that may support the answer, with an owner and scope.
- Relevant state: only the facts carried from this conversation or workflow that change the next step.
- Exclusions: material the agent must not use: expired collateral, unrelated customer data, private notes, or a broad archive with no role in this decision.
That card turns “use the knowledge base” into an operating instruction. It also makes the workflow easier to render in a visible orchestration tool such as an AI decision record: a reviewer can see what entered the lane, what rule governed it, and why the agent took its next step.
Do not confuse this with a universal source hierarchy. A source-of-truth policy decides which credible source wins when they conflict. The AI context budget decides which sources and state should enter this task at all. Both matter. The first resolves disagreement; the second prevents irrelevant or sensitive material from becoming part of the question.
The principle is close to data minimisation: use what is adequate, relevant, and limited to the purpose. The NIST Privacy Framework is useful reading here because it treats data processing as a managed risk, not a pile of information to collect just in case. For an AI workflow, that means asking whether each context item changes a justified outcome.
Make exclusion a product decision
Teams are usually good at naming what an assistant should know. They are less explicit about what it should ignore. That omission becomes a product decision by accident. The model’s access quietly expands because somebody connected another drive, imported another export, or left a broad retrieval index running after a pilot.
Write exclusions in normal language. “Do not use private CRM notes to answer public website questions.” “Do not use last quarter’s pricing deck when an approved current pricing page exists.” “Do not pull a person’s past conversation into a new request unless it changes the service they asked for.” These boundaries give customers a more predictable experience and give operators a clear place to investigate when an answer feels wrong.
This is also where privacy becomes product craft. A visitor does not experience “our vector store has sensible defaults.” They experience whether an assistant knows a fact it should not know, or cannot explain a promise it made. meLink’s approach to source-of-truth design for agents is useful precisely because it turns invisible data choices into an inspectable service boundary.
For teams building agentic systems, the NIST AI Risk Management Framework offers a complementary lens: govern and map the context, measure the outcome, then manage the resulting risk. It is not a prescription for a small business workflow. It is a reminder that an agent is a system, not merely a chat box.
Start with one consequential question
Pick a question that matters but repeats: an integration query, a security question, a contact-form triage decision, or a customer update draft. List everything the assistant can currently see. Then circle only the items that would change a correct answer. Put the rest in an exclusion list or a human-review route.
Run ten representative cases with the reduced set. Look for two outcomes: does the answer remain useful, and can a human explain its basis in under a minute? If not, add the missing context deliberately. If yes, you have found a smaller, safer lane worth keeping. This is an AI context budget in practice: a living design choice, tested against real work rather than a theoretical maximum.
The best agents do not feel omniscient. They feel appropriately informed. They know enough to help, enough to stop, and enough to show a human what they used. Give an agent every document you own and you have created a guessing machine with a large filing cabinet. Give it the right context for the job, and you have given it a chance to earn trust.
Leave a Reply