DEV Community

Nick
Nick

Posted on

Solving agent system prompt drift in long sessions — a 300-token fix

The problem

If you've run any LLM agent for 30+ minutes, you've seen this: the agent follows its system prompt perfectly at the start, then gradually drifts. An hour in — it acts like the prompt never existed.

This happens with every model, every framework, every agent. It's not a bug — it's how attention works in transformers. The system prompt is tokens at the beginning of context. As context grows, those tokens
lose weight. 1,000 prompt tokens out of 2,000 total = 50% attention. 1,000 out of 80,000 = ~1%.

What doesn't work well

  • Repeating the prompt every N messages — eats context window (2,000+ tokens each time), and passive re-reading is weaker than active generation
  • Restarting the session — kills accumulated context, unacceptable for agents mid-task
  • Summarization / memory layers — help with information recall, but don't restore attention to instructions and rules

What works: SCAN

Make the model generate tokens semantically linked to its instructions. Not re-read them — generate new ones by answering questions about them. Generation creates ~20 tokens that actively link instructions
to the current task. Prompt repetition inserts 2,000+ tokens the model passively skims.

How it works

  1. Markers — questions at the end of each section in the system prompt:

[Section: data handling rules]
...your rules here...
@@SCAN_1: What data will this task affect? What if state is stale?

[Section: error handling]
...your rules here...
@@SCAN_2: What's the most likely failure mode for this task?

Markers at the end — to answer the question, the model must read the section first.

  1. Trigger — before a task, the agent answers its markers:

SCAN_1: Task affects session state. If stale — double charge.
SCAN_2: Timeout on external API without retry logic.

1-2 sentences per marker. ~300 tokens total vs 2,000+ for prompt repetition.

  1. Post-task check:

CHECK: session reset ✓, error codes ✓
MISSED: didn't verify concurrent requests — acceptable, single-threaded task

  1. Levels — FULL (~300 tokens, all markers) for critical tasks. MINI (~120 tokens, key markers) for medium. ANCHOR (~20 tokens, one line) between subtasks. SKIP for trivial ops.

Key constraint: SCAN answers must be in the model's output, not in internal thinking/reasoning. Token generation in output is what restores attention.

Multi-agent systems

Each agent in a pipeline runs SCAN independently and returns CHECK/MISSED to the orchestrator. Without this, a sub-agent loses all instruction context by the time it finishes. The orchestrator sees what was
verified across the entire chain.

What this addresses beyond drift

  • Prompt injection defense — safety instructions with maintained attention weight can't be outweighed by attacker tokens
  • Tool calling accuracy — API schemas decay like everything else, a marker keeps them alive
  • Multi-agent coordination — CHECK/MISSED creates visibility into what each agent actually verified

My experience

I use this daily with 11 agents, 100K+ context, 7 markers. Cost is under 0.5% of total tokens. Without SCAN — agents reliably lose critical rules by mid-session. With SCAN — stable across entire session
length.

I'm not selling anything — the method is open, adapt it however you want. If you try it, I'd love to hear what works and what doesn't.

Full writeup with detailed technical explanation, multi-agent propagation protocol, and complete prompt templates: [https://gist.github.com/sigalovskinick/c6c88f235dc85be9ae40c4737538e8c6]

Top comments (0)