CustomLabs
Reliability

Why does our agent forget its instructions halfway through a long task?

Answer

As the conversation grows, a naive truncation strategy drops the oldest messages to stay under the context window — and the oldest messages are exactly where the system prompt and the original task state usually live, so the agent keeps running with no memory of what it was actually supposed to do.

Also known as truncation drops system prompt, long-run instruction drift

Symptoms

What does this look like in production?

  • An agent behaves correctly for the first several steps of a long session, then starts ignoring constraints stated at the very start
  • The transcript, inspected at step 20, no longer contains the original system prompt or task specification
  • Behavior at step 1 and behavior at step 20 diverge on rules that were never explicitly rescinded mid-session
  • Runs crossing a certain length or turn count show a step change in error rate rather than a gradual decline
Root cause

Why does it happen?

A context window has a hard token ceiling, and once a long-running agent or conversation approaches it, something has to give. The simplest and most common strategy is to drop the oldest messages first — which is exactly the strategy that discards the system prompt and the initial task framing before it discards anything else, since those were written first. The agent doesn't "forget" in any dramatic sense; the instruction simply isn't in its input anymore, and it continues generating from whatever context remains, which increasingly looks like an ordinary continuation task rather than the constrained job it started as.

This is worse for agents than for simple chat, because an agent's task state — what it has already tried, what the goal actually is, what constraints apply — often lives nowhere except in that same truncatable transcript. Losing the early context doesn't just lose politeness instructions; it can lose the actual definition of the task.

Detect

How do you confirm it's this?

  • Log token count and specifically which messages get dropped at every truncation event, per run
  • Replay a long session and diff the agent's behavior at step 1 against step 20 on a rule stated only once, at the start
  • Check whether your system prompt and task state are stored in a truncatable position in the message array or pinned separately
  • Alert when any run's token usage crosses a defined share (e.g. 80%) of the context window, before truncation has to kick in
Fix

How do you fix it?

  1. Pin the system prompt and task state outside the truncatable window

    Store critical instructions and task state in a position that is never subject to the truncation strategy — re-injected on every call rather than living once in message history that can age out.

  2. Summarize and compact instead of truncating

    When the window fills, compress older turns into a summary that preserves the decisions and state that matter, rather than deleting them outright.

  3. Persist task state in a store the agent re-reads

    Keep the actual goal, constraints, and progress in an external structure (not just conversation history) that gets re-read on every step, so it survives regardless of what happens to the transcript.

  4. Alert when a run crosses a set share of the context window

    Treat approaching the window limit as an operational signal worth watching, the same way you'd watch memory usage, rather than discovering it only once truncation has already silently dropped something.

Limits

What this doesn't cover

This explains instruction loss caused specifically by truncation — if a long run degrades for a different reason (accumulated wrong context reinforcing itself, as in compounding agent-loop failures, or a genuinely ambiguous task), context-window truncation may not be the actual cause even if the symptoms look similar.

Not sure if this is the one?

A Ship Audit runs this full checklist against your actual system and hands back a written, prioritized plan.

Book a Ship Audit

navigate select esc close