A long-running Claude agent may appear to understand a project until it resumes after an interruption and acts on outdated assumptions. It remembers that a migration was proposed but not that the database administrator rejected the change. It knows a test was discussed but not whether the test actually passed. These are not cosmetic memory failures. They can cause repeated operations, contradictory conclusions and unauthorized state changes.
Claude Certified Architect – Foundations includes Context Management & Reliability as a distinct exam domain, weighted at 15 percent in the public blueprint. A sound architect treats context as a limited working surface and external state as the durable source of truth. The design goal is continuity without allowing a summary or conversational claim to replace verifiable evidence.
Context windows are a resource budget
A model’s context contains instructions, recent messages, tool results and selected documents. Every additional token competes with material that may be more important to the next decision. Feeding an entire document library into every turn can raise latency and cost while obscuring the relevant facts.
Useful context selection starts with the task. A billing-support agent may need a customer’s verified account number, the relevant policy and a recent transaction status. It probably does not need every support interaction in the organization’s history. A legal research agent may need full text for a small set of directly relevant clauses, but should avoid filling its context with all retrieved search hits before deciding which deserve closer reading.
Truncation creates another problem: details can disappear without an obvious error. If the missing detail established that an operation had already succeeded, a later retry may duplicate work. The application should therefore store durable facts, operation IDs and completed-tool results outside conversational context, then retrieve them deliberately when required.
Working memory is not the same as authority. A model’s recollection that a user approved a change should not override an approval record in the transaction system. Even when the recollection is correct, the durable system should decide whether that approval is still valid and which exact action it covers.
Summaries preserve meaning only when their limits are explicit
Summarization and compaction can make long tasks workable. A concise handoff may record the task objective, key decisions, open questions and the next permitted step. But summaries are lossy. They can omit uncertainty, merge conflicting evidence or turn a proposed plan into an apparent completed fact.
For example, a research assistant compares three policy versions and writes “the new policy requires supervisor approval.” If the source documents actually disagree, that compressed statement hides an important uncertainty. A better handoff records the policy version IDs, the section that supports the claim, the conflict and the fact that the determination remains unresolved.
Summaries should distinguish observations from inferences. “Tool returned HTTP 200 with transaction ID X” is an observation. “The customer received the refund” may be an inference requiring further reconciliation. A durable record should make that distinction readable by both software and human reviewers.
High-stakes state can be maintained in structured fields rather than prose alone. A workflow might save current_step, approved_action_id, source_document_version, completed_tool_calls and outstanding_checks. These are more reliable than expecting the model to reconstruct an execution history from a compressed conversation.
Retrieval solves freshness only when provenance is retained
A retrieval system can supply relevant knowledge on demand, but a returned passage is not automatically current or authoritative. The application needs source identity, publication or effective date, access policy and a way to resolve conflicts. Searching more documents may increase recall while also introducing stale copies and contradictory statements.
Consider an employee who asks which security training is mandatory. The system retrieves both a current policy and a retired policy that happens to match the search terms more closely. A semantic ranking score is not enough. The application should filter or mark superseded records using trusted metadata and, where appropriate, retrieve the current version from the policy owner.
An answer can include citations to support review, but source references themselves must point to authentic records. If a model invents a citation label, readers may be falsely reassured. A robust implementation validates source IDs against the retrieval output and records the exact passage used for a consequential recommendation.
In retrieval-augmented generation with Amazon Bedrock, indexing and retrieval likewise require freshness and access controls; a Claude architecture must enforce equivalent provenance and authorization through its own data services.
Recovery is a state transition, not a hopeful retry
A failure can happen before a tool runs, during execution, after execution but before the response reaches the caller, or during the model’s interpretation of the result. Recovery differs in each case. Simply repeating the last message can be unsafe when the tool may have changed external state.
For a state-changing operation, use a durable identifier. If an agent requests a refund and the network drops, the controller should query the transaction service with the original request ID rather than submit a new refund request. The system can then resume from the known result. A retry policy without idempotency or reconciliation is a duplication risk.
A read-only search may be retried more freely, but even read operations need budgets. Continually requesting the same unavailable document wastes resources and may make the agent appear stuck. Bound retries, vary strategies only when useful, and return an explicit limitation when evidence remains unavailable.
Cancellation requires attention as well. A user may cancel while an asynchronous subagent is still working. The application should not treat a conversational “stop” message as proof that all tools have ceased. It must propagate cancellation to the relevant workers, prevent future side effects where possible and record which operations were already completed.
Durable state should separate facts from generated memory
A reliable checkpoint might store task_id, input_version, approved_plan_version, completed_step_ids, pending_operations, source_ids and last_verified_result. A free-form conversation summary can accompany that record, but it should never be the only evidence that a privileged step was executed. If an agent says in its summary that “refund submitted,” the controller still needs the payment system’s operation receipt. If a source document was superseded since the checkpoint, its summary must be marked stale even if the text remains persuasive.
Consider a research agent interrupted after two of four sources finish. On resumption, the right state is partial research with two pending inputs, not a polished answer claiming comprehensive coverage. The coordinator can reuse the two verified artifacts, retry only the unfinished work and surface remaining uncertainty if a deadline expires. Independent IDs and source versions prevent it from accidentally counting the same result twice. The model may decide how to phrase the summary; application state decides which facts exist.
Test the design by changing a user’s authorization between pause and resume. An earlier instruction cannot grant permanent power to a later session. The workflow should recheck current permissions before sensitive actions and avoid silently discarding a previous human rejection. Recovery succeeds when the system returns to an auditable, correctly authorized state—not merely when the agent produces fluent text after a restart.
Multi-agent handoffs need a minimum sufficient record
A parent agent may delegate a research task to a worker with a smaller context. The worker’s return message should contain a bounded result and enough evidence for validation. It should not need to reproduce every intermediate thought, but it should identify the sources and limitations that affect the decision.
Imagine a procurement workflow with three workers: one checks vendor security, one checks cost, and one checks compatibility. If the security worker returns “acceptable” without naming the applicable policy version, the parent has no way to confirm whether that result covers the current requirements. If the cost worker returns a currency without a date, the recommendation may compare incompatible quotes.
A useful handoff contract records key outputs, provenance, what was checked, what was not checked and whether work is complete. The parent reconciles conflicting results rather than accepting each output as independent truth. If workers share the same flawed source, their agreement should not be mistaken for independent confirmation.
Persistent state also supports replay and diagnosis. The system should be able to identify which agent handled which assignment, which tool responses it used and what evidence the parent relied on in its final recommendation. This is particularly important for operations with external side effects.
Prompt caching and context reduction have different roles
Caching reusable prompt content can reduce repeated processing where supported, but it should not make stale business data authoritative. A cached instruction explaining output format is different from a cached account balance. The first may remain valid across many requests; the second needs appropriate freshness controls.
Context reduction similarly requires selection. Dropping low-value tool output can make the model more focused, but removing the section that establishes an exception can reverse the answer. The goal is not to minimize tokens blindly. It is to preserve the information needed to justify the next action with the least unnecessary exposure and repetition.
A useful architecture maintains several distinct stores: stable instructions, task state, source evidence and operational logs. Those stores serve different purposes and need different retention and access policies. A summary of a conversation should not become a substitute for a source document, a permission record or a successful transaction receipt.
Privacy belongs in this design. Passing an entire customer history to a subagent just because it is readily available can expose more personal information than the task requires. Context should be limited to the user’s actual request and the worker’s authorized responsibility.
Observability reveals where memory failed
When a system produces a wrong answer after many turns, it can be hard to know whether the cause was retrieval, prompt design, missing context or an unreliable tool. Logs and traces should make these possibilities distinguishable. Record which document versions were retrieved, when summaries were created, which tools ran and whether the application validated the results.
A regression test for long-running tasks should include interruptions. Start a workflow, complete several steps, simulate a restart and examine what the resumed process does. It should not invent completed work, repeat side effects or silently ignore previously recorded conflicts. If a summary omitted a crucial decision, the test should expose the defect before users encounter it.
Another useful test injects contradictory evidence late in the process. The system should update its understanding without erasing the reason it previously reached a different conclusion. Versioned evidence helps reviewers distinguish new information from an unexplained change of answer.
The final answer should disclose gaps when source evidence is incomplete. Concealing uncertainty may sound smooth, but it makes a system harder to trust and nearly impossible to audit.
Design a resilient CCA-F exercise
For an Anthropic CCA-F preparation project, build a research assistant that must assemble a recommendation from several versioned sources. Give it a memory budget and a clear retrieval API. Force a source conflict and make the assistant preserve both positions rather than select one without explanation. Interrupt the workflow after one worker completes but before another returns.
Then restart the application using only the stored task state and source IDs. Verify that completed work is recognized, that uncompleted work is not fabricated, and that the system can still trace its final conclusion to its inputs. Introduce a failed state-changing tool and require reconciliation before retrying. These exercises connect token management to actual reliability rather than treating the context window as a purely mathematical limit.
The architectural standard is simple: conversational state helps a model reason, while durable systems establish what happened and what is allowed to happen next. Context management becomes reliable when lost information does not silently turn into lost accountability.