Writing Prompts That Survive Context Loss: Session Hygiene for Long Tasks

Long agentic sessions have a failure mode that short ones don't: the context window fills up, gets compacted or truncated, and the model loses the thread. The task doesn't fail because the model got something wrong, it fails because the information it needed quietly fell out of view. This is preventable, but only if you write and structure the session with that failure mode in mind from the start.

Here's how to work in a way that holds up even when context gets lost.

Why context loss happens

Every session has a finite window. As a task runs, files get read, commands get run, tool outputs stack up, old turns either get pushed out or summarized. Summarization is lossy by design: it keeps the gist and drops specifics. The specifics are usually the part you needed later the exact env var name, the edge case you flagged twenty turns ago, the reason you rejected an earlier approach.

The result is a model that sounds confident and coherent while quietly working from an incomplete picture. That's more dangerous than an obvious failure, because nothing looks wrong.

Put state in the file system, not in the conversation

The single highest-leverage habit: don't let critical information live only in chat history. Chat history is exactly what gets compacted. Files don't.

• Keep a running plan or task file (PLAN.md, TODO.md, whatever) that gets updated as work progresses, not just written once at the start.
• Log decisions and their reasoning where they'll persist a DECISIONS.md or comments in the code itself especially for anything non-obvious ("we're not using library X because it conflicts with Y").
• Treat the conversation as a scratchpad for this turn's reasoning, and the file system as the source of truth for anything that needs to survive.

If the model can re-derive the current state by reading a file instead of remembering the last fifty messages, context loss stops being fatal.

Write self-contained task descriptions

A prompt like "continue what we were doing" is only meaningful if "what we were doing" is still in context. Once it isn't, that instruction is empty.

Instead, write prompts that would make sense to someone or some model with zero memory of the conversation so far:

• State the goal concretely, not by reference ("implement retry logic for the payment webhook handler in webhooks/payment.py," not "do the thing we discussed").
• Include the constraints that matter, even if you already said them earlier. Repetition is cheap; a dropped constraint is not.
• If there's a reason something must be done a specific way, say the reason, not just the rule. "Don't touch legacy_auth.py" survives compaction as a bare instruction; "don't touch legacy_auth.py it's still used by the old mobile clients" survives as a reason, which is more likely to generalize correctly if the situation shifts slightly.

Checkpoint explicitly

Rather than letting a long task run as one continuous stream, build in natural stopping points where you and the model confirm state together:

• After a meaningful chunk of work, ask for a short summary of what's been done, what's left, and any open questions. This does two things: it catches drift early, and it produces a compact artifact that's cheaper to keep in context than the raw history that produced it.
• Treat these summaries as checkpoints you could hand to a fresh session and get the same outcome. If a summary wouldn't be enough to resume the task cold, it's missing something.

Keep tasks small enough to fit

The most reliable fix for context loss is not needing that much context in the first place. A task that fits comfortably in one focused session doesn't have this problem.

• Break large tasks into stages with clear boundaries (schema migration, then endpoint updates, then client changes not "migrate everything").
• End a session, or start a fresh one, at natural boundaries rather than pushing one session to cover an entire multi-day project.
• If a task keeps needing "as I mentioned before" callbacks, that's a signal it's grown past what one session should hold time to checkpoint and possibly split.

Front-load the constraints that must never be dropped

Not all information is equally fragile. Instructions near the very start or the very end of a long session tend to survive better than ones buried in the middle. Use that:

• State hard constraints (don't touch this file, always run tests before finishing, never commit directly to main) early, and consider restating them at natural checkpoints.
• If something is truly non-negotiable, put it somewhere structural a project-level instructions file the model reads automatically rather than relying on it surviving in conversational memory at all.

The underlying principle

Context loss isn't really a memory problem to route around. It's a signal that important information was living somewhere fragile. The fix in every case above is the same move: push anything that matters out of the conversation and into something durable: a file, a structural constraint, an explicit checkpoint so that losing the chat history doesn't mean losing the task.

Write every long-task prompt as if the next message might arrive with no memory of this one. Often, it will.