Solution Patterns & Playbooks

Conversational Assistant with Memory

The Messages API is stateless by design — your application owns the conversation. Here's the reference design for session state, long-term memory, and keeping long conversations inside the context window.

Claude 3P 101 · Updated July 2026 · Unofficial guide

Every "chat with our assistant" product has to solve three separate memory problems: remembering the current conversation (session state), remembering the user across conversations (long-term memory), and forgetting gracefully when the conversation outgrows the context window. The Messages API deliberately solves none of them for you — each request carries the full message history, and the API remembers nothing between calls. That statelessness is a feature: it makes requests reproducible and lets you store conversation data wherever your governance requires. This pattern assigns each memory problem a documented mechanism.

Session state: your database, plus prompt caching

Store the running message array in your own session store keyed by conversation ID, append each user turn and assistant reply, and send the whole array every request. The cost problem this creates — re-sending a growing prefix every turn — is exactly what prompt caching solves: mark the conversation prefix with cache_control and repeated tokens bill as cache reads at 0.1x the base input price (5-minute default TTL, 1-hour available at a higher write cost). The docs describe an automatic mode — a single top-level cache_control that keeps moving the breakpoint forward as the conversation grows — which is the right default for chat. One availability nuance: automatic caching isn't supported on Amazon Bedrock or Google Vertex AI, which take explicit breakpoints only, so on those platforms your code places the markers itself. Prompt caching as such works on all four 3P platforms.

Long-term memory: the memory tool

For cross-conversation memory, Claude has a purpose-built client-side tool, generally available with no beta header on all Claude 4 and later models. Declared as {"type": "memory_20250818", "name": "memory"}, it lets Claude read and write files under a virtual /memories directory — your handler maps those paths onto real storage (a database, object storage, a per-user folder). When the tool is present, the API automatically injects a memory protocol that instructs Claude to check its memory directory before doing anything else, so remembered preferences and facts flow into new conversations without you engineering the injection.

from anthropic import AnthropicBedrockMantle

client = AnthropicBedrockMantle(aws_region="us-east-1")
msg = client.messages.create(
    model="anthropic.claude-sonnet-5", max_tokens=1024,
    tools=[{"type": "memory_20250818", "name": "memory"}],
    messages=history)  # your handler executes view/create/str_replace/... commands

Because the handler is yours, memory is as governable as any other data you store: scope it per user, encrypt it, expire it, audit it. Two documented obligations: your handler must reject any path outside /memories (path traversal like /memories/../../secrets.env must fail), and remember everything Claude writes there is model-generated content — review what enters long-term storage. The bash, text editor, and memory tools are GA on the Claude API, Claude Platform on AWS, Bedrock, and Vertex AI, and beta on Foundry.

Forgetting gracefully: context editing and compaction

Even with 1M-token context windows on most current models (200K on Haiku 4.5), long-running assistants eventually hit the wall — and cost rises with every resent token long before that. Two server-side beta mechanisms manage this without you rewriting history yourself:

Context editing (beta header context-management-2025-06-27) clears old tool results once the prompt crosses a token trigger — default 100,000 tokens, keeping the last 3 tool uses. The editing happens server-side before the prompt reaches Claude; your stored history stays complete and unmodified.

Compaction (beta header compact-2026-01-12) goes further: past a trigger (default 150,000 input tokens, minimum 50,000) the API summarizes older conversation into a compaction block. You append the response to your history as usual, and on the next request the API automatically drops everything before the compaction block. The docs recommend putting cache_control on compaction blocks and caching the system prompt separately so a new compaction doesn't invalidate your whole cache.

Platform note: compaction and context editing are beta across all five surfaces (Claude API, Claude Platform on AWS, Bedrock, Vertex AI, Foundry), so the trio in this pattern — caching + memory tool + compaction — runs on every platform, with Foundry's pieces mostly in beta. That makes this one of the most portable patterns in the playbook.

Where to go next

Assistants that act, not just chat, need the agentic loop pattern; ones that hand off to people need escalation to human. The feature matrix tracks beta status per platform.

Sources