Conversation context management

• Repeated summarization turns numbers, percentages, dates and customer-stated expectations into vague phrases.
• Models attend reliably to the start and end of a long input and may skip the middle ("lost in the middle").
• Tool results accumulate out of proportion to their value: one lookup can return dozens of fields when a handful matter.
• Every call must carry the complete conversation history; the model remembers nothing between calls.
• A "case facts" block holds transactional facts (order ids, amounts, dates, statuses) outside the summarized history and is sent with every prompt.
• Trim tool output to the relevant fields before it enters the conversation.
• Put a key-findings summary first and organize details under explicit headers when aggregating long inputs.

• Extract transactional facts into a persistent block that summarization never touches.
• Keep a separate structured layer per issue in multi-issue sessions.
• Trim verbose tool results at the boundary (tool wrapper or post-tool hook).
• Order long aggregated inputs to counter the position effect.
• Require subagents to return structured data with metadata (dates, sources, method) when downstream agents have small context budgets.

• "A bigger context window solves it." The position effect and summarization loss remain; the window only delays them.
• "Telling the model to be precise with numbers is enough." Compression loses detail regardless of instructions.
• "Sending only the latest message is cheaper and fine." It breaks coherence and causes repeated lookups.

Answer choices that fix a cost problem by summarizing harder, or a memory problem by resending everything. The best answer usually moves a small set of exact facts into a protected place and removes waste at the source.

• 1.1Agentic loops
• 5.4Context in large codebases
• 5.6Provenance and uncertainty