Emerging

Context packet transfer

A compact briefing — what was tried, what is known, what the ask is — handed to the receiving human.

MTicket #4821Dana Ortiz · escalated by Milky Waiting for Billing · 0:40

Handoff from Milky

For Sam Okafor · built from the run, not the chat

The ask

Send Dana's $1,240 refund (invoice #8822) to her new card ending 0932, not the cancelled card ending 4417.

Known

Charged twice on 14 Aug: #8821 and #8822, 2 min apart payments log
Refund for #8822 created, held, not sent refund R-2290
Card 0932 added 12 Sep; 4417 reported lost 10 Sep account

Tried

Offered refund to 4417. Dana declined: card is cancelled.
Checked policy BIL-7: a new refund destination needs a person to verify it.

Still unknown

Is the name on card 0932 Dana Ortiz?

78 words · Dana: polite, 2nd contact this month, waiting 0:40

Already answered for you

Dana won't be asked these again.

✓Account emaildana@ortizstudio.co
✓Which charge#8822
✓Amount$1,240.00
✓Where to send itcard ending 0932
?Name on card 0932ask Dana

Try it: You're Sam, picking up an escalation. Read the one-screen brief instead of the transcript, then take it: your reply asks Dana only what nobody knows yet.

In the wild

How one product ships this pattern. Click a screenshot to enlarge it.

Intercom conversation with a yellow internal note headed Summary: a one-line Question followed by bullet points on what the customer wants, what they use, and who is already involved — Intercom
A workflow posts an AI summary note at handover, with the customer's question and what has already happened, so the teammate doesn't have to reread the thread.
Source: Intercom Help ↗

When to use

Escalations and shift handovers where the human's first minute is otherwise spent reconstructing.

Seen in

Support handoff summaries, on-call incident briefs, agent-to-analyst research packets.

For engineers

Generate the packet from structured run state, and cap length; noisy packets get skimmed.

Build prompt

A neutral, component-only prompt for a coding agent. Edit the stack block or anything else to fit your project, then copy it.

# Build the "Context packet transfer" pattern: `HandoffBrief`

## Stack (edit this block to match your project)
- React 18+ with TypeScript: one function component, typed props, no `any`.
- Tailwind CSS, using your design system's tokens if you have them.
- Presentational only: data comes in through props, decisions go out through callbacks. No fetching or global state inside.
- If your codebase already has conventions (naming, shared components, tokens), follow them over this spec.

## What the pattern is for
A compact briefing — what was tried, what is known, what the ask is — handed to the receiving human.

Use it when: Escalations and shift handovers where the human's first minute is otherwise spent reconstructing.

## What to build
A compact briefing for the person receiving escalated work: the ask, what is known (with where each fact came from), what was tried, what is still unknown, and what the customer has already answered. The raw transcript is kept as a secondary tab for audit. It renders in a ticket side panel or a handoff inbox.

### Props
- `ask`: string, the one thing the receiver needs to do, e.g. "Send the $1,240 refund to the new card ending 0932".
- `known`: Array<{ fact: string; source: string }>, facts the run verified, each with its record (log, account, policy).
- `tried`: Array<{ action: string; outcome: string }>.
- `unknown`: string[], open questions the receiver must resolve.
- `answered?`: Array<{ label: string; value: string }>, details the customer won't be asked again.
- `transcript`: Array<{ who: string; at: Date; text: string }>, the full record, shown only on its own tab.
- `meta`: { from: string; to?: string; waitingSince: Date; note?: string }, plus `wordLimit?`: number (default 120).
- `status`: "waiting" | "claimed" | "loading" | "error" and `claimedBy?`: { name: string; at: Date }.
- `onClaim()`, `onFlagInaccurate?(section: "ask" | "known" | "tried" | "unknown")` and `onTabChange?(tab)`: callbacks.

### States it must render
- Waiting: the Brief tab is open by default with the ask first, then Known, Tried, Still unknown, a word count and a waiting timer; Take this ticket is the primary action.
- Claimed: a line "You took this at 09:07" replaces the button.
- Already answered: a checklist of confirmed details, with anything still to ask marked with a question mark.
- Transcript tab: the full messages with a note that the brief is built from run state, not summarised from this.
- Loading and error: skeleton sections; on error the transcript tab still works.

### Interactions
- Take this ticket calls `onClaim` and moves focus to the ask.
- Tabs switch between Brief and Transcript (with the message count on the tab).
- Each section can be flagged as inaccurate via `onFlagInaccurate`, so bad packets get fixed at the source.

### Edge cases
- Over `wordLimit`: show the count in amber and collapse list items beyond three per section behind "+2 more"; never pad to fill.
- Empty sections say so ("Nothing tried yet") rather than disappearing.
- Missing `ask`: render "No ask provided" as a visible problem instead of falling back to the transcript.
- A fact without a `source` gets an "unverified" marker.

## Must avoid
Dumping the raw transcript and calling it context, so the reviewer does the summarising.

## Engineering constraint
Generate the packet from structured run state, and cap length; noisy packets get skimmed.

## Accessibility
- The ask is the brief's heading so it is read first; tabs follow the tablist pattern.
- The waiting timer is not announced each tick; announce only when the status changes.

## House rules
- Real `<button>`/`<input>` elements, full keyboard use, visible focus; announce status changes with `aria-live="polite"`; respect `prefers-reduced-motion`.
- All user-facing text comes from props (or a `labels` prop) so it can be translated.
- One consistent accent marks anything the AI made or is doing; amber means "needs a person", red means risky, green means done. Never rely on colour alone.
- Fits a 360 px wide container without horizontal scrolling.

## Acceptance checks
- [ ] Every state above can be rendered by passing props, with no internal fake data.
- [ ] Every interaction and edge case above behaves as described.
- [ ] Nothing in "Must avoid" can happen with this component.

## Deliver
1. The component file with its exported prop types.
2. A short usage example that renders each state.

Download this prompt as Markdown, or every prompt as JSON for an agent.

Critique checklist for human handoff

0 of 4 checked

These questions apply to every pattern in this family. Ticks are saved in this browser.

Does the human receive the full context, unprompted?
Is the wait between handoff and pickup visible?
Can the user force a human at any moment?
Can work return to the agent cleanly afterwards?