Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Retain the smallest amount of history that is sufficient for the agent’s next decision. Keep the current request, system and developer instructions, active goals, constraints, unresolved commitments, and recent tool results in raw form. Compress older conversation into a structured summary, and store durable facts or documents outside the prompt for selective retrieval.
There is no reliable universal number of turns. A 10-message window can be enormous in a tool-heavy session, while 100 short messages may be cheap. Set retention with token budgets and task-quality measurements rather than an arbitrary message count.
The practical rule: preserve decisions, not transcripts
An AI agent should remember whatever can change the answer or the next action, and discard or summarize everything else. The minimum useful context normally includes:
- The latest user request and the immediately preceding exchange needed to interpret references such as “that file” or “the second option.”
- System and developer instructions, safety rules, output formats, and active tool permissions.
- The current objective, accepted decisions, constraints, definitions, assumptions, and unresolved questions.
- Recent tool calls and results that affect the next step, including identifiers, errors, pending operations, and state changes.
- Older facts only when they are still relevant, preferably retrieved from a durable store with provenance.
Raw history is valuable for exact wording and conversational references, but it becomes an expensive and noisy way to store everything. Keep a recent raw window, maintain a compact running summary, and retrieve older material on demand.
Why “keep the last N messages” is a weak policy
Messages have wildly different sizes. A single pasted log, source file, or tool response can consume more tokens than dozens of ordinary turns. Conversely, a long conversation may contain many short acknowledgements that add little information. A fixed turn count therefore provides neither a predictable cost nor a predictable level of recall.
Long context also does not guarantee perfect memory. Anthropic describes “context rot” this way: “as the number of tokens in the context window increases, the model’s ability to accurately recall information from that context decreases.” Irrelevant instructions, duplicated tool output, and competing versions of a decision can distract the model even when the technical limit has not been reached.
Use a turn count only as a secondary guardrail. The primary controls should be token counts, relevance, freshness, and the consequences of losing a detail.
Understand the context window before setting a budget
A context window covers the tokens supplied to the model and the tokens it generates; for some models it also includes reasoning tokens. OpenAI’s documentation gives gpt-4o-2024-08-06 as an example with a 128k-token total context window. A 2025 OpenAI session-memory cookbook cites GPT-5 limits of up to 272k input tokens and 128k output tokens. Those are model-specific documentation figures, not universal targets. Check the limits and billing rules for the exact deployed model.
Your usable input budget is smaller than the headline window because the request must leave room for output, tool calls, reasoning, system instructions, and unusually large results. A simple planning equation is:
usable_history = context_limit - system_and_developer - current_request - expected_output - tool_and_reasoning_reserve - safety_marginSet the safety margin before production traffic. Without it, a single large retrieval result or verbose tool error can push an otherwise valid request over the limit.
A four-layer retention architecture
Separating kinds of memory makes retention easier to control and audit.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →| Layer | Keep | Typical handling | Remove or relocate when |
|---|---|---|---|
| Active raw window | Latest turns, current references, immediate tool state | Send verbatim | A turn no longer affects the next action |
| Structured running summary | Goals, decisions, constraints, definitions, assumptions, open work, exact values that matter | Update after milestones or before the budget threshold | A newer decision supersedes it, or the project is closed |
| Retrievable long-term store | Durable preferences, project facts, documents, prior decisions, tool artifacts | Store outside the prompt; retrieve relevant passages with provenance | The user corrects, deletes, or expires the information |
| Ephemeral tool state | Short-lived IDs, intermediate results, pending operations, error context | Keep until the operation completes, then summarize the outcome | The operation is complete and its result is recorded |
This architecture avoids treating the chat transcript as a database. It also lets a user correct or delete durable memories without rewriting every historical turn.
How to set a retention policy step by step
- Define the task’s memory obligations. List the references the agent must resolve, facts it must quote exactly, decisions it must not reverse, and operations it must resume after a tool call. A coding agent may need file paths and test failures; a support agent may need the customer’s issue, promised follow-up, and account identifiers.
- Measure tokens before every model call. Count system instructions, the running summary, raw turns, retrieved passages, the new request, and any tool payload. Do not estimate from character count alone. Record the count and the remaining headroom.
- Reserve output and execution space. Allocate room for the expected answer, tool arguments and results, model reasoning where applicable, and a safety margin. If an agent commonly produces a 4,000-token answer, that capacity must not be consumed by history.
- Keep a relevance-ranked raw window. Preserve the latest exchanges that establish pronouns, references, and immediate state. Drop old acknowledgements, repeated instructions, and tool output whose final result is already summarized.
- Compact before the hard limit. When the budget approaches its threshold, summarize the oldest removable block and start the next call with the summary plus the necessary recent turns. Anthropic calls this compaction: summarize a conversation nearing the limit, then continue in a new context with that summary.
- Write a structured summary, not a vague recap. Use explicit fields for objective, decisions, constraints, definitions, entities, open questions, commitments, assumptions, timestamps, and source message identifiers. Preserve negations, quantities, version numbers, and quotations when wording affects the result.
- Retrieve older material selectively. Search the durable store for passages relevant to the current subtask. Include provenance and dates so the agent can distinguish an old plan from a current one. Do not inject an entire project archive merely because it is available.
- Validate the policy with regression conversations. Test references to early turns, corrections to previous decisions, interruptions during tool calls, contradictory instructions, and recovery after compaction. Compare quality, token cost, latency, and privacy behavior with a full-history baseline.
What belongs in a running summary
A useful summary is an operational record rather than a paragraph of prose. A format such as the following is easy for a model and an application to update:
Objective: migrate the service to the approved database version.
Constraints: no production downtime; deploy only during the maintenance window.
Decisions: use the blue-green plan; rollback target is version 4.2.
Definitions: “staging” means the eu-west test cluster.
Completed: backup verified at 2026-10-15 21:10 UTC.
Open questions: confirm the final connection-string owner.
Next action: run the staging migration and attach the test log.
Provenance: messages 184–191; tool run 7f3a.Do not silently turn uncertainty into fact. Mark assumptions, pending confirmations, and superseded decisions. If an exact quotation, identifier, or command matters, retain it verbatim rather than relying on a paraphrase.
When to summarize, retrieve, truncate, or start a new session
| Situation | Preferred action | Reason |
|---|---|---|
| Recent turns contain unresolved references or active tool state | Keep them raw | Paraphrasing can break “this,” “that result,” or an in-progress operation |
| Older turns contain settled decisions and constraints | Summarize them into structured fields | Preserves the decision while removing conversational noise |
| A document or project fact may be needed later but not now | Store and retrieve it when relevant | Avoids paying for irrelevant tokens on every call |
| The conversation nears the context threshold | Compact before the limit | Leaves room for the next request and tool results |
| The task is complete or a security boundary is reached | Start a new session | Prevents stale instructions and unnecessary sensitive data from carrying forward |
| Only the beginning and end fit after truncation | Do not rely on implicit truncation | Middle turns may contain the one constraint or correction the agent needs |
OpenAI’s Agents SDK sessions retain conversation history for a session while allowing an application to control how much history is retrieved without changing what is stored. Its memory guidance also distinguishes session history from separately consolidated memory and warns that an overlong conversation may be truncated to fit a model’s context, preserving the beginning and end. Make truncation an explicit, tested policy rather than an accidental fallback.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Choosing retention by task type
| Task | Raw history priority | Summary emphasis | Long-term retrieval |
|---|---|---|---|
| Short question and answer | Current request plus a few relevant turns | Usually unnecessary | Only if the user refers to a saved document or preference |
| Multi-step troubleshooting | Latest symptoms, commands, outputs, and failed attempts | Environment, hypotheses eliminated, next test | Known configuration and prior incidents |
| Software development | Current diff, errors, tool state, and requested behavior | Architecture decisions, constraints, accepted changes | Repository documentation, issue history, coding conventions |
| Long-running business workflow | Pending approvals and the latest transaction state | Commitments, owners, deadlines, exceptions | Policies, customer records, prior cases with access controls |
| Research or document analysis | Current question and cited passages | Claims, definitions, evidence gaps, conclusions | Source documents and indexed excerpts with provenance |
The more expensive an incorrect memory is, the more aggressively you should preserve provenance and exact values. A casual conversational preference can be summarized; a compliance requirement or deployment command should retain its source and version.
Retrieval is part of memory, not an excuse to load everything
Models can see only what the application supplies in the conversation. Retrieval tools can fetch relevant material from files, databases, or the web, but retrieval quality determines memory quality. Index durable material with useful metadata such as project, author, date, version, sensitivity, and supersession status. At retrieval time, filter by authorization and current task before ranking passages.
Return small, coherent passages rather than isolated sentences that lose qualifiers. Include the document title, section, timestamp, and a stable identifier. If two passages conflict, show both with their dates and ask the agent to follow the explicit precedence rule instead of blending them.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Measure whether the policy works
A retention policy is successful only if it improves the agent’s behavior at an acceptable cost. Track these dimensions separately:
- Task recall: whether the agent resolves references and recovers exact constraints from earlier turns.
- Reasoning precision: whether irrelevant history causes distraction, contradictory answers, or context rot.
- Cost and latency: input tokens, output tokens, retrieval calls, summarization calls, and end-to-end response time.
- Reliability: lost negations, numbers, provenance, unresolved work, or superseded decisions after compaction.
- Governance: whether users can inspect, correct, and delete durable memories and whether sensitive details stay out of long-term storage.
- Operational behavior: what happens at the budget threshold—compaction, retrieval, truncation, refusal, or a new session.
Build regression cases that deliberately mention an early decision, correct it later, interrupt a tool operation, and ask for an exact value after several compactions. Compare a full-history policy, a recency-only window, a summary policy, and a retrieval-based policy on the same cases.
Common failure modes and fixes
The agent forgets a “do not” instruction
Negations are easy to lose in aggressive summaries. Put prohibitions and safety constraints in a dedicated, high-priority summary field, preserve the original wording when it matters, and test corrections explicitly.
The agent cites an obsolete decision
Mark decisions with timestamps, owners, versions, and supersession status. Remove or clearly label old entries instead of appending a new decision with no relationship to the old one.
A tool result consumes the entire budget
Store the full artifact outside the prompt, retain the error or result needed for the next action, and retrieve only relevant excerpts. Impose maximum sizes on tool output and fail gracefully when a result is too large.
Summaries become longer every turn
Summarize by replacement, not by endlessly appending notes. Periodically merge duplicate fields, delete completed work, and move durable details to the external store.
Users cannot correct remembered information
Give durable memories an identity, source, timestamp, and deletion path. Treat a user correction as a state change that supersedes the old fact, not as another equally valid sentence in the transcript.
A sensible default policy
For a new agent, begin with the latest turns needed for references and tool state, a compact structured summary of the active task, and retrieval limited to the current objective. Count tokens before every call, compact at a conservative threshold below the model’s hard limit, and reserve explicit space for output and tools. Increase or decrease the raw window only after regression tests show a measurable effect on recall, accuracy, cost, latency, or privacy.
The right amount of history is therefore dynamic: enough to preserve the state of the work, never so much that irrelevant text competes with the next decision.
Recommended Free Tools
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
