Module 1 · Foundations of Agentic AI · scripted
The Context Window: The Wall Has Edges
The wall has edges
Stay in the cave one more lesson. We said: you are the fire, and the conversation is the wall where you cast the world as word-shadows. Now the constraint: the wall in front of the LLM is limited. We cannot project everything onto it at once — the entire world will not fit. If it could, the LLM would probably perform a great deal better. But there is only so much wall.
That limited space is called the context window.
The world will not fit on the wall
A page limit
Another way to think about it: the LLM has a page limit on the length of the conversation it can read and deal with at once. Everything we have built — the script, the trajectory, the tools, the results — must fit inside that limit, and we have to use it very, very efficiently.
The space on the wall is measured in tokens. We will look at tokens properly later; for now, think of a token as roughly a word. So the question "how big is the window?" is roughly: how many words can it see at one time?
Three ways to say the same limit
And this is a hard boundary on agents: the agent's ability to work is inherently constrained by the length of the conversation we can create and have it reason about. An agent is a conversation — so the window is the size of the agent's world.
Everything competes for the same space
The window creates two pressures, and they squeeze from both ends.
First: the amount of information we can give the LLM to understand the situation, the goal, and the task is limited by the window.
Second: as the agent takes actions and receives information back about the external world, those results are limited by the same window — and here is the crucial part — everything is competing for the same space:
One wall, many shadows competing for it
So watch what happens when one participant is careless with the shared wall:
Find any updates related to my Molde trip. Tools: search_email(query), read_email(id).
⟨tool_use⟩
search_email(query="Molde")⟨tool_result⟩
[Returning all matching content]
Email 12, full text, 1,400 words: "Hotel Alexandra — booking
confirmed… (terms and conditions, cancellation policy, loyalty
program, parking information, breakfast hours…)"
Email 47, full text, 2,100 words: "SAS schedule change… (fare rules,
baggage allowances, codeshare notices, lounge access…)"
Email 51, full thread, 3,800 words: "Fwd: fjord kayaking?" (six
forwarded replies, signatures, and disclaimers)Find any updates related to my Molde trip. Tools: search_email(query) → returns matches as (id, sender, subject, one-line summary); read_email(id) → returns the message body only.
⟨tool_use⟩
search_email(query="Molde")⟨tool_result⟩
[12] Hotel Alexandra — "Booking confirmed" — reservation unchanged
[47] SAS — "Schedule change" — flight WF562 24 Aug now departs 14:05
[51] Erik — "Fwd: fjord kayaking?" — proposes Saturday morning⟨tool_use⟩
read_email(id=47)⟨tool_result⟩
"Your SAS flight WF562 Oslo–Molde on 24 Aug now departs 14:05
(previously 11:20)."- In Example 1, what exactly is the wasted wall space made of? Who put it there — the LLM, or the tool's designer?
- Example 2's search result throws almost everything away. What did it carefully keep?
- What happens to Example 1's agent on action five? Action ten?
Casting economically
The context window turns the shadow-casting insight into an engineering discipline. Casting shadows well is not only about being accurate — it is about being economical: for every piece of the world, we must ask what the LLM actually needs on the wall to make its next decision, and what is merely occupying space. The goal statement, each tool description, each result a tool sends back — every one of them is a choice about how to spend a limited budget.
Much of what comes later in this course — summarizing, retrieving, revealing information in stages — is a set of strategies for exactly this problem. For now, carry the constraint itself: the wall has edges, and everything you project must earn its place on it.
Take the agent you sketched for your own domain and audit its shadows: for each tool, write down what its result would actually contain. Which tool, as designed, could eat the window in one action? Redesign that result to be the Example 2 version — what does it keep, and what does it make requestable on demand?