Keep each concern in its own record

Learning objective

Maintain separately structured per-issue state such as order IDs, amounts, and resolution status for multi-concern sessions.

Core idea

Exact values are insufficient when their associations are lost. A record containing “USD 67.35, delayed, approved” can preserve every word and still mislead: which concern is delayed, which payment is approved, and which order owns the amount?

The exam guide requires structured issue data in a separate context layer for multi-issue sessions. Build one record per concern, with explicit links to the order and evidence it describes. This extends the exact case-facts technique in 5.1.2: that lesson preserves values; this lesson preserves their ownership and independently changing states.

The issue layer is application data. Anthropic’s structured note-taking pattern explains how persisted information can be pulled back into context, but it does not prescribe your issue schema. Define the schema to preserve the distinctions your support workflow needs, then include the relevant records in the context supplied to Claude.

How it works

Separate the case, the issue, and the order

A case is the conversation-level container. An issue is a concern that requires its own investigation or resolution. An order is an entity the concern references. These are useful application distinctions, not Claude object types.

For a customer reporting a damaged item and a delayed shipment, create independent issue records rather than a single changing status. Give each issue its order identifier, concern type, relevant monetary values, and resolution status. Keep shared customer information at case level so it does not obscure the issue-specific facts.

Do not assume one order always means one issue. A customer can report both a damaged product and an incorrect charge on the same order. An application-defined issue_id can distinguish those concerns while order_id links each to the shared order. An order-only key would merge their states even though their remedies differ.

The following example shows the distinctions a support context must preserve:

All identifiers and values are illustrative application data. The repeated order identifier is deliberate: the damaged item and disputed charge remain separate issues. The shipping fee is a paid amount, not an automatically approved refund.

Update the issue the evidence addresses

When an order lookup or payment result arrives, associate it with the issue it answers. Update the fields supported by that result. A delivery investigation becoming resolved does not close the damaged-item issue. A refund submission does not settle an unrelated charge dispute.

This relationship should be visible in the content your tool returns. In a direct Messages loop, the tool_result answers a particular tool_use through tool_use_id; inside its content, your application record identifies the order and issue. The protocol identifier connects call to result, while the application identifiers connect evidence to the right case state. They solve different problems.

See 1.1.2 for protocol pairing and 5.1.4 for reducing result volume. Here, the important consequence is that trimming must retain the identifiers needed to attach a result to its concern. A concise result that preserves the amount but drops its order can be worse than a larger, well-attributed one.

If a response addresses only an order-level fact, such as its delivery date, update that fact where the schema represents it. Do not infer an issue’s resolution status from the order fact unless the result actually supports that transition. “Delivered” does not mean “damage complaint resolved.”

Render issue state independently of narrative history

Persist the issue collection outside the material replaced by progressive summaries. When the customer changes topic, keep the earlier unresolved entries. When they return to “the other charge,” the supplied issue layer can identify which disputes remain open even if the narrative has been compressed.

Render each concern under an explicit heading containing its issue and order identifiers. Include its relevant values and status in the same section. This makes association visible instead of asking Claude to infer it from the order in which facts happen to appear. See 5.1.5 for arranging the whole aggregated input.

For direct Messages requests, include this rendered context through messages. For an Agent SDK workflow, reuse the persisted-context injection approach in 5.1.2 rather than teaching another hook implementation here. The schema remains your responsibility whichever harness supplies the context.

Give the active question enough context to resolve its references. If two refund-related issues remain open, “Has that been completed?” is ambiguous even with perfect records. Preserve both states and ask which concern the customer means rather than choosing the most recently updated amount without evidence.

Key distinctions and trade-offs

Flat case facts versus issue records: A flat block works for one unambiguous concern. Separate records become necessary when the same field name can have several owners or when concerns move through different states.

Order identity versus issue identity: An order can support several concerns. Order IDs preserve entity association; issue IDs preserve independent investigation and resolution.

Order status versus resolution status: “In transit” describes a shipment. “Investigation open” describes support work. Neither can substitute for the other.

Compact context versus missing association: Repeated identifiers consume some space but carry meaning. Remove unrelated detail before removing the keys that let Claude interpret values correctly.

Architecture / decision scenario

A customer raises three concerns: a damaged item on ORD-731, an unexplained USD 14.00 charge on that same order, and late delivery for ORD-744. The application uses one case-level order_id, amount, and status. Each tool result overwrites those fields, so the delayed shipment’s status appears next to the damaged item’s refund amount.

Replace that flat representation with separately persisted issue records. Store USD 67.35 as the damaged-item refund request, USD 14.00 as the charge dispute, and USD 8.00 as the shipping fee paid for the delayed order. Keep each issue’s resolution status alongside its own identifiers.

When the delivery tool confirms ORD-744’s arrival, update that order’s delivery fact and the supported delivery-resolution state. Leave the charge review open and the damaged-item refund approved but unsubmitted. Render all unresolved concerns, plus the relevant completed delivery record, when the customer asks for an overall update.

The answer can now report three distinct outcomes. If the customer then asks “What about the refund?”, the agent uses the issue associations to discuss the damaged item; it does not treat the shipping fee or disputed charge as the approved refund merely because those values appeared later.

Common exam traps

• Keeping exact amounts without identifying their issue and order.
• Using one case-level status for independently progressing concerns.
• Assuming an order identifier uniquely identifies a support issue.
• Treating a shipment status as a support-resolution status.
• Closing all concerns when one tool reports success.
• Dropping attribution keys while trimming context.

What to remember

Persist each concern’s identifiers, values, and resolution state together. Link tool evidence to the issue it addresses, preserve unresolved concerns through topic changes and summaries, and distinguish entity facts from the status of support work.

Knowledge check

References

• Anthropic, Claude Certified Architect – Foundations Exam Guide
• Anthropic, Effective context engineering for AI agents
• Anthropic, Working with Messages
• Anthropic, Handle tool calls