The Persistent Case Facts Block

Mastering the Persistent Case Facts Block

Discover how summarisation destroys critical transactional details and learn to manage agent context securely using a persistent case facts block.

The Progressive Summarization Trap

Large Language Models have finite context windows. To save space, developers often summarize earlier parts of a conversation.

This creates a systematic trap. Summaries preserve the narrative but discard specific identifiers like dates and amounts.

A request for a refund of $247.83 for order #8891 placed on March 3rd often compresses into: Customer wants a refund for a recent order.

All three critical facts are lost during this compression step.

Why Instructions Are Not Enough

You might try telling the model to preserve all numerical values while summarizing. This approach often fails.

Prompt-level instructions compete with the heavy pressure of compression. The model prioritizes the "gist" over the details.

Even server-side features like compaction can drop transactional values if they are not protected.

To maintain 100% accuracy, you must move data out of the conversational history entirely.

The Persistent Case Facts Block

The solution is a structured block of data included in every prompt. This block is never summarized.

It sits outside the message history and is copied forward verbatim. It acts as the "source of truth" for the agent.

A typical block includes customerId C-4421 and an issues array. This array stores orderId #8891, orderDate 2024-03-03, and refundAmount $247.83.

This ensures the agent still quotes the correct figures on turn 20.

Managing Multiple Issues

A common mistake is using one shared block for everything. This fails when a customer raises several separate issues.

Each unique problem needs its own entry in the issues array. This keeps attribution honest from end to end.

Decide what belongs in the block versus the summary. Transactional facts like status pending_refund stay in the block.

Subjective details, such as the customer mood, belong in the summarized narrative history.

Putting It All Together

Will adding prompt-level instructions to preserve numerical values reliably prevent an LLM from dropping dates and amounts during conversation summarisation?

• Yes
• No

Answer: No

Prompt-level instructions compete with the high compression pressure of summarisation, causing the model to naturally drop specific figures in favour of the general narrative.

In agent context management, _____ like order numbers are kept in a persistent block, whereas _____ like customer mood belong in the summarised conversation history.

Answer: In agent context management, transactional facts like order numbers are kept in a persistent block, whereas subjective details like customer mood belong in the summarised conversation history.

Transactional facts must sit outside conversation history in an unsummarised block to avoid context decay, while subjective elements like customer sentiment remain in the summarised narrative history.

A customer reports two separate issues in one support session: a delayed delivery for order #101 and a damaged item from order #102. How should the persistent case facts block handle this?

• Overwrite order #101 details with order #102 details as soon as the second issue is raised.
• Create a separate entry for each distinct problem within an issues array inside the block.
• Keep order #101 in the persistent block and place order #102 into the summarised narrative history.
• Concatenate both order numbers into a single text field named orderId within the block.

Answer: Create a separate entry for each distinct problem within an issues array inside the block.

Using a single shared block fails when multiple issues arise. Each distinct problem requires its own item in an issues array to maintain clear and accurate attribution across long sessions.