Part 5 · Beyond the Prompt

Prompt Engineering · ~7 min

When the Prompt Fades

A rule placed perfectly at the start still loses its grip as the session runs long. The fix isn't a louder system prompt — it's a reminder injected at the moment it's needed.

Why this, for you: everything so far assumed the prompt is read once and holds. Over a long agent run it doesn't. Instructions fade — even while still present in context. This lesson hands you the lever for that: stop relying on a static prompt to carry a rule across a hundred turns, and re-inject it on the event that makes it relevant.

Static system prompts lose effectiveness over extended sessions. The model progressively deprioritises initial instructions as conversation history grows — even when those instructions remain present in context (Bui, 2025). The rule didn't leave; its grip did.

1 Fade-out is not compression

This is distinct from context being summarised away. An instruction can survive compaction and still fail to influence behaviour because it occupies a low-attention region of the context — the same lost-in-the-middle trough from Lesson 3, now widening as history accumulates around the prompt.

Top-and-tail (Lesson 3) places a rule well once. Fade-out is what happens when "once" was a hundred turns ago. The prompt is still there; the attention isn't.

2 Event detectors, not a schedule

The fix is not to repeat every rule continuously — that just refills the context and recreates the problem. Instead, event detectors watch for conditions that warrant a targeted re-injection (Bui, 2025):

Each detector fires a reminder at the next decision point. The trigger is the event, not the clock — so the guidance arrives exactly when it's relevant and nowhere else.

3 Escalate, and inject as the user

A single misstep shouldn't get the full hammer. Guardrail counters track violation frequency and raise severity:

CountSeverityTone
1AdvisorySuggest an alternative approach
2–3WarningState the constraint explicitly
4+MandatoryRequire compliance, block progress

And the placement matters: inject reminders as user messages, not system-prompt additions. User messages sit in recent conversation history and stay in the attention window more reliably — and an explicit user command can still override the reminder when appropriate.

# a reminder fires only when the detector trips: if tool_failure_count >= THRESHOLD: inject(role="user", "You've called {tool} {n}× without success. Stop retrying; review what you know and try another approach.")

When reminders make it worse

Reminders earn their keep on long, safety-critical runs — and cost more than they return elsewhere. A badly tuned threshold fires on normal retries. Accumulated injections consume tokens and can themselves land in the low-attention middle, recreating the fade they fight. And if a template drifts from the system prompt, the injected message contradicts baseline instructions. Design reminders as additive safety: if a detector crashes, the agent runs on its baseline prompt unharmed.

↪ Your win: refresh the rule on the event

Retrieval practice — recall, don't peek

Question 1Instruction fade-out means a rule loses influence even though it…

Question 2Event-driven reminders fire based on…

Question 3Guardrail counters exist so that the system can…

Question 4Reminders are injected as user messages because they then…

Question 5 · spaced recall from Lesson 9Pointing the agent at an existing type or test instead of describing it in prose mainly avoids…

Ask me anything. Want to pick the two or three events worth a reminder in your agent, or set escalation thresholds that don't fire on normal retries? Next, the last content lesson: Where Prompting Ends — when a rule should stop being a reminder and become a hook the model can't overrule.
✎ Feedback