Skip to lesson

AnthropicClaude Certified Architect – Foundations2026-105.1 Manage conversation context to preserve critical information across long interactions

Replay history on every stateless request

Completed by the knowledge check

Learning objective

Supply complete relevant conversation history and content blocks on subsequent stateless Messages API requests to preserve continuity.

Core idea

A conversation identifier in your application does not supply conversation history to the Messages API. Anthropic documents Messages as stateless: you send the full conversational history on subsequent requests. The model answers from the context you provide, so a missing earlier decision can look like forgetfulness even when the request completed successfully.

See 0.2 for basic history construction and 1.1.2 for matching tool calls to results. This lesson applies those foundations to long interactions: decide what continuity requires before reducing context, and preserve content structure rather than treating every turn as a transcript string.

The architectural question is what the next call actually contains. Saving a conversation in your database and sending only its final sentence are different operations. Storage preserves evidence for your application; request assembly makes that evidence available for inference.

How it works

Reconstruct the conversation from owned history

For POST /v1/messages, build the messages array from the conversation your application maintains. Preserve earlier role: "user" and role: "assistant" turns, then append the next input. Supply standing instructions through the top-level system field as needed; they are another part of request assembly, not something a previous API call installs for later calls.

After an inference, retain its content array as the assistant turn. Do not keep only the first text block because it happens to look like the visible answer. Content can include tool requests or other typed blocks needed to interpret the next exchange. The response envelope and a history message have different roles: replay the assistant content in a message, rather than inserting the entire response envelope into messages.

For a customer saying “Does that cover the second order too?”, the relevant history includes what “that” refers to, which orders were discussed, and what the agent actually committed to. A request containing only the question gives Claude no reliable basis for recovering those references. Adding a customer ID does not restore the missing dialogue.

Keep typed evidence and tool relationships intact

A user turn can contain an array of content blocks rather than a plain string. If an earlier decision depended on an uploaded image or document, preserve the supported content representation needed for that decision. A transcript that records only “customer attached a photo” does not supply the photo’s contents. Do not imply that the model can reconstruct omitted evidence from the attachment’s label.

For client tools, preserve the assistant tool_use and the corresponding user tool_result. The result’s tool_use_id identifies the call it answers. Anthropic requires the user result message to immediately follow the assistant tool-use message, with tool_result blocks first in that user’s content array. See 1.1.2 for the complete protocol treatment.

This ordering matters when introducing a context-reduction step. Do not insert a summary message between a pending tool request and its result. Do not remove the call while retaining an orphaned result, or retain the call while discarding its response. A shorter history still has to be a valid conversation.

Treat reduction as an explicit representation change

Anthropic’s context-engineering guidance describes compaction as summarizing a conversation near its context limit and continuing with compressed context. It also warns that aggressive compaction can lose critical details. Therefore, “send complete history” and “manage a finite context budget” are not competing permissions to omit arbitrary turns. Raw replay is the baseline; compression is a deliberate transformation with preservation requirements.

When your application introduces summaries, keep the information needed to continue the task available in the assembled request. Preserve exact case facts separately as taught in 5.1.2, issue associations as taught in 5.1.3, and recent exchanges that establish the active question. A summary saying “refund discussed” is not an adequate substitute for a still-active refund commitment.

The Claude Agent SDK owns an execution loop that manages context, including automatic compaction as the window approaches its limit. Its agent-loop documentation says compaction replaces earlier messages with a summary and may not preserve specific early instructions. Moving to that harness changes who manages history; it does not prove that every fact survives compression.

Key distinctions and trade-offs

Stored history versus supplied context: A complete archive helps you rebuild a request, but Claude uses what the request supplies. Investigate the assembled messages, not only the conversation record, when continuity fails.

Relevant history versus the newest message: Relevance follows the active task’s dependencies. Earlier commitments, evidence, corrections, and unresolved actions can remain relevant after many unrelated turns.

Typed content versus display text: The user interface can show a readable transcript while the application stores typed blocks. Reducing storage to display text loses information that the protocol and later reasoning may require.

Replay versus compaction: Raw replay preserves more original detail and consumes more context. Compaction frees space and risks omission. A deliberate summary plus independently preserved critical facts is a managed representation, not automatic memory.

Architecture / decision scenario

A support agent investigates a damaged item, reads an attachment, and checks a second order. Later the customer asks, “Can you confirm the refund and the delivery date?” The application’s archive contains all turns, but its request builder sends only this final sentence and the customer identifier.

Repair the builder before changing model settings. Supply the relevant conversation through messages, including the commitments that define the question and the typed evidence that supports them. Append assistant responses using their content arrays. Keep completed client-tool exchanges paired, and finish pending tool exchanges without inserting unrelated messages between call and result.

As the conversation grows, the team introduces compaction. It preserves an exact refund record and separately keyed delivery state outside the summary, then assembles those records with compressed background and recent turns. The summary still explains why the customer contacted support, while the records retain what the agent must confirm.

To diagnose another omission, inspect the assembled request: was the evidence absent, reduced to an inadequate paraphrase, or present but poorly organized? These are different failures. Only the last calls for the input-ordering techniques in 5.1.5.

Common exam traps

  • Assuming an application conversation ID makes Messages stateful.
  • Sending only the newest user message because the archive already contains history.
  • Saving assistant text while dropping other response content blocks.
  • Removing one half of a tool exchange during context reduction.
  • Treating automatic SDK compaction as exact preservation of early details.
  • Blaming retrieval or model quality before checking what the request supplied.

What to remember

Continuity is a property of request assembly. Supply the conversation and typed evidence needed for the next decision, preserve valid tool exchanges, and make compression an explicit change with critical information retained outside lossy summaries.

Knowledge check

References