A Bigger Context Window Is Not Agent Memory

A one-million-token context window is an impressive engineering capability. It allows an agent to retain more code, tool output, documents, and conversation history before older information must be summarized or removed.
But a larger context window should not be confused with a complete memory system.
When building agents, it helps to separate three concepts: context, memory, and state.
Context is the model’s current working set. It may include the user request, retrieved documents, tool results, recent messages, and system instructions. A larger context window increases the amount of information the model can consider during one execution.
Memory is information that should persist beyond the current execution. This could include user preferences, previous decisions, reusable knowledge, commitments, or results that will be needed in a future session.
State describes the progress of a task. It records which steps have completed, which tools were called, what outputs were produced, whether approval is pending, and where execution should resume after a failure.
These layers have different lifecycles.
Context may be compacted or discarded. Memory must be selected and updated intentionally. Workflow state must be stored deterministically enough for the system to resume, inspect, or replay an execution.
Trying to solve all three by placing more information inside the prompt creates several problems:
Token usage and latency continue to grow.
Old and irrelevant information competes with useful context.
Task progress becomes difficult to inspect.
Recovery depends on the model reconstructing what happened.
Permissions and tool actions remain mixed with natural-language history.
A production Agent Runtime should therefore manage these responsibilities outside the model where appropriate.
The model still reasons over context, but persistent memory, workflow state, permissions, tool execution, and runtime logs need their own structures.
This is one of the architectural ideas we are exploring in ZGI. The goal is not to fit the entire system into a larger prompt. It is to give each layer a clear responsibility and make agent execution easier to understand and operate.
ZGI is available here, and feedback from other builders is welcome:
https://github.com/zgiai/zgi