An agent gets an identity file — 800 tokens describing its values, temperament, and constraints. Injected at session start, position 0. The system prompt says to embody it. The agent does.
Twenty turns later, there are 20,000 tokens of dialogue between position 0 and where the model is generating. At turn 50, 50,000 tokens. The identity file is still there — never truncated, never summarized. Present in every forward pass. Nobody would say it is missing.
The question nobody asks: does it matter the same way at turn 50 as it did at turn 1?
Why position is not neutral
Transformer attention is not uniform across distance. In practice, models exhibit recency bias — recent tokens carry higher effective weight than distant ones during autoregressive generation, especially at long sequence lengths. The "lost in the middle" problem is documented in retrieval settings: information in the middle of a long context is underweighted relative to the beginning and end.
An identity file injected at position 0 starts privileged. As the conversation grows, it moves toward the middle of an ever-longer sequence. By a 50,000-token session, the agent's values file competes against everything that came after it — task context, tool outputs, recent conversation, injected documents — for the attention that produces behavior.
The file says: be direct, protect memory, resist avoidable compression. Whether those constraints actually shape what the agent produces at token 51,000 is an empirical question, not a design guarantee.
What measurement shows
Two signals track this degradation in practice.
Ghost lexicon decay measures whether vocabulary from the identity file — the specific terms that define the agent's character — survives into late-session outputs. When the agent at turn 50 no longer uses the words it used at turn 5, something has shifted. The terms are present in context but are no longer driving generation. The vocabulary ghost is still there; the influence is not.
CCS (Constraint Consistency Score) measures output similarity between early and late session responses to equivalent prompts. A well-anchored agent produces outputs with high cosine similarity across session depth. One that has drifted produces outputs that share less with early-session behavior — measurably, reproducibly, across agents and sessions.
Both signals degrade with context depth. Compaction events make it worse: when a summarization pass compresses early context, the presence guarantee disappears entirely, and both signals drop sharply at the compaction boundary.
The methodology and reference implementation are at doi.org/10.5281/zenodo.19313733.
What to do about it
The naive fix is periodic re-injection: append the identity file to context every N turns. This works, roughly. The problems are precision (you re-inject on schedule, not when the agent actually drifted) and waste (you re-inject even when nothing changed, consuming context budget on turns where the identity file was still effective).
The better fix is event-driven re-injection triggered by compaction events. When the runtime compresses early context, the identity file should be re-injected at that boundary — because that is the exact moment when its presence guarantee broke. Some SDKs expose compaction hooks; most do not yet.
The deepest fix is architectural: critical behavioral constraints should live in non-summarizable anchors re-injected on every turn rather than sitting in rolling context. The overhead is roughly 800 tokens per turn on a 50,000-token window — about 1.6%. For long-running agents where behavioral consistency matters operationally, that is cheap insurance.
The honest position
Identity files work best at the start of a session. That is expected behavior of the architecture, not a failure. Designing as if position 0 means uniform influence throughout a multi-hour session is the failure.
Whether a persistent agent's identity file shapes cognition or just claims to is a question that depends on what is in the active window when it matters. For sessions long enough for this to matter operationally, the answer should be measured, not assumed.
The tools to measure it exist. The question is whether the teams building long-running agents are using them.