{"slug": "i-stopped-treating-ai-memory-as-summaries-i-now-think-in-handoffs", "title": "I stopped treating AI memory as summaries. I now think in handoffs.", "summary": "A developer argues that AI memory should be structured as handoffs rather than summaries, identifying four key classes of information to carry between sessions: framing shifts, boundaries, unresolved states, and corrections. The approach aims to make future interactions more respectful and accurate by preserving only the most relevant context.", "body_md": "In [my last post](https://dev.to/woshiliyana/ai-memory-should-be-a-product-state-not-a-prompt-trick-4m20), I wrote that AI memory should be treated as product state, not as a prompt trick.\n\nAfter publishing that post, I kept running into the next problem while working on the memory layer:\n\nWhat should actually be carried into the next session?\n\nThat is a different question from what should be stored.\n\nA summary compresses the past. A handoff prepares the next interaction.\n\nThat difference matters.\n\nA lot of memory systems start from summarization.\n\nAt the end of a session, compress the conversation. Save the important parts. Use them later.\n\nThat sounds reasonable, but the word \"summary\" hides a product problem.\n\nA summary does not have a clear reader.\n\nIt tries to compress everything for nobody in particular. It often becomes a smaller version of the conversation, with some details removed and some confidence added. But it does not answer the question that matters:\n\nWho is this note for?\n\nIf the answer is \"the next session,\" then the artifact changes.\n\nIt is no longer just a summary. It is a handoff.\n\nA handoff artifact is written for a future interaction that has to pick up the work without pretending it was there the whole time.\n\nThat constraint changes what is worth writing down.\n\nFor reflective AI, I do not think the best memory is always the most detailed memory.\n\nThe goal is not to preserve everything. The goal is to preserve the few things that would make the next session more respectful, more accurate, or less repetitive.\n\nI currently think there are at least four classes worth carrying forward.\n\nSometimes the important thing is not a fact about the user.\n\nIt is a shift in how the user understands the problem.\n\nMaybe they came in thinking they needed a feature, and left realizing they needed a boundary. Maybe they started with a vague feeling and ended with a clearer question. Maybe the session changed the shape of the work.\n\nThat kind of moment can be worth carrying forward because it helps the next session avoid dragging the user back to an older frame.\n\nBut it has to be handled carefully.\n\nA framing shift is not a permanent identity claim. It should not become \"the user is this kind of person.\" It is closer to:\n\nIn this context, the user moved from this frame to that frame.\n\nThat is a safer memory.\n\nBoundaries are different from preferences.\n\nA preference might be:\n\nI like shorter replies.\n\nA boundary is more like:\n\nDo not make this decision for me.\n\nOr:\n\nDo not reopen this unless I ask.\n\nOr:\n\nThis topic needs explicit consent.\n\nThese should not be buried inside a general summary. They deserve their own status.\n\nIf a user sets a boundary, the next session should not have to rediscover it through trial and error.\n\nThis is where memory starts to look less like personalization and more like trust infrastructure.\n\nNot every useful session ends with a conclusion.\n\nSometimes the user chooses to keep something unresolved.\n\nThat can be an important state.\n\nThe system should not rush to resolve it later just because it has a saved note. It should also not erase it and force the user to rebuild the context from scratch.\n\nA good handoff artifact can say:\n\nThis was left open on purpose.\n\nThat is different from saying:\n\nThis is unfinished.\n\nThis one feels especially important.\n\nWhen the user corrects the system, that is not just a preference signal. It is a repair event.\n\nThe system got something wrong, and the user supplied the fix.\n\nThat should be one of the most valuable things to carry forward, because it is testable.\n\nA framing-change moment can be hard to verify in the next session. A correction is easier to test. When a similar input appears again, the system can show whether it actually learned by not making the same mistake.\n\nThis is also a useful guardrail against vague personalization.\n\nThe system should not only remember a polished version of who it thinks the user is. It should remember where its own model of the user failed.\n\nThe practical difference between a summary and a handoff is that a handoff needs a schema.\n\nA loose summary can be a paragraph.\n\nA handoff artifact needs to make the next reader explicit.\n\nA simplified version might look like this:\n\n```\ntype HandoffArtifact = {\n  id: string;\n  sessionId: string;\n  audience: \"next-session\" | \"retrieval\" | \"user-review\";\n\n  carryForward: HandoffItem[];\n  doNotCarryForward: HandoffItem[];\n  unresolvedTensions: HandoffItem[];\n  userCorrections: HandoffItem[];\n\n  consentState: \"draft\" | \"approved\" | \"edited\" | \"rejected\";\n  createdAt: string;\n  expiresAt?: string;\n};\n\ntype HandoffItem = {\n  kind:\n    | \"framing-change\"\n    | \"boundary\"\n    | \"unresolved-tension\"\n    | \"correction\";\n\n  text: string;\n  sourceExcerpt?: string;\n  reason: string;\n  confidence: \"low\" | \"medium\" | \"high\";\n};\n```\n\nThe important part is not the exact schema.\n\nThe important part is that the artifact separates several things that summaries usually flatten:\n\nThis gives the next session a cleaner contract.\n\nIt also gives the product a better failure mode.\n\nIf the system gets the handoff wrong, the user can reject or edit a specific item instead of fighting an invisible memory layer.\n\nA basic lifecycle might look like this:\n\n``` php\nsession\n-> draft handoff\n-> user review\n-> approved / edited / rejected\n-> retrieval candidate\n-> prompt context\n```\n\nThat lifecycle is the part I would not skip.\n\nWithout it, the schema is just another hidden memory object. The user still has no real authority over what gets inherited.\n\nThis may be the hardest product question.\n\nIf the model writes the handoff artifact by itself, it may quietly preserve the version of the user it finds easiest to understand.\n\nThat is dangerous.\n\nThe model might turn a temporary mood into a stable trait. It might compress a complicated tension into a simple label. It might save the cleanest story, not the truest one.\n\nIf the user has to write the handoff artifact, the cost is too high.\n\nMost users will not do it. And honestly, they should not have to. Asking users to manage their own memory system like a database is not a real product solution.\n\nThe middle ground seems more promising:\n\nThe model drafts. The user ratifies.\n\nBut that only works if ratification is light.\n\nIt cannot feel like reviewing a document after every session. It probably has to be closer to:\n\nThe user should not have to become the system administrator of their own memory. But they should have real authority over what gets inherited.\n\nThis part is under-discussed.\n\nMost memory products assume continuity is good.\n\nMore continuity, more personalization, more context.\n\nBut unasked-for continuity can create a burden for the user.\n\nIf the system carries forward the wrong thing, the user has to spend the next session undoing it. They have to refute an inheritance they never asked for.\n\nThat is backwards.\n\nSometimes carrying nothing forward is the more respectful choice.\n\nIt means the next session has to earn the context again. The user does not have to dismantle a stale version of themselves before the conversation can begin.\n\nFor reflective AI, this matters a lot.\n\nA system that remembers too aggressively can start to sound intimate before it has earned the right to be. It can act as if it understands the user more than it does.\n\nThat is not continuity. That is overconfidence.\n\nI have been thinking about this while building [Jung Room](https://www.jungroom.com/en/chat), a non-clinical AI self-exploration room for dreams, moods, symbols, and recurring patterns.\n\nIn that kind of product, memory cannot just be a hidden personalization layer.\n\nIt has to be something the user can inspect, correct, and choose not to carry forward.\n\nThat changes the implementation.\n\nMemory is no longer just a retrieval feature. It becomes part of the product contract.\n\nThe more I think about this, the less I see AI memory as a storage problem.\n\nStorage is the easy word.\n\nThe harder questions are governance questions.\n\nWho decides what gets remembered?\n\nWho decides what gets used?\n\nWho can correct it?\n\nWho can delete it?\n\nWhen should the system choose not to remember?\n\nAnd when memory moves from one session to the next, who is responsible for that inheritance?\n\nA handoff artifact makes these questions more visible because it names the next reader.\n\nIt forces the system to ask what the next session actually needs, instead of simply compressing the last one.\n\nThat is the product shift I care about:\n\nAI memory should not be a pile of summaries. It should be a set of governed handoffs, with the user still in charge of what gets carried forward.", "url": "https://wpnews.pro/news/i-stopped-treating-ai-memory-as-summaries-i-now-think-in-handoffs", "canonical_source": "https://dev.to/woshiliyana/i-stopped-treating-ai-memory-as-summaries-i-now-think-in-handoffs-1gcb", "published_at": "2026-06-25 14:59:41+00:00", "updated_at": "2026-06-25 15:13:22.063068+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-products", "ai-agents", "natural-language-processing"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/i-stopped-treating-ai-memory-as-summaries-i-now-think-in-handoffs", "markdown": "https://wpnews.pro/news/i-stopped-treating-ai-memory-as-summaries-i-now-think-in-handoffs.md", "text": "https://wpnews.pro/news/i-stopped-treating-ai-memory-as-summaries-i-now-think-in-handoffs.txt", "jsonld": "https://wpnews.pro/news/i-stopped-treating-ai-memory-as-summaries-i-now-think-in-handoffs.jsonld"}}