The Bottleneck Is Moving From Intelligence to Context

A capable AI system can explain how to negotiate a contract renewal, compare commercial options, and draft a persuasive recommendation. Those abilities do not tell it whether the customer has already received a concession, whether a service problem remains unresolved, or whether the person requesting the recommendation can authorize the proposed terms.

The missing information may exist somewhere in the organization. Some of it may be recorded in a customer system, some in a signed agreement, and some in the experience of an account manager. A recent decision may have changed what is acceptable without yet appearing in the formal guidance. The model can reason well about the information it receives and still recommend the wrong action for that situation.

As access to sophisticated models broadens, this distinction becomes strategically important. Organizations can obtain similar analytical capabilities while remaining very different in their ability to apply them. Normatic's view is that an increasingly important constraint lies in making organizational context available, trustworthy, and usable at the point of work.

Our previous Perspective examined how ownership and authority should be distributed across the organization. This article concerns what those arrangements must enable intelligence to work with: the relevant knowledge, objectives, constraints, permissions, and current state of the business.

Context does not replace model capability or human judgment. It supplies the basis on which both can be applied to a particular decision.

Context is the situation in which an answer must work

In technical discussions, context often means the information supplied to a model during an interaction. For an enterprise, the management problem extends further. It includes deciding which information is relevant, which sources carry authority, and which conditions govern its use.

Business context establishes what the organization is trying to achieve. A recommendation can differ depending on whether the priority is margin, service continuity, growth, or a particular customer relationship. Policies, economics, and accepted risk boundaries determine which options deserve consideration. If those priorities remain implicit, the system must operate on incomplete instructions or introduce assumptions of its own.

Knowledge context supplies the evidence: documents, records, specialist expertise, correspondence, and prior decisions. But evidence becomes operationally meaningful through workflow context. A proposal under discussion is different from an approved commitment. A request being assessed for completeness is different from one awaiting a final decision. The trigger, completed activities, next action, accountable owner, and completion criteria all affect what assistance is useful.

User context adds another distinction. Two people asking the same question may have different responsibilities, expertise, access rights, and authority to act. The appropriate explanation may change with their role; the information they are permitted to receive must follow established access controls.

System and temporal context connect that understanding to present reality. Enterprise planning, customer, and case-management systems may hold facts that change after a document is written or an earlier answer is produced. An answer can accurately describe yesterday's position and still be wrong for today's decision. A newly uploaded document, meanwhile, may describe a policy that has not yet taken effect. Recording when something was retrieved is not the same as knowing when it applies.

These dimensions interact. A piece of information becomes useful context through its relationship to a purpose, a decision, a person, and a moment in the workflow.

Model capability and context are complementary

A stronger model can interpret difficult material, connect dispersed evidence, identify inconsistencies, and recognize that a question cannot yet be answered. Those capabilities remain consequential. Context cannot compensate indefinitely for a system that cannot perform the required reasoning reliably.

The reverse is equally important. A stronger model cannot reliably reconstruct an unrecorded commercial commitment or determine which of two conflicting internal policies the organization has actually authorized. It may infer a plausible answer. Plausibility does not establish the missing fact or confer institutional authority.

Consider two companies using the same model to support contract renewals. One can assemble the applicable agreement, current service record, prior concessions, approved commercial boundaries, and the decision-maker's authority. The other provides a folder of sales material and asks for advice. Differences in the recommendations would reflect more than model quality. The systems have been given different conditions for doing useful work.

This is an illustrative comparison, not evidence of measured performance. Its implication is that model evaluation and context design belong together. A task may require a better model, better source material, a more reliable connection to operational systems, or some combination. Treating every failure as a model problem can leave the binding constraint untouched.

Anthropic's 2025 guidance on context engineering describes an engineering task broader than writing prompts: maintaining the information available to a model as instructions, tool results, external data, and interaction history change. It is practitioner guidance rather than a controlled study of enterprise returns. The relevant organizational implication is that context requires continuing selection and maintenance. Connecting a repository once does not complete that work. Effective context engineering for AI agents

More information can weaken the basis for a decision

Giving a system access to a larger collection does not establish that it can distinguish current policy from an obsolete copy, an approved exception from a draft request, or independent evidence from several documents repeating the same claim.

Chroma's 2025 Context Rot report tested long-context behavior across a set of 18 models. Its experiments found uneven performance as input length increased and showed that related but misleading material could reduce accuracy. These were bounded technical evaluations of the models tested, not evidence that every additional document harms every system or a ranking of today's models. They challenge the assumption that accommodating more input necessarily means using it well. Context Rot

For organizations, there is a separate problem even when retrieval and reasoning work as intended: the retrieved material itself may have no settled authority. A search system can find three inconsistent policy documents accurately. It cannot settle which policy should govern simply by retrieving all three.

Context quality therefore includes relationships that raw content does not express. Who maintains the source? What business object does it describe? When did it become effective? Has it been superseded? Does it record a general rule, a proposal, or an exception? Which part of the decision does it support?

Provenance makes those relationships inspectable. A recommendation should preserve access to the underlying record and its relevant status, rather than presenting a synthesized answer as a new source of truth. Citations help readers examine evidence; they do not by themselves prove that the evidence is authoritative, complete, or applicable.

Selection should also preserve uncertainty. If the relevant contract amendment cannot be located, the useful response may be to identify that gap and seek confirmation. Adding loosely related material cannot supply the missing agreement. A context capability needs to make absence and conflict visible as well as retrieve information.

The workflow determines which context matters

Return to the renewal example. A useful system might need the signed contract and amendments, the latest service issues, previous concessions, the renewal deadline, current pricing boundaries, and the authority of the person making the decision. It would need to distinguish an account manager's negotiating suggestion from a commitment already made to the customer.

That is a substantial information requirement, but it is bounded. It does not justify unrestricted access to unrelated customer records, employee information, or the entire email archive. The question is what could change this decision and what the system is authorized to use for that purpose.

The required context also changes as work progresses. Preparing options calls for evidence and constraints. Seeking approval requires a clear account of the proposed commitment and unresolved issues. Executing an approved change requires confirmation that approval remains valid and that the relevant record has not changed in the meantime. A conversation summary from the preparation stage is not sufficient evidence of current execution authority.

History helps explain how the present situation arose. A previous concession may have been conditional on a service improvement, rather than a standing commercial entitlement. Recording the decision without its scope and rationale can cause a later system to treat an exception as precedent. Workflow history must preserve the distinctions that matter for future use.

This extends the argument that the workflow is the unit of transformation. It also becomes a practical boundary for context design. Leaders can identify the decisions that matter, the evidence they require, and the gaps that prevent reliable action. They do not need to make all enterprise knowledge available before improving one meaningful flow of work.

AI exposes how well the organization knows what it knows

Organizations can function with substantial gaps in their formal knowledge because experienced people compensate for them. A colleague knows which spreadsheet is trusted, which policy is awaiting revision, and whom to contact when two systems disagree. The formal record and the practical way of working are held together by relationships and memory.

When an AI system is expected to operate across the same environment, those hidden dependencies become design problems. A document may have no owner. A familiar business term may mean different things in two departments. The customer system may record an opportunity as closed while the contract repository still contains only a draft. Combining these records does not automatically reconcile them.

The remedy involves organizational work as well as engineering. Someone must establish the applicable definition, resolve an inconsistency, or record a decision that previously existed only in conversation. The aim is to improve the knowledge needed for a particular outcome, with named responsibility for keeping it usable.

Specialist expertise has a different character from a database field. Some knowledge can be expressed through examples, decision rationales, exception patterns, and review criteria. Some remains dependent on experience, relationships, or an emerging situation. Making expertise accessible should include a route to the person who can exercise it, rather than assuming that every important judgment can be captured in a document.

AI can assist this work by surfacing conflicting passages, proposing summaries, and identifying recurring gaps. Its outputs still require appropriate validation before they become authoritative guidance. Otherwise, an organization risks repeatedly retrieving its own unverified summaries and mistaking repetition for corroboration.

Preparing for AI can therefore improve the organization's ability to know what it knows. The gain is a more dependable connection between evidence, interpretation, and responsibility—useful to employees as well as AI systems.

Permissions are part of context quality

A context layer that makes information relevant but exposes it to the wrong person is not performing its function well. Access must reflect identity, responsibility, sensitivity, permitted purpose, and applicable location or jurisdictional constraints. These conditions belong in the surrounding systems and controls; they cannot depend solely on a model interpreting a written instruction correctly.

Access and disclosure also differ. An employee may be permitted to consult internal material while preparing a customer response without being permitted to include all of it in that response. The recipient and purpose matter alongside the requesting user's access rights. Permission to read information is also distinct from permission to change a record or make a commitment.

The 2026 CI-Work benchmark examines this distinction using simulated enterprise workflows and synthetic data. Researchers found that the tested agents could disclose sensitive context while conveying useful information, and that greater model size or reasoning effort did not reliably resolve the problem. The results concern benchmark behavior, not measured leakage rates in deployed enterprises. They support evaluating appropriate information flow alongside task completion. CI-Work: Benchmarking Contextual Integrity in Enterprise LLM Agents

Normatic's implication is that relevance, authorization, and appropriate disclosure must be designed together. Information should be retrieved within enforceable access boundaries, used for the permitted task, and handled according to the audience receiving the result. Changes to permissions need to affect retained context as well as future retrieval. A previously authorized conversation should not become a permanent route around later restrictions.

The same discipline applies to authority inside the material. An instruction quoted in an email or external document should not acquire the status of an approved operating rule merely because the system retrieved it. Context provides evidence for the work; the organization must still determine which sources may direct the system's behavior.

Context becomes a managed enterprise capability

Treating context as infrastructure means making it dependable enough for multiple workflows to use. It does not require a single repository, a new platform category, or one architecture for every organization.

Some decisions need carefully maintained guidance and a reliable way to find it. Others require live connections to operational systems, workflow events, identity controls, and decision history. Search, retrieval, enterprise interfaces, metadata, and evaluation can contribute to the capability. Their value depends on whether they make the required context available with the right meaning, freshness, and controls.

Shared foundations may support many workflows, while each workflow retains specific requirements. A common customer identifier can help connect records, but it does not determine which commercial history matters for a renewal. A shared permissions service can enforce access, but the business must still define the purpose and authority of the proposed use. Common infrastructure and domain ownership need to develop together.

Performance should be assessed where the context is used. Can the system distinguish a superseded policy from the applicable one? Does it notice that a relevant record changed? Can it surface missing evidence, preserve source references, and withhold information from an unauthorized recipient? Does the resulting workflow require less reconstruction and rework while maintaining decision quality?

These checks reveal different failure causes. The source may be wrong, retrieval may miss it, the model may misinterpret it, or an integration may return stale state. Distinguishing those causes directs improvement to the responsible part of the system. Changing the model alone would address only one of them.

The strategic opportunity lies in how well an organization maintains these connections. Proprietary data is not an automatic advantage. It may be inaccessible, inconsistent, or disconnected from the decisions that create value. An organization that connects its knowledge to current work, explicit authority, and feedback from outcomes has a stronger basis for turning widely available AI capability into differentiated performance.

The bottleneck will not move at the same pace in every organization or task. Model limitations remain real, and better context cannot remove uncertainty from the world. But as intelligence becomes easier to obtain, leadership attention should increasingly turn to the conditions under which it is used: the right organizational context, at the right moment, with the right permissions, inside the workflow where an outcome is produced.

Sources

• Anthropic — Effective context engineering for AI agents. September 2025. Primary engineering guidance on selecting and maintaining model context; not a study of enterprise business returns.
• Chroma — Context Rot: How Increasing Input Tokens Impacts LLM Performance. July 2025. Technical evaluations of long-context behavior and distractors; findings apply to the tasks and models tested.
• Wenjie Fu and colleagues — CI-Work: Benchmarking Contextual Integrity in Enterprise LLM Agents. ACL Industry Track, July 2026. Evaluation of information disclosure in simulated enterprise workflows using synthetic data.

The organizational and strategic conclusions are Normatic's interpretation. The contract-renewal scenarios are illustrative and do not represent client engagements or measured results.