{"slug": "a-retry-safe-handoff-contract-for-long-ai-chats", "title": "A Retry-Safe Handoff Contract for Long AI Chats", "summary": "A developer outlined a retry-safe handoff protocol for resuming long AI-assisted tasks across conversations, proposing a structured packet that separates confirmed facts from unknowns, decisions, and open items. The design uses a content-derived SHA-256 hash as a stable packet ID so duplicate retries are detected via a receipt store, and defines PREPARED, ACKNOWLEDGED, RESUMED, and CANCELLED states, with a separate transition required before any action with external effects. The author notes the sample code is an in-memory illustration that would need durable storage, a unique constraint on the handoff ID, and canonical serialization for cross-language systems.", "body_md": "Long AI-assisted tasks often span more than one interaction. A response may be interrupted, a user may need to start a new conversation, or a tool call may finish while the interface is still waiting. The fragile point is not always the summary itself. It is the *transition*: what happens if a handoff is sent twice, acknowledged late, or resumed from incomplete context?\n\nA useful design starts by treating a handoff as a small protocol, not as an unstructured paragraph that says “continue where we left off.”\n\nA handoff packet should describe only the state needed to resume responsibly. For example:\n\n```\n{\n  \"schema_version\": 1,\n  \"conversation_id\": \"example-session\",\n  \"revision\": 17,\n  \"goal\": \"Complete the deployment review\",\n  \"confirmed_facts\": [\"Tests passed locally\"],\n  \"decisions\": [\"No production change without approval\"],\n  \"open_items\": [{\"id\": \"T-12\", \"task\": \"Verify the live service\"}],\n  \"unknowns\": [\"Whether the new version is serving traffic\"],\n  \"last_completed_step\": \"Recorded the dry-run results\"\n}\n```\n\nThe distinction between `confirmed_facts` and `unknowns` matters. A newly opened conversation should not silently promote a guess into a fact. Likewise, decisions and restrictions should survive even if older conversational details do not.\n\nAvoid putting passwords, API keys, session cookies, personal identifiers, or confidential source material into the packet. A handoff is still data being copied into another context; minimization and redaction should happen *before* transfer.\n\nRetries are normal in distributed workflows. Suppose a sender transfers a packet, receives no acknowledgment, and retries. Without a stable ID, the receiver may treat the retry as a new instruction.\n\nA simple demonstration uses a content-derived ID:\n\n``` js\nimport { createHash } from 'node:crypto';\n\nfunction makePacket(state) {\n  const payload = JSON.stringify(state);\n  const id = createHash('sha256').update(payload).digest('hex');\n  return { id, payload };\n}\n\nfunction acceptPacket(packet, receiptStore) {\n  if (receiptStore.has(packet.id)) {\n    return { duplicate: true, receipt: receiptStore.get(packet.id) };\n  }\n  const receipt = { id: packet.id, accepted: true };\n  receiptStore.set(packet.id, receipt);\n  return { duplicate: false, receipt };\n}\n\nconst state = { conversation_id: 'example-session', revision: 17 };\nconst packet = makePacket(state);\nconst receipts = new Map();\nconsole.log(acceptPacket(packet, receipts).duplicate); // false\nconsole.log(acceptPacket(packet, receipts).duplicate); // true\n```\n\nThis is an **in-memory illustration**, not production-grade exactly-once delivery. A real system needs durable storage, a unique constraint on the handoff ID, and an atomic relationship between recording the receipt and applying any consequential operation. Cross-language systems also need canonical serialization before hashing, because equivalent JSON objects can have different byte representations. A hash is an identifier here, not an authorization token.\n\nA handoff can move through a few named states:\n\n| State | Meaning | \n|---|---|\n| `PREPARED` | A packet exists, but the destination has not confirmed receipt. | \n| `ACKNOWLEDGED` | The destination accepted a specific packet ID. | \n| `RESUMED` | Work continued from that acknowledged packet. | \n| `CANCELLED` | The user or system stopped the transition. | \n\nA timeout after `PREPARED` is not evidence of failure; the receiver might have accepted the packet before the acknowledgement was lost. The safe retry uses the **same packet ID** and first asks the receiver whether it has already been accepted.\n\nA separate state transition should be required before any action with external effects: sending email, updating a database, deploying software, or publishing content. Resuming context is not permission to perform those actions.\n\nBefore continuing, the destination should answer five questions:\n\nIf the answer to an important question is unknown, the continuation should say so. “Needs verification” is a valid state; invented certainty is not.\n\nAt minimum, test duplicate delivery, dropped acknowledgments, stale revisions, malformed packets, missing restrictions, cancellation, and re-opening a conversation after the sender is gone. It is also worth checking that no hidden background action starts solely because a handoff arrives.\n\nFor browser-based tools, the user should be able to pause, inspect, copy a backup, and stop a transition. Visibility is not a substitute for permissions, but it makes failures easier to detect and recover from.\n\nA summary helps another conversation *understand* the work. A handoff protocol helps it *resume safely*. The difference is an explicit record of what is known, what is not known, what has already happened, and which steps still require authorization.\n\n**AI disclosure:** This article was drafted with generative AI. It must be checked and substantially reviewed by a human who understands the technical material before publication. It is not a report of firsthand testing or production experience.", "url": "https://wpnews.pro/news/a-retry-safe-handoff-contract-for-long-ai-chats", "canonical_source": "https://dev.to/lamama/a-retry-safe-handoff-contract-for-long-ai-chats-28pe", "published_at": "2026-10-25 20:11:49+00:00", "updated_at": "2026-10-25 20:13:24.656522+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "ai-safety"], "entities": [], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/a-retry-safe-handoff-contract-for-long-ai-chats", "markdown": "https://wpnews.pro/news/a-retry-safe-handoff-contract-for-long-ai-chats.md", "text": "https://wpnews.pro/news/a-retry-safe-handoff-contract-for-long-ai-chats.txt", "jsonld": "https://wpnews.pro/news/a-retry-safe-handoff-contract-for-long-ai-chats.jsonld"}}