Skip to lesson

MicrosoftMicrosoft Certified: Multi-Agent AI Solutions Expert2026-102.2 Design and implement agent memory, context management, and knowledge integration

Compact history without erasing business meaning

Completed by the knowledge check

Learning objective

Compact and truncate context without losing commitments, critical facts, or entity references

Core idea

Context reduction succeeds only if the next decision remains correct. A shorter input that forgets a promise, changes a condition, or merges two customer records is a failure even when it fits the model’s window. For an architect, the target is bounded context with preserved business meaning, not the smallest possible transcript.

Compaction summarizes or restructures retained information; truncation removes information. Both can reduce tokens, but neither automatically proves that every critical fact survives. Preserve exact commitments and entity identifiers in authoritative application state, then test the reduced context against that state.

Microsoft documents separate mechanisms for Agent Framework local history and Azure OpenAI Responses context. Agent Framework’s compaction framework is experimental. Its applicability is local in-memory history, so do not configure it and assume that it rewrites a service-managed Foundry conversation.

How it works

Identify which layer owns the history

A Foundry conversation can retain all its items while only a subset reaches inference when context exceeds the model’s supported size. The runtime-components page distinguishes truncation of model input from truncation of the stored conversation. An important fact in durable history is therefore not guaranteed to be visible to a later response.

For Agent Framework agents with local history, the compaction strategies operate on message groups. Tool calls and their corresponding results form atomic groups: dropping one side can produce invalid model input. System messages are preserved. In .NET, MessageIndex and MessageGroup expose the structured view, while strategies respect a MinimumPreserved floor for recent non-system groups.

The experimental .NET types require the documented MAAI001 warning suppression. Python’s compaction types are imported from agent_framework and are also described as experimental. State that status when selecting the mechanism; it is separate from the status of the agent hosting service.

Choose a strategy by what can be lost

A sliding window retains recent groups and discards earlier context. It works when recent turns contain all needed state, but it can remove a promise made at the start. A truncation strategy can provide a deterministic size reduction, but its selection rule must align with what the application can safely forget.

ToolResultCompactionStrategy targets verbose older tool interactions. In .NET it can replace call-and-result groups with a short trace naming the tools. In Python its examples preserve the newest groups through keep_last_tool_call_groups. Do not assume that a short tool trace retains every numeric result or source passage that a downstream decision needs.

For meaning-preserving summaries, .NET provides SummarizationCompactionStrategy; Python provides SummarizationStrategy. The documented default summary prompt preserves facts, decisions, preferences, and tool outcomes, and the strategy accepts a custom summarization prompt. Use that prompt to require unresolved obligations, conditions, exact entity IDs, and contradictions to remain explicit.

Python’s TokenBudgetComposedStrategy accepts token_budget, a tokenizer, and a sequence of strategies. A useful sequence reduces old tool payloads, summarizes older turns, and then applies a window if the budget still requires it. This is a policy choice: the final fallback can discard facts that summarization preserved, so inspect the final result rather than approving each stage independently.

CharacterEstimatorTokenizer estimates one token per four characters. Supply a model-specific tokenizer through TokenizerProtocol when exact accounting matters. A message-count threshold also differs from a token threshold because one tool result can be much larger than many short turns.

Distinguish request reduction from stored-history reduction

In .NET, a CompactionProvider registered on ChatClientBuilder through UseAIContextProviders(...) reduces in-flight messages and leaves the history stored by ChatHistoryProvider unchanged. Registering it through ChatClientAgentOptions.AIContextProviders instead runs it before history is stored, so synthetic summary messages can become part of persisted history. An IChatReducer on InMemoryChatHistoryProvider reduces the provider’s managed history.

The reducer trigger events are BeforeMessagesRetrieval, the default, and AfterMessageAdded. A compaction strategy can be adapted with AsChatReducer(). Choose the integration point based on whether you only need a smaller model request or also need to bound retained local history. Reducing a request does not fulfill a requirement to delete retained sensitive data.

.NET CompactionTriggers.TokensExceed(maxTokens) identifies when reduction starts. The strategy’s target identifies when it stops; without an explicit target, it defaults to the inverse of the trigger. Keep that distinction separate from the floor protecting recent groups. A floor that preserves too much can prevent the desired reduction.

Use the Responses mechanism for its own API path

Azure OpenAI documents client.responses.compact() and POST /openai/v1/responses/compact. They accept input items or previous_response_id and return compacted output for the next request’s input. This is a Responses API mechanism, not the Agent Framework reducer.

Server-side compaction on responses.create() uses context_management with type: "compaction" and compact_threshold. The documented flow emits an encrypted, opaque compaction item and supports store=False. With explicit input-array chaining, retain that item in subsequent input; with previous_response_id, carry the response ID and send the next user message. The page advises against manual pruning in the ID-chaining path.

Do not treat an opaque compaction item as a human-readable audit summary. Maintain a separate application record for commitments or source facts that must be inspectable. The API preserves continuation state, while your record supports verification and correction.

Key distinctions and trade-offs

Truncation is cheap and predictable but can remove decisive context. Summarization spends another model call and can introduce omissions or reinterpretations. Tool-result reduction often reclaims substantial space, but exact evidence may need to remain available elsewhere.

Preserve a commitment as structured data: who owns it, what action is promised, which entity it concerns, what condition applies, and whether it is complete. Preserve critical facts with source references. Keep contradictions as unresolved alternatives rather than summarizing them into one confident statement. These are application invariants, not automatic guarantees of a compaction strategy.

Test fidelity using questions that depend on early turns and ambiguous entities. Verify the final rendered context and the resulting answer. A low token count alone is not an acceptance criterion.

Architecture / decision scenario

A purchasing assistant handles two machines with similar names. Early in the conversation it promises to reserve machine A only after finance approves, while later tool results describe machine B’s inventory. Repeated inventory output pushes local history toward an application budget of 16,000 tokens.

Use a local-history compaction pipeline that reduces old tool groups, summarizes earlier interaction, and preserves recent groups. Its custom summary prompt requires exact machine IDs, the conditional reservation promise, approval status, and the source of each inventory fact. The application retains those values in the purchase record and checks the summary before using it.

If the summary says “reserve the machine” without an ID or drops “after finance approves,” reject it and rebuild from the authoritative record. If no valid reduction fits, narrow or pause the task rather than silently removing the condition. Test the next response by asking whether a reservation can proceed: it must identify machine A and the missing approval.

For the Azure OpenAI Responses deployment, use the documented compaction endpoint or server-side settings instead of attaching a local Framework strategy to service-managed history. Preserve the same external purchase record so opaque continuation state does not become the only evidence of the promise.

Common exam traps

  • Assuming durable history means all items remain model-visible.
  • Applying a local reducer to service-managed conversation history.
  • Removing a tool call without its corresponding result.
  • Treating a tool-name summary as complete factual evidence.
  • Confusing reduced request context with deleted stored history.
  • Approving compaction solely because the token count decreased.

What to remember

Select compaction at the layer that owns the context. Preserve message-group validity, exact entity references, and unresolved commitments. Validate the final reduced input against authoritative facts; neither a summary nor an opaque compaction item is a substitute for inspectable business state.

Knowledge check

References