Yes, it is true. A one-million-token context window can hold more than 700,000 words, roughly the scale of several Harry Potter novels [1].
Imagine putting two Harry Potter novels beside two project risk management manuals and asking AI for a contingency recommendation. A capable model should recognize that the novels are irrelevant. But what if, all four documents are technical, plausible, and potentially relevant, but differ in authority, date, assumptions, and purpose.
Anyone who has built AI models or agents for real work will recognize the implication: a million-token context window does not remove the need to engineer the context. It matters especially when an agent must work across many projects, repeat decisions at scale, and deliver answers whose accuracy can be checked.
The size of the window tells us how much information the model can accept, not whether that information supports the right conclusion.
As context windows grow, the greatest marginal gains may come from designing processes that help AI determine which relationships, assumptions, and sources matter to a decision, and what additional evidence it needs to reach a reliable conclusion.
When every document looks relevant
Imagine an AI agent estimating the contingency needed for a construction project.
It has access to risk procedures, engineering reports, and project schedules. However, a recent engineering report changes an earlier assumption, which affects the construction method, schedule, and costs. The AI might correctly read and cite every document but still reach the wrong conclusion if it fails to recognize how these changes are connected.
Project knowledge, as many other complex domins, is not merely a pile of documents or a flat table of facts. It is a network: a design choice depends on a site condition; the choice changes an activity; the activity affects resources and schedule; and those changes alter the risk picture. Some connections are explicit in project records. Others must be inferred and verified.
This is the problem we explored in the Uniform Project Ontology, that presents an ontology-based approach to representing industrial megaproject knowledge using linked data and the semantic web [2]. An ontology specifies entities and the meanings of relationships among them. A knowledge graph can express these entities as nodes and relationships as edges, supporting queries and reasoning across project information.
This does not mean relational databases are incapable of representing project relationships. Rather, the challenge is preserving their meaning across documents, systems, disciplines, and project phases. Nor does UPonto by itself establish that an LLM will answer more accurately. It explains why making project relationships explicit is a promising foundation for better AI context.
Reading more, reasoning better
There is experimental support for distinguishing context capacity from context use.
In Lost in the Middle, Liu and colleagues found that models could struggle to use relevant material placed in the middle of long inputs [3]. A later RAG study found that adding retrieved passages often improved performance at first, then degraded it as plausible but misleading passages accumulated [4]. The NoLiMa benchmark also showed that finding information becomes harder when a model must infer semantic connections rather than match similar words [5].
Nonetheless, sufficiently resourced long-context models outperform conventional retrieval-augmented generation, or RAG, on average in their tested tasks [6]. Some decisions genuinely require broad context because an unexpected relationship may be decisive.
So the question is not How little information can we give the model? It is How can we ensure the information it uses is relevant, authoritative, appropriately connected, and sufficient?
The assumption hidden inside a convincing answer
I see an analogy whenever I mark engineering exams. Students can be conscientious, understand the method, and perform each calculation carefully, yet reach the wrong conclusion because of one quiet assumption.
Two risks are treated as independent. A boundary condition is misunderstood. A design stage is taken for granted. The reasoning that follows may be internally consistent, but it is built on the wrong starting point.
We see something similar in AI-generated work. An agent may search diligently and still interpret a superseded document as the governing record. Worse, once it chooses that interpretation, it may keep retrieving evidence that appears to support it.
Language itself contributes to the difficulty. Clark and Brennan described communication as building common ground, the shared understanding that allows people to interpret each other’s words [7].
Michael Polanyi’s work on tacit knowledge helps explain why professional judgment cannot always be fully captured in a manual [8]. A skilled worker, say a plumber or a barber learns through practice and feedback that builds the important context, not only through instructions.
Why not let AI curate the context itself?
A reasonable objection follows. If models are becoming better at planning, searching, and using tools, why should we do the curation ourselves? Let AI read the project repository, locate the right documents, and correct its own mistakes.
We should. At least, we should allow it to do much of the work.
Research on Self-RAG shows that models can be trained to decide when to retrieve evidence and to critique the information they obtain [9]. Anthropic’s guidance on context engineering likewise describes agents retrieving information as needed and refining their working context over successive steps [10]. Human experts do not need to hand-pick every page every time.
But an agent that can curate information is not necessarily an agent that can validate its own assumptions, at scale.
Research on intrinsic self-correction found cases where asking a model to revise its reasoning without external feedback failed or made performance worse [11]. This finding does not refute all methods of self-revision; it identifies a weakness in revision that introduces no independent evidence.
The useful distinction, then, is not between human-curated and AI-curated context. It is between a process that accepts its first interpretation and one that actively looks for reasons to change and optimize it.
Context engineering is the process of governing the agent’s curation.
More and more, the mindset shift appears to be “how to interact with this new form of intelligence,” rather than, “how to use AI.”
Explain it to a Friend
What if an AI could read every document ever written about a project and still miss the one relationship that changes the decision?
Perhaps the deepest limit would not be memory, but judgment about what deserves attention and what remains unknown. A larger window would help it remember more. A better process would help it notice what it has misunderstood, seek evidence beyond its current interpretation, and sometimes ask a person who has seen the site.
Could the future of intelligence depend less on possessing all the answers than on knowing what to investigate next?
How would you explain this to a friend?
Notes
This post is part of the PM Along AI series. See all episodes here.
Join the EPM Network to access insights, influence our research, and connect with a community shaping the industry’s future.
You are not receiving future PM Along AI posts simply by subscribing to EPM Research. Learn how to receive future PM Along AI posts.
Support us by sharing this article with your friends and colleagues, or over social media.
References
[1] Google DeepMind. (2024). Introducing Gemini 1.5, Google’s next-generation AI model.
[8] Polanyi, M. (1966). The tacit dimension. Doubleday.
[10] Anthropic Engineering. (2025). Effective context engineering for AI agents.
[11] Huang, J., et al. (2024). Large language models cannot self-correct reasoning yet. ICLR.


