A context window is the limit on the information a language model can work with at one time, measured in tokens. Depending on the model and application, that information can include instructions, conversation history, documents, tool results and the response being generated.
When an AI assistant appears to forget a decision, several things may have happened. The relevant detail might be absent from the current request, compressed out of a summary, contradicted by newer material or simply used incorrectly. A long conversation stored in an application does not establish that every part of it reaches the model on every turn.
Understanding the context window helps separate these problems. It also explains why continuing work needs a dependable record outside the immediate conversation. A team should be able to recover its current objective, constraints and evidence without hoping that a particular chat still contains everything important.
What counts toward a context window?
Models process information as tokens. In text, a token can be a word, part of a word or a character. Tokenization depends on the model, so a word count is not an exact token count. Google's token documentation explains this distinction and how nontext inputs are also accounted for in its API.
The visible message is only part of the information an application may supply. The request can also contain system instructions, tool descriptions, earlier messages and retrieved passages. A short question can therefore produce a large request.
Input and output limits also need to be read carefully. The relationship between the context limit, generated response and any reasoning budget varies by model. Google's long context guidance describes differing input and output arrangements within its own model families. Check the selected model's actual contract before assigning a budget.
The practical lesson is to measure the complete request through the appropriate tooling. Counting only the paragraph a user typed will miss the other material the application added.
Why is chat history different from active context?
Chat history is an application record. Active context is the information made available for the current model operation. The application determines how the two relate.
It might include earlier messages directly, retrieve selected records or supply a summary of previous work. It may preserve the complete conversation for the person while sending a smaller representation to the model. The details depend on the product and its configuration.
This distinction matters when investigating an apparent memory failure. If a constraint is missing from the current context, asking the model why it ignored that constraint may produce an explanation without establishing what actually happened.
Where the application exposes the relevant records, inspect the assembled input, selected sources and omissions. If those details are unavailable, keep that uncertainty explicit. A model's answer about its own access is not a substitute for an application record.
Four reasons an assistant can lose an important detail
The symptoms can look similar while requiring different fixes.
The information was never supplied. A project document may exist in storage without being selected for the request. Check retrieval and input assembly before changing the model's instructions.
A summary omitted the condition. “Migrate the reporting database” does not preserve “customer exports must remain available throughout the change.” The shorter wording can retain the task while losing the constraint that determines an acceptable plan.
The information is stale or contradictory. An old proposal and an accepted decision can both appear in the context. The application needs to make their status and applicability understandable.
The model did not use available evidence correctly. A fact can be present without being applied correctly. This is an answer quality problem that needs evaluation, not proof that the context window was too small.
Avoid treating every failure as the same kind of forgetting. The distinction determines whether the next change should address source selection, summary design, record maintenance or model behavior.
Example: resuming a database migration
In this hypothetical scenario, a software team is planning a reporting database migration over several weeks. Different engineers and assistants contribute investigation, test results and proposed changes. The team needs to preserve customer exports during the transition.
An early conversation establishes three constraints: no customer downtime, a tested recovery route and confirmation that both database versions produce the expected exports. Later discussions contain schema details, exploratory alternatives and a revised sequence of work.
When another engineer resumes the project, the question is not whether the entire transcript can fit in a new model request. The question is what the next decision requires and whether the important constraints are still supported by current evidence.
Keep a recoverable project record
The team retains the objective, accepted constraints, current plan, unresolved questions and links to the relevant source records. It distinguishes a proposed recovery procedure from a tested one.
The record should identify what changed and why. If the team revises the migration sequence, an older plan can remain available as history without being mistaken for the current instruction.
This is a record of the work, not a replacement transcript that claims to preserve every detail. Supporting material stays available for questions that need it.
Assemble context for the next task
Suppose the next task is to review the export validation plan. The agent needs the current constraints, relevant schema revisions, expected export behavior and the test evidence available so far.
It may not need every earlier discussion about naming or an abandoned database option. Those records can remain discoverable without occupying the immediate request.
The application should make the selection inspectable where practical. If a required source is inaccessible or excluded, the agent should report the limitation and request the appropriate information.
Verify the claim before moving forward
A summary says that recovery is ready. The source record shows that the procedure was drafted but not tested against the current schema. The reviewer should preserve that distinction and leave the condition unresolved.
A larger context window might allow both records to be included. It would not by itself decide which statement is authoritative or whether the proposed migration is safe to execute.
Resume from confirmed state
After testing, the team records what was tested, against which revisions and what remains open. A later assistant can begin with that current account and inspect the evidence it needs.
The process does not depend on one participant keeping the same chat open. It depends on recoverable records and deliberate selection of the next context.
Does a larger context window solve the problem?
A larger window can make more material available in one request. This can help with tasks that need broad coverage, such as comparing several complete specifications or reviewing a substantial section of a codebase.
Capacity and reliable use are different questions. The original Lost in the Middle research found that performance on its tested tasks changed with the position of relevant information in long inputs. That 2023 result is evidence about the studied models and tasks, not a measurement of every current model.
Evaluate the model and application you intend to use. For the migration example, check whether the answer preserves the export constraint when it appears in different places, when a conflicting proposal is present and when the supporting test record is missing.
More capacity also does not establish freshness, access or authority. A complete copy of yesterday's project still needs today's accepted changes. An accessible document can contain a proposal that nobody approved.
What does summarization preserve, and what can it lose?
A summary is a new representation of earlier material. It should have an explicit purpose: orienting a new participant, recording a decision or helping select the next sources. Those uses need different levels of detail.
For continuing work, preserve the conditions that would change a future decision. In the migration record, that includes the export availability requirement, the status of recovery testing and the revisions covered by a result.
A concise handover can identify the current plan and unresolved conditions, then link the supporting records. It should not turn a suggestion into an accepted instruction or a planned test into a completed result.
Review summaries when consequential decisions depend on them. Where possible, compare the summary's key statements with their sources. Keeping the longer record makes those checks possible without placing the full history into every request.
Our context engineering guide develops the broader process of choosing and organizing information for a task. The context window is one constraint within that process.
How does retrieval relate to the context window?
Retrieval selects information that may help answer a particular question. The selected material still needs to fit the request and remain understandable when separated from its original surroundings.
In the migration example, a search might find a matching test report but omit the paragraph describing its unsupported configuration. A shorter passage saves space while removing the condition that makes the result meaningful.
Choose passages and source references that preserve the relevant scope. Check what the application actually supplies after selection, formatting and any additional summarization. A good search result is useful only if the information reaching the model supports the intended task.
The RAG and AI memory guide explains retrieval as part of an application. Storing information, retrieving it and using it correctly remain separate responsibilities.
Working memory, persistent records and model training
The term memory can hide several different mechanisms. It is useful to ask exactly where the information lives and how it becomes available again.
Active context is the material used in the current model operation. Persistent application records can remain available between requests and sessions. Model training changes the model through a separate process.
Saving a project note does not automatically place it into every later request. Supplying a note as context also does not mean the model has been retrained on that note. A system can use persistent records effectively without changing model weights.
For a team, the important behavior is practical: can an authorized participant find the current decision, inspect the evidence and continue the work? That question is more useful than assuming that a product's memory label describes one particular implementation.
How should you test context continuity?
Start with a task that depends on a small number of explicit conditions. Record what a correct continuation would need to preserve. Then test realistic changes in the information available.
For the migration, useful cases include:
Resuming in a new session with the current project record.
A constraint present in the original transcript but absent from the summary.
An accepted decision alongside an older conflicting proposal.
A required source that cannot be read by the new participant.
A test result that applies to an earlier schema revision.
A request too large for the chosen model configuration.
Inspect the selected input as well as the answer. Define what the application should do when the request is too large, and test that behavior. Silent loss of an important condition should not be treated as successful continuation.
Use these checks to identify which part of the application needs attention when continuity breaks.
Where does Swarm fit?
Swarm Spaces preserve shared context, discussion, outputs, Runs and human decisions. The migration record can remain available as people and connected agents continue the project across tools.
For a question about earlier work, an agent can inspect eligible sources before selecting the material it needs. A supported context pack can be bounded to a token budget and retain source references and omission information. The connected client still determines what reaches its model.
That does not enlarge the underlying model's context window or guarantee that a constraint will be applied correctly. It provides a shared record that can be revisited, checked and selected for the next task.
A saved Space answer and any learning update are also deliberate operations with their own authority requirements. They should not be confused with a temporary summary or assumed to happen automatically whenever a conversation ends.
Common questions about context windows
Is a context window measured in words?
It is measured in tokens. Words, code and other material can consume different amounts of the budget. Use the selected model's token counting and usage information when available.
Does a full context window mean the chat is deleted?
No. Storage and active context are different concerns. The application's handling of history determines what is retained, summarized, selected or omitted. Check that behavior in the product being used.
Will a new chat remember the project?
That depends on what the application supplies to the new session. A saved project record can support continuity when it is retrieved and used, but its existence alone does not establish that it was included.
What should a team do first?
Identify the conditions that must survive a handover. Preserve them with their sources in a current project record, then test whether a new participant can recover and apply them. This exposes continuity problems more clearly than measuring conversation length alone.