An AI agent can make a sound decision in one step and a poor decision ten steps later because the evidence behind the earlier decision has been summarized away, contradicted by a newer record, or confused with a user instruction.<\/p>\n
This is a context-management problem, not necessarily a failure of reasoning capability. A reliable architecture must decide what belongs in the model’s working context, what needs to live in an external system of record, and how to preserve enough provenance for a later action to be audited.<\/p>\n
The context management and reliability domain of Anthropic CCAR-F<\/a> asks for this kind of design judgment. A large context window helps an agent consider more material, but it does not turn conversation history into a secure database. Context also carries cost and retrieval-quality trade-offs. More text can distract the model, duplicate contradictory instructions, or make the most relevant evidence difficult to find.<\/p>\n Consider an operations assistant investigating an incident across several services. It reads logs, infrastructure changes, customer tickets, and status updates while coordinating with an engineer. The investigation might last hours and require multiple conversations. The design must preserve what has been verified, which hypotheses were discarded, who approved a change, and what remains unresolved\u2014even if the active model context is reset.<\/p>\n The model’s context window holds the material available for the current request: instructions, conversation, tool descriptions, returned data, and any other included content. It is useful for synthesis, but it is not authoritative simply because something appeared there. A server can return a cached incident status, and the model may keep referring to it after the source system has changed. An old statement in the conversation cannot override a newer verified deployment record.<\/p>\n Identify the systems that own each fact. A monitoring platform owns metric timestamps, a deployment service owns release identifiers, a ticketing system owns the incident record, and an access-management service owns approval status. Claude can connect these facts into a working hypothesis, but the fact itself should remain traceable to the service that produced it.<\/p>\n Separate three kinds of context: instructions that define the assistant’s task, evidence that describes the world, and working notes that record tentative reasoning or a plan. They have different levels of authority. A suspicious string inside a log line cannot change application policy. A tentative hypothesis should not become a confirmed root cause simply because it has appeared in several successive summaries.<\/p>\n This separation also simplifies recovery. If an interrupted agent session restarts, it can fetch the latest incident state and the known evidence references rather than relying on a copied paragraph whose timestamp or origin is no longer clear.<\/p>\n Retrieval works best when guided by a specific information need. An incident responder asking \u201cWas the error rate already elevated before the rollout?\u201d needs a time-bounded metric comparison and the deployment timestamp. Dumping months of logs and every related ticket into the prompt raises cost without necessarily improving the answer.<\/p>\n Make retrieval queries explicit about entity identity, environment, time range, and data classification. If a service has similarly named staging and production deployments, the system should not combine their logs because a search result ranked both highly. A retrieved record needs a stable source identifier, observation time, and sufficient context to interpret it. A title without a timestamp may be unsuitable for an incident decision.<\/p>\n Chunking and summarization should preserve meaning. Splitting a technical document in the middle of a precondition can turn an accurate rule into a misleading fragment. For runbooks, retain procedure boundaries and link to the full authoritative version. For logs, preserve ordering and time zones. For support records, separate customer claims from a system-generated status.<\/p>\n If a retrieval step returns no records, ask whether that means the facts are absent or the search failed. An authorization denial, rate limit, or index outage must be reported differently from a confirmed empty result. Designing those states upstream prevents the model from building a confident conclusion on a false negative.<\/p>\n Long-running conversations eventually need a shorter working representation. Claude context windows<\/a> have finite capacity, so compaction can summarize earlier dialogue without resending every prior token. A summary is operational context, not a trustworthy replacement for source documents or durable approvals.<\/p>\n An incident summary should retain the incident ID, affected services, verified timeline, current mitigation state, evidence references, decisions, approvals, and unresolved questions. It should label hypotheses as hypotheses and identify which claims come from tool results. A generic phrase such as \u201cthe network team believes the issue is resolved\u201d loses the test that established resolution and the person or service responsible for confirming it.<\/p>\n Define a summary contract for the workflow. At a minimum, it might contain verified facts, open questions, completed steps, pending actions, and references to the authoritative sources. Include the time the snapshot was taken. If a crucial fact cannot be recovered from the source system, keep it as a durable artifact rather than letting a compression process paraphrase it until the original meaning is lost.<\/p>\n Compaction is also a natural checkpoint for reevaluating whether the agent should continue. A case that has exhausted its allowed investigation budget should escalate with its evidence, not restart a tool-use loop because older failed attempts were removed from the active context.<\/p>\n New evidence can invalidate an earlier hypothesis. For example, an agent first associates latency with a deployment because the timestamps are close. Later it discovers a network incident that began before the deployment. The correct action is to update the working hypothesis while retaining enough context to explain why the assessment changed.<\/p>\n Source priority should be based on relevance and authority, not whichever document was retrieved most recently. A fresh unsigned comment may be less authoritative than a validated production metric. Conversely, an old runbook can be wrong when a service has migrated to a different architecture. Use timestamps, ownership, confidence labels, and direct verification steps to resolve disputes.<\/p>\n An application can implement a simple evidence ledger: claim identifier, source ID, timestamp, claim text or normalized value, verification status, and the decisions that depend on it. This ledger does not need to be a complex knowledge graph. Its purpose is to make dependencies visible. If a source is invalidated, the team can identify recommendations that relied on that source.<\/p>\n Treat model-generated summaries as derived data. Preserve the original source reference and record when the summary was produced. A later reviewer must be able to follow the chain from a decision to the original log, ticket, or measurement without trusting the assistant’s memory alone.<\/p>\n Putting all available data into context is not just an efficiency issue; it may increase privacy and security risk. Production logs can contain addresses, credentials, or customer identifiers. Documents may include regulated material that some users can see but others cannot. A retrieval service should enforce permissions before returning content, and the application should minimize the fields exposed to the model.<\/p>\n For an incident involving one customer account, the model rarely needs an export of all customers. Retrieve the authorized case and a narrow set of related facts. Redact or tokenize identifiers when the exact value is not needed for the reasoning task. Store secure references to full records rather than repeating sensitive data in every subsequent message.<\/p>\n Treat retrieved text as untrusted input even when it comes from an internal source. A malicious log entry can contain instructions intended to alter agent behavior, and a compromised knowledge-base article can point to a hostile URL. Preserve the distinction between data being analyzed and instructions from the authorized user or application. Tool permissions must prevent text in a log from becoming a route to unrestricted file access or external exfiltration.<\/p>\nDistinguish working context from authoritative state<\/h2>\n
Retrieve the smallest evidence set that answers the question<\/h2>\n
Use compaction as a change of representation, not a loss of accountability<\/h2>\n
Handle conflicts when new information arrives<\/h2>\n
Keep sensitive data out of unnecessary context<\/h2>\n