Context windows, context rot and better AI handoffs

You spend an hour shaping a proposal with an AI assistant. The scope is settled, the draft is nearly ready, and then it suggests an option you rejected earlier, or confidently fills in a price you never confirmed. Another reminder may help. Sometimes the better move is to preserve the work and start from a clean briefing. To choose well, separate three questions: what can fit into the model’s working context, what information the application actually supplies, and how reliably the model uses it. This explainer connects those ideas to an ordinary business task. The handoff examples are original and synthetic; they demonstrate a method without claiming a successful personal-account test.

Before you start

• An unfinished task with a clear intended deliverable and any source documents you are permitted to use.
• A way to save or download the current draft and a handoff; no API setup or personal-account connection is required.
• A reviewer who can distinguish current facts, proposed decisions and approvals still required.

Tools: ChatGPT, Claude, Codex. Use an assistant approved by your organization. This text-based first version does not require new integrations; account features and data policies still apply.

The ideas, explained clearly

1. A context window is the working space for this response

   A context window is the model’s finite working space for a request. Text is measured in tokens: pieces that can be words, parts of words or punctuation. A page count is therefore a rough planning aid, not an exact token count. Languages, tables and document formatting can produce different counts. OpenAI’s documentation explains that the window must accommodate input and output, with reasoning tokens also counted for applicable models. The maximum response length can impose a separate limit. A large input allowance does not mean an equally large answer allowance. For business work, leave room for the deliverable you want. Asking for a detailed proposal after supplying an archive of old drafts may squeeze the available response budget. The diagram on this page uses 100 invented planning units: 20 for instructions, 35 for the current task, 25 for evidence and 20 reserved for the response and applicable reasoning. This is an illustration of competing demands, not a model specification, recommended allocation or utilization threshold. You do not need to count every token to ask a better question: which material actually helps produce the next result?

2. The chat you can scroll is not a receipt of what the model received

   Your visible conversation is an interface record. The model works with the context supplied for its current response. An application may assemble that context from recent messages, instructions, selected file passages, search results and summaries. Some older material may have been compressed or omitted. Conversely, instructions and tool information may consume space without appearing as ordinary chat bubbles. OpenAI’s token-counting guide documents inputs beyond a simple text string, including instructions and tool definitions. Treat a file attachment as a source to check, rather than proof that every page is being considered on every turn. Ask the assistant to identify the specific section supporting a consequential statement. If it cannot locate that section, provide the relevant passage or accessible file again. A path printed in a chat is also not proof that the file was saved. For our fictional proposal, a long discussion contains three pricing ideas. The current task needs the chosen approach, the saved draft and the unresolved price check. Sending the whole discussion may preserve the discarded options while obscuring the decision. A compact statement of current state can be more useful than another transcript dump.

3. Context rot is a quality problem; overflow is a capacity problem

   Context rot describes unreliable use of information as context becomes longer or more distracting. In its research report, Chroma evaluated 18 models and found nonuniform performance across input lengths and task conditions. Those experiments do not establish a universal failure percentage for every model or business task. A model can miss an important condition even when the input fits its advertised window. Hard overflow is different: the request or requested generation exceeds a supported limit. Depending on the application, you may see an error, truncation or an automatic context-management response. A warning about capacity is stronger evidence of a limit than an assistant merely producing a poor answer. Repeated questions, revived rejected options and forgotten constraints are reasons to check the working context. They do not prove context rot. Ambiguous instructions, contradictory source documents, missing permissions or an ordinary reasoning error can look similar. In our proposal, inventing a current price could come from an obsolete quote or an unsupported guess. Start by asking which source and date support the figure. Correct the factual gap before deciding that a fresh thread will fix it. There is no evidence here for an automatic reset at 80 percent full.

4. Choose whether to continue, compact or start a new thread

   Continue in the same thread when the objective is stable, the relevant material is easy to locate and the assistant can accurately restate the current constraints. Ask for the next bounded result rather than restarting a healthy conversation out of habit. A short correction may be enough when one fact has changed. Use compaction when you need continuity through a long session and your product supports it. It reduces the context carried forward while retaining useful state. OpenAI documents compaction that carries an opaque machine-readable item; Anthropic describes summarizing important session content. These implementations are not interchangeable, and neither implies a universal command. Review important decisions against saved sources after compression. Start a new thread with a handoff when the objective changes substantially, the discussion is crowded with abandoned directions, or another person or agent needs to take over. The handoff is an inspectable briefing you provide deliberately. A fresh thread does not automatically inherit your files, access or approvals. Before leaving, preserve what the next worker will need. Choose by the state of the work and the product’s actual controls, not a made-up token cliff.

5. Save the work before you ask for a summary

   A beautiful handoff cannot restore a draft that exists only in an inaccessible session. Save the artifact first, then record where it is and what state it is in. If the assistant has file access, ask it to save through its available tools and confirm the file can be read back. If it only produces chat text, copy or download the result yourself. Record that manual step honestly instead of saying the agent saved it. In the synthetic example, the proposal draft is recorded at proposals/harbor-proposal-v3.md. That is an illustrative project-relative path, not a downloadable file created by this article. The draft uses the fixed-fee structure chosen in the decision note. Its pricing section remains marked NEEDS CURRENT QUOTE. Stakeholder approval is outstanding, and nothing has been sent. Also preserve work that would be expensive to repeat: a comparison table, source list or rejected approach with its reason. Keep temporary brainstorming out unless it explains a present constraint. Before closing the session, ask a practical question: if tomorrow’s assistant can open only these saved artifacts and the handoff, will it know what remains unfinished?

6. Write a handoff around state, evidence and the next decision

   A useful handoff says what the next worker must accomplish, what has already happened and what must remain true. Include the objective, deliverable, decisions with reasons, constraints, saved artifacts, verification performed, failures, unknowns and ordered next actions. Distinguish an approved decision from a suggestion. State who can resolve each blocker when known; leave ownership unknown when it is unknown. Evidence makes the briefing portable. Identify the file or source section behind an important claim, its version or date where available, and whether it was actually read. Preserve the exact relevant error when a failed attempt matters. For the fictional pricing request, the handoff says the latest quote was unavailable; it does not turn a previous estimate into a current price. A source reference helps the next agent verify the statement without replaying the entire conversation. Avoid vague instructions such as finish it as discussed. Also avoid a giant transcript disguised as a summary. Put the current source of truth first, explain any conflicting older document and make the next safe action specific. Our next action is to open the draft and decision note, then obtain current pricing through the approved route.

7. Restart with verification, then continue the unfinished work

   Give the new agent the handoff and access to the named artifacts. Ask it to check the objective, current files, governing instructions and unresolved blockers before editing. A project-relative path needs a project location; a document link needs the right account and permissions. If either is unavailable, the agent should report what it cannot inspect and continue only work that does not depend on that missing evidence. For the proposal, the receiving agent should confirm that version three exists and that the fixed-fee structure matches the recorded decision. It should keep the pricing placeholder until a current quote is available. It can improve wording around the approved scope while stakeholder approval remains pending, but a handoff saying approval needed is not permission to claim approval or send the proposal. Ask for a brief state check and the next action, rather than another long summary. This creates a chance to catch a mistaken handoff before it spreads. A sensible restart acknowledgment would distinguish the draft it actually opened from a price source it could not access. That is an example of the desired behavior, not a result we observed from a tested agent.

8. Keep reusable knowledge separate from this task’s handoff

   A handoff captures the present state of one piece of work. A skill captures a repeatable method, such as how to structure a proposal or review a supplier quote. Project instructions capture durable constraints; a decision log records choices and their reasons. Product memory features may retain selected information across conversations, but their scope and behavior depend on the product and settings. OpenAI documents projects that organize chats, files and instructions; that organization is not a promise that every item is supplied on every response. None of these is the same as training the model on your business. Supplying a handoff gives the next interaction information to use; it does not itself update model weights or guarantee permanent recall. Keep changing facts, such as current prices and pending approvals, in dated source records instead of freezing them into a reusable skill. Build checkpoints into normal work: after a decision, save the decision; after a draft, save the draft; before a transition, refresh the handoff. Anthropic describes structured notes outside the active context as one way to support longer work. Our practical adaptation is a small, reviewable project record that another worker can verify. The payoff to check is continuity of decisions and unfinished work, rather than a claim that the assistant can now remember everything.

Try it with a sample

Use this synthetic input to see the distinctions your output should preserve.

What a good result should preserve

A prompt you can adapt

Prepare a portable handoff for this unfinished task. Use only the conversation and artifacts you can actually inspect. Do not infer completion, approval, saved files or successful checks.

TASK / DELIVERABLE: [what we are making and for whom]
PROJECT LOCATION: [folder, workspace or document collection]
HANDOFF DESTINATION: [file path or request text output]
CURRENT SOURCE-OF-TRUTH ARTIFACTS: [paths/links, versions and dates if known]
NON-NEGOTIABLE CONSTRAINTS: [scope, factual boundaries, approvals and permitted actions]

First preserve work that would otherwise be lost. If saving is authorized and tools are available, save the current draft and read it back. Report the exact path and result. If you cannot save or verify it, say so and provide the text for me to save. Do not claim a successful write from a proposed filename.

Then create a handoff with:
1. Objective, deliverable and acceptance criteria.
2. Current state: completed, in progress and not started; evidence for consequential claims.
3. Decisions already made, who made them if known, rationale and rejected alternatives that still matter.
4. Constraints and approvals; clearly separate authorized drafting from sending/publishing or other external actions.
5. Artifact/source manifest: exact path or link, purpose, current version/date, what you actually inspected and any access prerequisite. Identify conflicts and which source governs, or mark unresolved.
6. Verification actually performed and its results; do not call a proposal or source-only check a runtime success.
7. Failed attempts and relevant exact errors; distinguish failure from missing access and untested assumptions.
8. Unknowns and blockers, with the person or source needed to resolve each when known.
9. Ordered next actions that preserve completed work and begin with checking the relevant files and current state.
10. A short restart prompt telling the receiving agent what to open, verify and do next.

Keep the record sufficient for someone without this transcript. Put current decisions ahead of historical discussion. Label unknowns explicitly. Include only material needed to continue; do not copy secrets, credentials or unrelated personal data. If sources are inaccessible or contradictory, record the gap rather than smoothing it over.

Before finishing, check that the next agent could distinguish facts from assumptions, saved work from intended work, and permission from a pending approval. Return the handoff and state where it was actually saved, or that it remains text awaiting saving.

Check the result

• Can the receiving agent identify the objective and acceptance criteria without the old transcript?
• Are completed artifacts saved at accessible locations, with actual readback distinguished from a proposed path?
• Are current decisions, constraints and approval boundaries explicit?
• Does each consequential claim point to evidence, with stale sources and unknown prices kept visible?
• Are failed attempts and unknown error text recorded honestly, rather than converted to success?
• Does the restart begin by verifying files and current state, then continue unfinished authorized work?

What to keep in mind

This is a researched explainer with an original synthetic proposal example, not a benchmark or a tested recovery of a real session. Context behavior, capacity indicators, compaction, memory and file access vary by model, application and configuration. The illustrative budget is not a measured token count. A fresh thread and a handoff can both omit essential information; consequential facts still require source checks.

Sources & review notes

These sources support the tool context and review principles. The workflow, prompt, and synthetic example are original editorial material.

• OpenAI: Conversation state

  Defines context and output limits; applicable reasoning tokens also count. API guidance does not establish a universal chat-app behavior.

• OpenAI: Key concepts

  Explains tokens as text units that can include word fragments and punctuation.

• OpenAI: Counting tokens

  Shows counting complete structured inputs including instructions and tools, beyond a visible message string.

• Chroma: Context Rot

  Primary research across 18 models and several tasks; findings are not an exhaustive evaluation of business work or a universal cutoff.

• OpenAI: Compaction

  Describes reduced carried context and opaque compaction items; not a human handoff or a universal product command.

• Anthropic: Effective context engineering for AI agents

  Describes summarization-based compaction and persistent structured notes; aggressive reduction can lose important context.

• OpenAI: Projects and chats

  Documents organizing related chats, files and instructions; specific inheritance and access depend on product behavior.

• OpenAI: Build skills

  Describes reusable instruction bundles; a skill is conceptually distinct from one task’s changing status.