Handoff summary

Problem Context

• Handoffs can occur between AI and human agents, support representatives, shifts, reviewers, incident commanders, queues, supervisors, care teams, departments, or tools.
• The sender may be a person, automation, bot, AI agent, previous shift, reviewer, triager, or supervisor.
• The receiver needs enough context to act without rereading every message, but also needs access to source transcript, ticket, case, log, attachment, or timeline evidence.
• Some facts may be generated, stale, disputed, redacted, confidential, unavailable, or outside the receiver's permission scope.
• A handoff can be warm, cold, live, asynchronous, temporary, permanent, escalated, declined, reassigned, or handed back.

Selection Rules

• Choose handoff summary when the user's task is to take over work or continue a conversation, case, incident, ticket, patient, workflow, or agent session from someone or something else.
• Use assignment when the primary action is only selecting the accountable owner; add handoff summary when the new owner needs context to continue.
• Use summary box when summarizing a long page for the same reader, not transferring responsibility to a receiver.
• Use activity log when the task is audit or investigation of historical events, not concise operational continuation.
• Use comments when collaborators are discussing details; handoff summary should extract the current state and next action from those details.
• Use notification center when users need to be alerted that a handoff occurred, but link to the summary for actual context.
• Use approval workflow when the receiver must approve or reject a request under route rules, not simply take over context.
• Use review queue when reviewers choose among many items; handoff summary is item-level context for one transferred item.
• Show sender, receiver, transfer reason, source object, generated time, last updated time, current status, urgency, risks, and next owner before the receiver accepts.
• Use structured sections such as Situation, Background, Assessment, Recommendation, action list, open questions, blockers, and source links rather than a vague paragraph.
• Label generated, edited, stale, redacted, permission-limited, and unverified facts.
• Provide accept, ask clarification, update summary, decline, reassign, hand back, or confirm-responsibility behavior when the workflow requires an explicit transfer.

Required States

• Default handoff summary with sender, receiver, reason, status, and source object.
• AI-to-human conversation handoff with transcript link, collected variables, attempted steps, and escalation reason.
• Human-to-human shift or case handoff with open tasks, deadlines, and contingency notes.
• Generated summary state with timestamp, source coverage, and edit or regenerate affordance.
• Receiver accepted and responsibility confirmed state.
• Clarification requested state before accepting ownership.
• Declined, reassigned, or handed-back state.
• Stale summary state after source transcript, ticket, case, or activity changed.
• Missing source, redacted, or permission-limited summary state.
• Long transcript condensed state with source links and omitted-details warning.
• Mobile condensed handoff card state.
• Failed summary generation or failed transfer retry state.

Interaction Contract

• A handoff summary is tied to a named source object and transfer event, not an orphan note.
• The receiver can identify who or what is handing off, why, what is currently true, what remains unresolved, and what action is expected next.
• Source links open the exact conversation, ticket, case, log event, attachment, or timeline section behind each major claim.
• Generated summaries disclose generated time, source coverage, and whether a person edited or confirmed them.
• Accepting a handoff updates responsibility, queue, notification, activity, and status surfaces according to the product model.
• Declining, reassigning, or handing back preserves the summary and reason so context does not disappear.
• Stale source data marks the summary stale and prompts refresh or review before acceptance.
• Permission-limited receivers see redaction reasons and request-access or route-recovery options instead of leaked content.
• After accept, decline, clarify, or refresh, focus stays near the status change or next required action.

Implementation Checklist

• Define the handoff record: source object, sender, receiver, route, reason, transfer type, current status, summary sections, generated time, source coverage, next action, risk, permissions, and acceptance state.
• Separate handoff summary data from assignment fields, notification records, comments, activity logs, transcript storage, approval records, and static page summaries.
• Design structured sections for situation, background, assessment, recommendation or request, attempted steps, open questions, action list, blockers, risks, deadlines, source links, and receiver confirmation.
• Implement accept, ask clarification, edit summary, refresh, regenerate, decline, reassign, hand back, copy summary, and source-open actions where the workflow allows them.
• Check source freshness and access before showing or accepting the summary.
• Represent generated, human-edited, stale, redacted, missing-source, failed-generation, failed-transfer, and partial-source states.
• Synchronize acceptance with assignment, queues, notifications, activity log, case status, and conversation first-responder state.
• Test long transcripts, sensitive data redaction, AI hallucination guardrails, missing attachments, mobile wrapping, high zoom, keyboard action order, screen reader section headings, and handoff across teams with different permissions.

Common Generated-UI Mistakes

• Sending only an assignment notification and calling it a handoff.
• Dumping the full transcript without current status, next action, or risk summary.
• Using an ordinary page summary instead of transfer-specific receiver context.
• Omitting who owns the next action after handoff.
• Showing generated summaries as verified facts without source links or freshness.
• Leaking confidential transcript, account, patient, or case details across permission boundaries.
• Letting summaries go stale after the underlying conversation or case changes.
• Failing to provide a way for the receiver to clarify, decline, or hand back.

Critique Questions

• Who or what is handing off, who receives it, and what responsibility changes?
• Can the receiver understand current status, prior attempts, open questions, blockers, risks, and next action without rereading the raw history?
• Which summary claims link to transcript, ticket, case, log, or attachment evidence?
• Is the summary generated, edited, stale, redacted, or permission-limited, and is that visible?
• What happens if the receiver declines, needs clarification, lacks access, or hands the item back?
• Would assignment, summary box, activity log, comments, notification center, approval workflow, review queue, share dialog, or permission-denied state better own this surface?