Most context problems do not announce themselves as context problems.
They show up as confident answers about the wrong source. Stale recommendations. Duplicate summaries. Bad tool choices. A model that looks like it is hallucinating when the real issue is that the system gave it the wrong material to trust.
That is why I treat context as a control layer, not as prompt stuffing.
Durable project memory is part of the picture, but it is not the same thing. Memory carries useful information across work. Context control decides which sources the system may trust for the decision in front of it.
The practical question is not simply how many tokens fit in the window. It is what the model was allowed to see, how fresh that material was, who was allowed to expose it, what permissions applied, and whether the source was appropriate for the action.
Context governance is not only an engineering concern. The business has to decide which policy, contract, customer record, runbook, or source is authoritative when sources conflict.
Before switching models, inspect the context path.
Start there when authority, freshness, or permission is in question.
Bigger windows do not fix bad inputs
A larger context window can help, but it can also hide a messy context strategy.
If the source is stale, a bigger window gives the model more stale material. If the source is duplicated, it gives the model more conflict. If the source is unauthorized, it gives the workflow a governance problem. If the source has no provenance, it gives reviewers no way to decide whether the answer should be trusted.
Consider a sales agent that recommends a discount.
It pulls last quarter’s pricing rules, misses the current contract terms, and summarizes a policy that no longer applies. The output may sound reasonable. The failure is upstream. The agent answered from the wrong slice of the business.
Telling the model to “be more accurate” will not fix that failure. The system has to control the context.
What context control includes
A useful context layer has several concrete responsibilities.
First, source inventory. The team should know which documents, tickets, notes, tables, APIs, and repositories the agent can use. A source no one has listed is a source no one has reviewed.
Second, freshness. Pricing, policy, incident status, customer contracts, and deployment runbooks need different freshness rules. The agent should not treat a six-month-old page and a current contract as equivalent.
Third, provenance. A reviewer should be able to see which source supported a claim or action. If the agent cannot show where a recommendation came from, the human reviewer inherits the uncertainty.
Fourth, permissions. Context access is part of the security model. An agent should not retrieve material merely because it exists. It should retrieve only what the user, task, and policy allow.
Fifth, memory and retrieval boundaries. Durable memory, short-term task state, and search results are different things. Mixing them together makes failures harder to debug.
Sixth, trace visibility. Context should appear in the trace. Reviewers need to see what the agent read and what it ignored.
MCP can standardize how AI applications connect to tools, data sources, and workflows. That is useful, but connection does not establish trust. Authorization, provenance, audit, and review still have to be designed.
The same is true for memory. Persistent memory can make an agent feel more useful, but it also raises source-quality questions. Which memories can override current documents? Which ones expire? Which ones came from a user preference, a prior task, or a business rule? If memory is treated as a general bucket of helpful facts, it can become another stale source with a friendlier name.
A practical source review
The first improvement I would make in many agent programs is a source review.
Pick one workflow and ask:
- Which sources does the agent need to complete the task?
- Which source is authoritative when documents conflict?
- How fresh does each source need to be?
- Who is allowed to expose each source to the agent?
- Which retrieved sources appear in the trace?
- Which actions require the agent to cite or show provenance?
- What happens when the right source is missing?
This review changes the conversation.
Instead of debating whether the model is smart enough, the team can inspect whether the system gave the model the right operating material. In many failures, that is the first place to look.
It also gives reviewers a practical artifact. A source inventory can sit next to evals and traces. When an answer is wrong, the team can ask whether the source list was incomplete, the retrieval rule was weak, the permission boundary was too broad, or a freshness rule was missing.
Business owners have a role here. They may not care about embedding strategy or retrieval architecture, but they do know which contract, policy, ticket, or customer record should be authoritative. Context design improves when those ownership decisions are explicit.
Context does not beat model quality every time. Some tasks need better models, tools, or workflow design. But when an answer is grounded in the wrong slice of the business, inspect the context path first.
Inspect source selection, freshness, provenance, permissions, memory boundaries, retrieval behavior, and trace visibility.
Before your agent answers or acts, ask whether you can explain which sources it was allowed to trust, and why. Here are five ways to find out.
A few things to try
- Build one source inventory. Pick an agent workflow and list every document, ticket, table, API, repository, and memory source it can use. Name the business owner and permission boundary for each source, not just the technical connector.
- Set one freshness rule. Choose a source that changes often, such as pricing, policy, incident status, or a deployment runbook. Define when it expires, how the agent detects a newer version, and what it should do when current material is missing.
- Resolve one source conflict. Take two documents that could disagree, such as a standard policy and a customer contract. Record which source is authoritative for the workflow, who can change that decision, and what the agent should do when it cannot tell.
- Put retrieved context in the trace. Review one run and make sure a reviewer can see what the agent read, what it ignored, and which source supported its recommendation or action. Without that path, the reviewer has to reconstruct the evidence.
- Assign an owner for source quality. Give someone responsibility for source access, freshness, provenance, and retirement. If every source is merely “available,” no one is accountable when the agent uses the wrong one.
Can you explain which sources it was allowed to trust, and why?