# The Summarization TRAP: Why You Should Never Summarize Everything > Source: > Published: 2026-08-02 14:01:03+00:00 Imagine you’re building a customer support chatbot for an e-commerce company. A customer starts a conversation and says: ``` Customer ID: cus_abc123Order ID: ord_xyz789Refund Amount: $249.50Coupon Code: SUMMER2026 ``` The chatbot verifies the customer, checks the order details, looks up the refund policy, and even calls a few internal APIs. The conversation keeps going because the customer has more questions. They ask about the shipping address, the expected refund date, whether the coupon affected the refund amount, and a few other things. Before you realize it, the conversation has already crossed 25 or 30 turns. Now the customer asks one final question: “Can you remind me how much I’m getting refunded?” The chatbot confidently replies, “You’re getting around $250.” Wait… The customer wasn’t getting **around $250**. The customer was getting **exactly $249.50**. Nobody changed the refund amount. Nobody edited the conversation. The information was clearly mentioned at the beginning of the chat. So why did the model suddenly stop being precise? **Where did those 50 cents go?** At first glance, this might look like a small rounding error. But in a production financial system, healthcare application, or legal workflow, this isn’t just a rounding mistake, it can become an audit issue. More importantly, it reveals a much bigger architectural problem. Most engineers immediately think,“Maybe the model forgot.” Others think,“Let’s just use a model with a larger context window.” Both sound reasonable, but neither is the real solution. Before we understand how production AI systems solve this problem using techniques like **Case Facts Blocks **( we will see later what exactly it is ), we first need to understand something much more fundamental. What exactly is summarization? The problem starts much earlier, with the way we summarize conversations. let’s understand what most engineers naturally do to solve it. The conversation is becoming longer. The context window is slowly filling up. So the obvious question becomes: “Why don’t we just summarize the old conversation?” Honestly, that’s not a bad idea. In fact, summarization is one of the most commonly used techniques in long-running AI systems. Whether you’re building a customer support chatbot, a research assistant, or a document analysis agent, sooner or later you’ll have to deal with conversations that become too large to fit comfortably inside the model’s context window. So instead of sending all 30 or 40 conversation turns back to the model, we compress the older part of the conversation into a much shorter summary and keep only the recent messages in full detail. For example, imagine the original conversation looked something like this: ``` Turn 1:Customer: My Customer ID is cus_abc123. My Order ID is ord_xyz789, and I paid exactly $249.50. Turn 2:Agent verifies the customer. Turn 3:Order lookup completed. Turn 4:Refund policy checked. Turn 5:Customer asks whether the coupon affects the refund. Turn 6:Agent explains the refund policy. ... Turn 25:Customer asks another follow-up question. ``` Instead of sending all twenty-five turns again, we might replace the first twenty turns with something like this: ``` Conversation Summary• Customer requested a refund.• Agent verified the customer.• Order lookup completed.• Refund eligibility confirmed.• Customer had questions about the refund policy. ``` Now the model only receives: Much smaller. Much cheaper. Much faster. At first glance, this seems like the perfect solution. We reduced the number of tokens, the model still understands what happened earlier, and we can continue the conversation without exceeding the context window. You maybe thinking, that’s what I do every time, what’s wrong in this ?? The problem isn’t summarization itself. The problem is **what summarization removes.** Step 2: Where Does Summarization Go Wrong? The summary captures the overall conversation accurately. But let’s compare it with the original conversation for a second. ``` Original Conversation SummaryCustomer ID: cus_abc123 MissingOrder ID: ord_xyz789 MissingRefund Amount: $249.50 MissingRefund Deadline: 2026-04-30 MissingCustomer requested refund PresentAgent verified eligibility PresentRefund eligibility confirmed. Present ``` Notice something interesting. The summary preserved the **story**. But it lost the **facts**. And that’s exactly what summaries are designed to do. When we ask an LLM to summarize a conversation, we’re essentially asking it: “Keep the important ideas, but remove unnecessary details.” The problem is… The model has no way of knowing that **$249.50** isn’t just another detail. For a human reading the conversation, “$249.50” might look like a small piece of information. For your refund API, it’s the **entire transaction**. The same is true for customer IDs, invoice numbers, dates, policy numbers, medical record IDs, contract clauses, or tracking numbers. To us, they look like tiny details. To the application, they’re the source of truth. So the issue isn’t that the summary is wrong. The issue is that **summaries are optimized for understanding, not for preserving exact data.** And once those exact values disappear, getting them back becomes almost impossible. Unfortunately… This problem becomes even worse when the conversation keeps getting longer. Because now you’re no longer summarizing the original conversation. You’re **summarizing a summary**. And that’s where the real trouble begins. Step 3: The Progressive Summarization Trap Imagine your customer support agent has now handled 40 conversation turns. **You already summarized the first 20 turns to save context**. After another 20 turns, the conversation becomes large again. So what do you do? **The most natural solution is to summarize everything once more.** This time, however, you’re no longer summarizing the original conversation. You’re summarizing **an existing summary**. A few more turns later, you summarize it again. ``` Original Conversation │ ▼ Summary #1 │ ▼ Summary #2 │ ▼ Summary #3 ``` At every stage, the model tries to keep the main idea while removing information it considers less important. The **story** survived. The **exact facts** didn’t. Every new summary removes a little more detail than the previous one. Individually, those changes seem harmless. But after multiple rounds of summarization, the information loss starts to compound. This phenomenon is known as Progressive Summarization. The model isn’t making a mistake. It’s doing exactly what we asked it to do. **We asked it to compress information.** And once those values disappear, the model has no reliable way to reconstruct them later. So the question becomes: **Can we summarize the conversation without summarizing the information that must never change?** That’s exactly the problem production AI systems solve. Step 4: Not All Information Is Equal At this point, we know that summarization removes details. But here’s the interesting question. **Should every piece of information be treated the same?** The answer is **no**. In a long conversation, there are generally two types of information. The first type isnarrative information. This is the information that helps us understand **what happened** during the conversation. For example: These statements describe the overall flow of the conversation. Even if we compress them into a shorter summary, we usually don’t lose anything important. Now let’s look at the second type. This is transactional information. Unlike narrative information, these values aren’t describing the conversation, they’re the actual data your application depends on. For example: ``` Customer ID: cus_abc123Order ID: ord_xyz789Refund Amount: $249.50Refund Deadline: 2026-04-30Tracking Number: TRK-982173Policy Tier: Gold ``` Notice something. These aren’t sentences. They’re facts. Your refund API doesn’t care that the customer asked for a refund. It cares about the exact value of: ``` refund_amount = 249.50 ``` Similarly, your database doesn’t care that the order was discussed. It needs the exact: ``` order_id = ord_xyz789 ``` This is where many engineers accidentally make a design mistake. They summarize **both** types of information together. The narrative gets shorter. But the transactional facts slowly disappear. Instead, production AI systems treat these two categories completely differently. Narrative information is meant to be summarized. Transactional information is meant to be preserved. That’s the mental model I want you to remember throughout this blog. Summarize the story. Preserve the facts. Once you separate information into these two categories, the architecture almost designs itself. The next question becomes: **Where should those facts live if they should never be summarized?** Step 5: The Case Facts Block Now we know something important. Not every piece of information should be summarized. Narrative information can safely become shorter. Transactional information cannot. So the obvious question becomes: If we shouldn’t summarize transactional information, where should we keep it? This is exactly the problem the **Case Facts Block** solves. A Case Facts Block is nothing more than a structured collection of facts that should remain **exactly the same** throughout the entire conversation. Instead of mixing these values with the conversation history, we separate them into their own dedicated block. For example, instead of relying on the model to “remember” that the customer paid **$249.50**, we explicitly provide those values every single time we make a request. ``` customer_id: cus_abc123order_id: ord_xyz789refund_amount: 247.83refund_deadline: 2026-04-30policy_tier: Gold ``` Now compare that with the conversation summary. ``` Customer contacted support regarding a refund.The order was verified.Refund eligibility was confirmed.The customer had questions about the refund policy. ``` Both pieces of information serve completely different purposes. The summary helps the model understand **what happened**. The Case Facts Block tells the model **what must never change**. **Once you separate these two responsibilities, summarization becomes much safer.** You can aggressively summarize the conversation without worrying about losing the customer ID, refund amount, invoice number, contract ID, policy number, or any other value your application depends on. In other words, instead of asking the model to remember important facts, you’re giving the model those facts explicitly on every request. That’s a much more reliable architecture. But here’s where things become even more interesting. Simply creating a Case Facts Block isn’t enough. **How you manage that block over time determines whether your system remains reliable or slowly starts drifting.** Step 6: The Three Rules Every Case Facts Block Must Follow At this point, creating a Case Facts Block sounds pretty straightforward. Just put the important information into a structured block and you’re done. Not quite. A Case Facts Block is only useful if it’s managed correctly. Over time, engineers discovered a few simple rules that make this pattern reliable in production systems. Let’s understand them one by one. Rule 1: Keep It at the Top The first rule is simple. **The Case Facts Block should always appear before the conversation.** You might be wondering… “Why does the position matter? The model can read the entire context anyway.” Technically, yes. But practically, not all parts of the prompt receive the same attention. Research on long-context language models has shown that information **buried in the middle of a very long prompt is easier to overlook** than information placed at the beginning or the end. This phenomenon is commonly known as the **Lost-in-the-Middle** problem. That’s why production systems pin important facts right at the beginning of the prompt. Not because the model can’t read the rest. But because these values are too important to leave buried inside hundreds of previous messages. Rule 2: Don’t Let the Model Rewrite Facts This is probably the rule that surprises most people. The Case Facts Block is **not** a summary. It’s **not** a conversation. It’s the source of truth. That means it should never be rewritten just because the conversation continues. For example, imagine your block contains: ``` refund_amount: 249.50 ``` A few turns later, the model summarizes the conversation and writes: Customer requested a refund of around$250. Should the block now become: ``` refund_amount: 250 ``` Absolutely not. The summary is allowed to paraphrase. The Case Facts Block is not. The only time this block should change is when the **underlying fact changes**. For example, if the customer says: “Sorry, I gave you the wrong Order ID.” or “The refund amount should actually be $312.50.” Now the source of truth has changed. Updating the block makes sense. Everything else, the model’s reasoning, summaries, explanations, and conversations, should never overwrite it. Rule 3: Never Summarize the Block This is where everything comes together. When your conversation becomes too large, you summarize the conversation. **You do not summarize the Case Facts Block.** Think about what happens if we include it in the summarization process. Original: ``` refund_amount: 249.50 ``` After summarization: Customer requested a refund of approximately $250. We’ve just recreated the exact problem we were trying to solve. Instead, production systems follow a much simpler workflow. The summary becomes smaller. The context window becomes smaller. But the important facts remain exactly the same. And that’s the entire idea behind this pattern. We’re not trying to preserve the whole conversation forever. We’re only preserving the information that should never be lost. Step 7: How Production AI Systems Actually Manage Context At this point, we understand three important things. So how does a production AI system put all of this together? Let’s imagine a customer support agent handling a refund request. The customer starts the conversation by providing their Customer ID, Order ID, and the exact refund amount. The application immediately extracts these values and stores them inside a **Case Facts Block**. The conversation then continues normally. The customer asks questions. The agent calls tools. The application checks internal APIs. More messages get added. Eventually, the conversation becomes large enough that we decide to summarize the older messages. Here’s the important part. We **don’t** summarize everything. Instead, the application follows a simple workflow. ``` User Conversation │ ▼ Extract Important Facts │ ┌──────────────┴──────────────┐ ▼ ▼ CASE_FACTS Conversation History │ ▼ Summarization Engine │ ▼ Conversation Summary CASE_FACTS + Conversation Summary + Recent Conversation │ ▼ LLM Request ``` Notice what happened here. The summarizer never touches the Case Facts Block. It only summarizes the conversation history. Once the summary is generated, the application simply combines three pieces of information: These three together become the next request sent to the LLM. This architecture gives us the best of both worlds. The conversation remains small enough to fit comfortably inside the context window, while the critical information stays exactly the same from the first turn to the last. More importantly, the model never has to “remember” those values. They’re explicitly provided on every request. That’s why this pattern is much more reliable than asking the model to recall information from hundreds of previous messages. Now that we understand the overall architecture, implementing it in code becomes surprisingly simple. Common Mistakes Engineers Make By now, you probably understand why the Case Facts Block exists. But here’s something interesting. When engineers first learn about this pattern, they often come up with solutions that sound reasonable but don’t actually solve the problem. Let’s look at some of the most common ones. “I’ll just use a larger context window.” This is probably the most common misconception. A larger context window certainly delays the problem, but it doesn’t eliminate it. Long-running conversations continue to grow. Tool calls continue to accumulate. Eventually, even a larger context window fills up. More importantly, a larger context window doesn’t solve the **Lost-in-the-Middle** problem. Important facts buried inside hundreds of messages can still receive less attention than information placed at the beginning of the prompt. A larger context window gives you more space. It doesn’t give you better state management. “I’ll summarize everything.” At first, this sounds like the perfect solution. Smaller context. Lower cost. Faster requests. But remember what we learned earlier. Summaries are designed to preserve the **story**, not the **exact values**. Customer IDs, invoice numbers, refund amounts, policy IDs, contract numbers, and medical record identifiers should never be treated like ordinary conversation. The moment you summarize them, you’ve already accepted information loss. “I’ll ask the model to remember important facts.” This one is surprisingly common. You’ll often see prompts like: “Remember the customer’s Order ID throughout the conversation.” The problem is that prompts are instructions. They are **not memory**. Production systems don’t rely on reminders. They rely on architecture. Instead of hoping the model remembers something, they simply provide those facts again on every request. “I’ll keep updating the Case Facts Block.” This is another mistake that sounds reasonable. As the conversation grows, some engineers keep rewriting the Case Facts Block so it matches the latest summary. Unfortunately, this introduces the very problem we’re trying to avoid. Every rewrite is another opportunity to accidentally change an exact value. Instead, think of the Case Facts Block as the application’s source of truth. If the customer corrects their Order ID, update it. If the refund amount actually changes, update it. But never rewrite it simply because the conversation was summarized. “I’ll store everything inside the Case Facts Block.” This is the opposite problem. Once engineers discover this pattern, they’re tempted to put every detail inside it. Meeting notes. Entire conversations. Reasoning. Tool outputs. That’s not the goal. The Case Facts Block should contain only the information that your application cannot afford to lose. Everything else belongs in the conversation and can safely be summarized. Think of it this way. **Summaries explain what happened.** **Case Facts preserve what must never change.** Final Thoughts The biggest takeaway from this article is simple: **not everything should be summarized**. Conversations and reasoning can be compressed, but critical facts like customer IDs, invoice numbers, dates, and exact monetary values should always remain intact. The next time you’re building a long-running AI agent, don’t ask, *“How do I summarize this conversation?”* Instead, ask, *“Which information should never be summarized?”* I hope this guide helped you understand why production AI systems don’t simply summarize everything and how the **Case Facts Block** helps preserve critical information in long-running conversations. If you found it useful, consider sharing it with others, and feel free to leave your thoughts or questions in the comments. Follow [Jiten Bhalavat](https://medium.com/u/b3fc496a0d17) and subscribe via email to receive upcoming blogs on AI systems, LLM architecture, context engineering, agentic workflows, and practical machine learning engineering straight into your mailbox. [The Summarization TRAP: Why You Should Never Summarize Everything](https://pub.towardsai.net/the-summarization-trap-why-you-should-never-summarize-everything-9a63438c87af) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.