Trace forgotten facts to context removal

Learning objective

Diagnose sliding-window amnesia caused by context truncation.

Core idea

For an architect investigating a long conversation, sliding-window amnesia means required information falls outside the history supplied to the model. The conversation can remain valid and the model can produce fluent output while a business constraint is no longer available. This is a context-selection failure, not evidence that the model’s training changed.

Prove the diagnosis by locating the missing fact in the source history and showing that the reduction policy excludes it from the failing request. A saved conversation, a session identifier, and the model-visible context are different objects. Persistence does not establish that every saved message reaches every model call.

See 2.2.4 for selecting compaction mechanisms. This lesson focuses on attributing a recall failure to truncation; see 3.2.4 when a surviving summary changes the meaning instead.

How it works

Establish the history owner first

Microsoft Agent Framework documents compaction for agents that manage their conversation history in memory. Its compaction framework is experimental in Python and .NET; .NET examples suppress MAAI001, and Python imports the strategy types from agent_framework.

The same page says these local strategies have no effect on service-managed history, including Foundry Agents and Responses API agents with store enabled. Identify the actual history owner before inspecting local window settings. A correct setting on an inactive provider cannot explain a service-side context decision.

Also confirm session continuity. Python creates an AgentSession with agent.create_session() and passes it to agent.run(..., session=session). session_id identifies the local session, while service_session_id can identify remote service history. Compare the applicable identifiers across the successful and failing turns. Creating an unrelated session can remove all earlier context without any sliding-window threshold being crossed.

Read the window’s unit of removal

In Python, SlidingWindowStrategy(keep_last_groups=20) retains the 20 most recent non-system groups. Its preserve_system default is True. In .NET, SlidingWindowCompactionStrategy operates on user turns; CompactionTriggers.TurnsExceed(4) is the documented example for retaining the last four turns. Its MinimumPreserved default is one recent non-system group.

Those are different units. A turn begins with a user message and includes the following assistant and tool-call groups until the next user message. One verbose turn can contain several groups. Do not convert 20 groups into a guarantee of 20 user turns, or interpret a turn threshold as a token limit.

Truncation can also be budget-driven. Python’s TruncationStrategy(max_n=..., compact_to=...) counts included messages unless a tokenizer is provided; with a tokenizer, it uses token count. A threshold that looks large might therefore mean messages rather than tokens. Record the installed strategy, its parameters, and its counting method with the failure evidence.

System-message preservation does not protect every earlier user constraint. A customer’s delivery restriction in a user message can disappear even though trusted instructions remain. Keep authoritative instructions separate from user facts, and do not promote untrusted user text into system instructions merely to escape the window.

Compare source, retained history, and actual input

Build a diagnostic fixture containing a stable entity identifier, a constraint introduced early, enough intervening turns to cross the configured window, and a later question requiring that constraint. Use a fact whose expected answer is explicit, such as a delivery address correction, rather than a subjective conversational preference.

Capture minimized evidence at three stages: the original record, the retained groups after reduction, and the messages sent to the model. Compare fact presence and group membership, not just total token counts. If the correction exists in the source but disappears immediately after reduction, the window explains the missing evidence.

Where the provider is registered (see 2.2.4) decides whether the original history survives. For a .NET history reducer, BeforeMessagesRetrieval is the default trigger event; AfterMessageAdded is the alternative. Inspect the history before the applicable event: if reduction changes the retained record, restoring a removed fact requires a separate authoritative source; if only in-flight context changes, the retained history can still supply it.

A provider registered through ChatClientAgentOptions.AIContextProviders does not engage during the tool-calling loop, according to the compaction documentation. Inspect the failing model call, not only the input at the start of the outer agent run. Provider placement is part of the diagnosis.

Use a controlled restoration to test causality

Repeat the failing request with the required fact restored from its authoritative source and the rest of the fixture held constant. If the answer becomes correct, that supports context omission as the cause. Also run a case with the window disabled or enlarged in an isolated test. Do not change the model, prompt, retrieval policy, and window together: the comparison would no longer identify the intervention that repaired the failure.

If the fact remains in the final model input but the response ignores it, investigate model use or conflicting instructions. If the fact exists only in a retrieval store and the recall step does not return it, investigate retrieval, as in 3.2.5. If the fact remains only as an inaccurate summary, investigate summary drift.

For a durable fix, preserve the record under the ownership design from 1.2.5 and reconstruct the required facts explicitly. Within a workflow, Python’s WorkflowContext.set_state() and get_state() expose state to downstream executors. They support explicit state transfer; they do not automatically inject every stored value into a model prompt or replace cross-session persistence.

Key distinctions and trade-offs

The following observations lead to different investigations:

Larger windows postpone loss but consume more context and do not make important facts durable. Explicit state and targeted reconstruction preserve business meaning more predictably, at the cost of maintaining a source of truth and selecting the facts needed for each role.

Architecture / decision scenario

A service assistant records that order A-417 must ship to a corrected address. After several diagnostic tool exchanges, it proposes the original address. The team suspects poor model recall.

The session identifiers match. The source history contains the correction, but Python’s SlidingWindowStrategy excludes its group after the configured cutoff. The final request includes the original address from a recent tool response and omits the correction. Restoring the verified correction repairs the fixture without changing the model.

The team retains the authoritative order record and passes the accepted address through workflow state to the shipping executor. It explicitly includes that address in the executor’s context. A regression fixture crosses the same window and verifies the shipping proposal against the record. The team preserves atomic tool-call groups rather than deleting isolated tool messages to make room. If the correction were already present in the final input, this diagnosis would be rejected and the team would investigate conflicting evidence instead.

Common exam traps

• Equating stored history with model-visible history.
• Treating groups, turns, messages, and tokens as interchangeable.
• Assuming preserved system messages preserve every user fact.
• Applying local compaction controls to service-managed history.
• Calling every wrong answer amnesia without inspecting input.
• Increasing the window without preserving authoritative business state.

What to remember

Find the fact, identify the history owner, and inspect the removal point. Prove truncation with a controlled restoration. Preserve required business facts explicitly rather than relying on their position in a rolling conversation.

Knowledge check

References

• Microsoft, Compaction
• Microsoft, Agent sessions
• Microsoft, Workflow state