Module 1 · Foundations of Agentic AI · scripted

The Context Window: The Wall Has Edges

20 minoutcomes: context-engineering

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

The cave:the wall has edges — shadows compete for wall space
The book:a page limit on the conversation it can read at once
The measure:a budget of tokens (≈ words), fixed by the model

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

the goal and the situation"find updates about my Molde trip"
the tools and their parameterssearch_email(query), read_email(id) …
every action taken so farthe whole history of tool calls
every result received so farwhat the computer reported each time

So watch what happens when one participant is careless with the shared wall:

Example 1 · The result that ate the window
user

You have the following tools available for use:


  1. search_email( query )
  2. read_email( id )

Task: Find any updates related to my Molde trip.

assistant
⟨tool_use⟩
search_email(query="Molde")
user
⟨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)
NoteOne action, and thousands of words of terms, disclaimers, and email signatures are now permanently on the wall — competing with the goal, the tools, and every future result for the same limited space. The schedule change that matters is buried in it.
Example 2 · The result that respected it
user

You have the following tools available for use:


  1. search_email( query ) — returns matches as (id, sender, subject, one-line summary)
  2. read_email( id ) — returns the message body only

Task: Find any updates related to my Molde trip.

assistant
⟨tool_use⟩
search_email(query="Molde")
user
⟨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
assistant
⟨tool_use⟩
read_email(id=47)
user
⟨tool_result⟩
"Your SAS flight WF562 Oslo–Molde on 24 Aug now departs 14:05
(previously 11:20)."
NoteSame world, same goal. But the tools were designed to cast compact shadows: summaries first, full text only on request, and only the body. The window holds the goal, the history, and the one detail that matters — with room left to keep working.
Reading the two walls
  • 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.

Your turn

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?