Why Bigger Context Windows Won't Save Your Agent — Elizabeth Fuentes Leone, AWS
Elizabeth Fuentes Leone, developer advocate at AWS, explains why agents break when tools return huge outputs, why bigger context windows do not fix the problem because models lose the middle of long contexts, and how four context engineering strategies (externalize, select, compress, isolate) can be implemented with the open-source Strands Agents framework.
Why bigger context windows don’t rescue agents
Elizabeth Fuentes Leone, developer advocate at AWS, starts from a failure mode most agent builders have hit: agents break when tools return very large amounts of data. The context window overflows, and the model begins to hallucinate and its reasoning quality degrades. Her running example is a supervisor agent that retrieves application logs. Every retrieval is appended to the context, and because each session replays prior history to ‘remember everything,’ the window keeps growing.
A year or so before the current agentic wave, the common assumption was that a larger window would fix this. She argues that assumption no longer holds. Models attend strongly to the beginning and end of a long context and lose information in the middle, the ’lost in the middle’ attention curve. Oversized contexts also become a liability, since injected or poisoned content can sit unnoticed among the tokens and influence the model.
Context engineering as the answer
Her definition of context engineering is giving the model the information it needs, at the moment it needs it, and not everything it could possibly see. The payoff is better outcomes and lower token consumption. She organizes the techniques into four strategies:
- Externalize: move large data into persistent storage and keep only a pointer in context.
- Select: retrieve only what is relevant to the current step.
- Compress: summarize or compact information so it takes fewer tokens.
- Isolate: separate context across agents so each one sees only its own slice.
Conversation managers in Strands Agents
The first and simplest technique is a conversation manager. She uses Strands Agents, an open-source, free, model-agnostic framework, to illustrate it. Strands ships with three conversation managers: a sliding window that keeps only the most recent messages, a summarizing manager that condenses older messages into a summary, and a combined approach that summarizes older turns while keeping recent ones verbatim.
Creating a full agent loop takes one line, because the framework builds the loop, the graph, the system prompt, and the tools behind the scenes. By default it uses Amazon Bedrock, and switching to OpenAI, Gemini, or Anthropic requires importing the provider library and adding one model line.
Her code example configures a summarizing manager with a summary ratio of 50%, preserving the last four messages. On each invocation, the session compresses the older half of the history and keeps the most recent four messages intact.
Memory layers
She frames memory as three complementary layers:
- Short-term memory holds the recent conversation history for the current session.
- Long-term memory lives in a vector database, with separate memory types and prompts that capture what matters from past conversations, so a new session can retrieve it.
- Graph memory models entities and their relationships and supports traversal-based reasoning about how things connect. She points to Neo4j as a good reference for this approach.
Her recommendation is to combine them: short-term memory for the active session, long-term memory for recall across sessions, and graph memory for relational knowledge that benefits from a different structure.
Memory pointers for large tool outputs
This is the core technique for the log-watching scenario. Instead of placing raw logs in context, the architecture uses two tools. The first fetches the logs, saves them to storage, and returns only an ID. That ID is kept in the agent state, which Strands exposes through the tool context. The second tool takes the ID and retrieves the logs only when the agent actually needs to inspect them.
In Strands, tools are defined with a decorator, and the fetch tool receives the agent state through its tool context. The context window therefore holds a small handle instead of megabytes of logs.
Sharing pointers across a swarm
For more complex systems she describes a multi-agent swarm. Sharing the entire context window among agents would pollute each one with information it does not need. Instead, the swarm shares only the memory pointer through the invocation state. Agents receive a common ID and can fetch the data they require, while the rest of their context stays clean.
Preventing endless tool loops
Agents sometimes get stuck invoking the same tool repeatedly, often because the tool’s response was unclear and the model keeps trying to get a better answer. Her mitigation has two parts: make tool responses clear and unambiguous, and cap how many times each tool can be called. In her example, the search tool and a second tool are each limited to three invocations, so the agent cannot fall into an unbounded internal loop.
Async handles for slow MCP tools
The final technique addresses latency rather than context size. MCP tools and external APIs can be slow, and synchronous calls leave the agent waiting indefinitely. She notes that managed gateways such as AWS API Gateway have hard timeouts, so a delayed response can crash the application. The fix is an async handle: the agent starts the job, receives a handle immediately, and checks the status or retrieves the result in a later invocation.
Her demo uses an MCP server built with FastAPI and exposes two tools, one to start a job and one to check its status. In her tests, the async version kept the agent responsive, while the synchronous version stalled while waiting for the answer.
Anti-patterns to avoid
- Context stuffing: including everything in the window instead of only what is needed to answer the current request.
- Naive summarization: compressing history without checking whether the details needed later survive.
- Context pollution: passing the full context to every agent in a multi-agent system.
Cheat sheet
For large tool outputs such as logs, database results, or alerts, externalize the data, select what is relevant, and keep a memory pointer in context. When many agents need the same large data, share the pointer through invocation state. To stop endless loops, give tools clear responses and limit their call counts. For slow external tools, use async handles rather than blocking calls.
She closes by pointing listeners to the Strands Agents GitHub organization and promising to share the slide deck.