A large context window does not solve a weak knowledge architecture.
Neither does better retrieval.
An agent can retrieve the right document and still receive the wrong answer if the organization itself has not resolved which definitions are authoritative, how concepts relate across systems, or which source should win when information conflicts.
That is why I think we need to separate two ideas that are often treated as the same thing:
organizational knowledge and agent context.
They are not the same layer.
Context is what a model receives for a particular task.
Organizational knowledge is the larger body of information, semantics, relationships, provenance, and decisions from which that context is constructed.
Put differently:
Organizational knowledge is not context. Context is a task-specific projection of organizational knowledge.
That distinction becomes important as enterprises move beyond simple retrieval-augmented generation.
A company may have thousands of tables, APIs, dashboards, policies, architectural decisions, tickets, and documents available to an agent.
Availability does not make those sources coherent.
Consider something as ordinary as a business metric.
One team defines an active customer as someone who logged in during the last 30 days.
Another system defines it as a customer with an active paid subscription.
A finance dashboard excludes trial accounts.
A product dashboard includes them.
All four definitions may be internally correct.
Retrieval cannot decide which one the organization means when an executive asks:
How many active customers do we have?
Finding more documents does not resolve the semantic conflict.
It may simply expose it faster.
The layer before context engineering
Context engineering usually asks a runtime question:
What does this agent need to know to perform this task well?
That remains essential.
But there is an upstream question:
What does the organization actually know, and how is that knowledge represented?
Those are different engineering problems.
I would separate them into three responsibilities.
Knowledge infrastructure: what the organization knows
This layer manages the sources from which enterprise knowledge can be constructed:
data,
documents,
schemas,
lineage,
provenance,
and freshness.
Its job is not simply to make information searchable.
It has to make knowledge discoverable and traceable.
If an agent receives a number, it should ideally be possible to determine where that number came from, when it was produced, how it was derived, and whether a newer or more authoritative source exists.
Organizational semantics: what the organization means
This is where raw information becomes usable organizational knowledge.
Which definition of revenue is canonical?
What constitutes an active customer?
Which system is authoritative for employee identity?
Are two differently named fields actually the same business concept?
Which policy supersedes another when they conflict?
These questions cannot be solved purely through similarity search.
They require explicit semantics, ownership, governance, and sometimes deliberate organizational decisions.
Context engineering: what this agent needs now
Only after those layers do we reach runtime context.
The context system can then decide which subset of trusted organizational knowledge should be projected into a specific task.
That projection may include relevant documents, business definitions, schemas, prior decisions, and task-specific constraints.
The architecture therefore starts to look less like:
agent → retrieval → documents
and more like:
enterprise knowledge substrate → governed organizational semantics → context assembly → agent
That is a materially different architecture.
Retrieval is not knowledge
The rapid improvement of retrieval systems can obscure this distinction.
Hybrid search, reranking, embeddings, knowledge graphs, semantic indexes, and long-context models can dramatically improve an agent's ability to find relevant material.
But retrieval answers:
What information appears relevant?
It does not necessarily answer:
Which information should be believed?
Inside large organizations, the gap between those questions becomes much wider.
Two highly relevant documents may disagree.
The most frequently cited definition may be obsolete.
The newest document may describe an experiment rather than approved policy.
A database column may have an intuitive name but different semantics from the same term used elsewhere.
The agent can retrieve all of them perfectly and still have no principled way to determine which interpretation governs the task.
This is also where the idea can sound deceptively familiar.
Much of this overlaps with established disciplines: data governance, semantic layers, catalogs, lineage, master data management, and knowledge graphs.
The difference is not that agents invalidate those disciplines.
It is that they make their unresolved ambiguity operational.
A human analyst can notice that two dashboards disagree, ask a colleague, inspect documentation, and decide which definition makes sense.
An autonomous agent may simply choose one and act.
That changes the consequence of weak semantics.
What used to create analytical friction can now create machine behavior.
Agents make semantic ambiguity operational
A chatbot can sometimes survive uncertain context by asking the user a question.
An autonomous agent may act on it.
That raises the cost of ambiguity substantially.
If an agent is asked to investigate falling revenue, the definition of revenue matters.
If it is asked to modify infrastructure based on an architectural decision, the current ADR matters.
If it is asked to answer a compliance question, policy precedence matters.
If multiple agents collaborate, they need enough shared semantics to avoid reasoning correctly from incompatible assumptions.
Progressive disclosure still matters here, but only after the underlying knowledge is trustworthy.
An agent should receive the minimum context required for the task and acquire more as necessary.
But progressively revealing contradictory or poorly governed information does not solve the problem.
It merely reveals ambiguity in stages.
The sequence matters:
first establish reliable organizational knowledge; then decide what portion becomes context.
As autonomy grows, context quality therefore depends increasingly on the quality of the knowledge system behind it.
The most sophisticated context pipeline cannot compensate indefinitely for an organization that has never resolved what its information means.
This is why I increasingly see context engineering as the runtime edge of a larger knowledge architecture problem.
The immediate task is selecting the right information for the model.
The deeper task is making sure the organization has reliable knowledge worth selecting in the first place.
When that foundation is missing, the problem is not that the agent needs a bigger context window.
It is not even primarily a retrieval problem.
It is a knowledge architecture problem.
Better retrieval will only retrieve uncertainty more efficiently.