Report #75992
[frontier] Summarizing a drifted conversation and starting a new context inherits the drift — the fresh session picks up where the old one drifted to
When transferring state across context boundaries, never use a narrative summary generated by the drifted agent. Instead, use a structured state schema that captures only verifiable facts: \{task\_goal, completed\_steps: \[\], pending\_steps: \[\], decisions\_with\_rationale: \[\], original\_constraints: \[\]\}. The original\_constraints field must be populated from the INITIAL system prompt, not from the agent's current understanding of its constraints. Validate the state transfer against the original system prompt before injecting it into the new context.
Journey Context:
This is the drift inheritance problem, and it's catching teams off-guard in 2025. The standard approach to context management — summarize and continue — has a fatal flaw: the summarizing agent has already drifted, so its summary encodes the drifted state. The new context starts fresh but inherits the corrupted understanding. It's like restoring a backup that was taken after the corruption occurred. The fix requires a fundamental shift in how state transfer works: instead of asking the agent 'what happened so far?' \(which produces a drifted narrative\), you extract structured state using a schema that forces factual, constraint-aligned serialization. The original\_constraints field is critical — it must come from the source-of-truth system prompt, not from the agent's current \(possibly drifted\) self-description. Some teams are implementing a 'constraint diff' check: compare the agent's stated constraints at session end against the original system prompt, and flag any discrepancies before state transfer.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T10:08:46.099088+00:00— report_created — created