A user delegates work to an agent. The agent plans, the progress indicator moves, and the system produces something.
When the work comes back, the user becomes the cleanup crew. What triggered the job, and what already got done? Which parts still need judgment? Should the next move be to edit, approve, or escalate? The return deserves as much design as the request.
Handoff is part of the work
Agentic products often focus on the moment work leaves the human. The return is part of the work too.
The moment the agent hands work back, the user inherits a different question: what happened, and do I need to worry about it?
“Done” isn’t the same as ready for a human. A handoff that transfers responsibility without transferring understanding is slop.
A useful pass-back answers five questions
Fill-in card
Five pass-back questions
Answer each question in the work the agent returns.
- What happened?
- Summarize the actions, changes, and completed steps.
- Why?
- Show the evidence, assumptions, and important tradeoffs without exposing an unreadable wall of internal reasoning.
- What remains uncertain?
- Mark weak claims, missing sources, unresolved decisions, and conditions that could change the result.
- What needs the human?
- Identify the decision, approval, judgment, relationship, or accountability that can’t be delegated.
- What happens next?
- Provide the right continuation—edit, approve, compare, escalate, apply, publish, or close. Continue, Improve, Explore, and Optimize don’t tell the user what will happen. Name the action and its object.
The pass-back should reduce orientation work, not create it. A draft handoff should make the user feel like the author, not the cleanup crew.
Context is part of the deliverable
Keep the trigger, object, source set, plan, completed actions, changes, permissions, and version history attached. An agent that forgets why it was doing the work the moment it hands off isn’t transferring ownership. It’s abandoning the job.
If the agent rerouted, name the trigger, not just the fact of a change. If it preserved partial work, say whether each piece is still valid, now stale, discarded, or waiting.
This is especially important when the handoff crosses people or systems. A support rep shouldn’t receive “agent failed.” They should receive the customer, goal, attempted steps, evidence, blockage, and safest next action.
Example
Five pass-back questions: a rerouted invoice
Invoice 284 reaches the matching step and cannot safely create an accounting entry. The agent returns the invoice with the information finance needs to resolve the match.
- What happened? Route changed at supplier match. No accounting record was created. Invoice 284 was preserved in the finance review queue, and the owner was notified.
- Why? The supplier name on the invoice doesn’t match the supplier record closely enough to create the accounting entry safely.
- What remains uncertain? Which supplier the invoice belongs to.
- What needs the human? “Choose the matching supplier.” Someone still has to resolve the supplier before the month can close.
- What happens next? The archive and receipt steps are waiting.
Handoff depth should match the stakes
A routine internal draft may need a short summary and diff. A customer-facing action may need evidence, tone review, policy checks, and explicit ownership. A production change may need tests, affected systems, rollback instructions, and approval history.
Don’t make every handoff heavy. Make the depth proportional to consequence and reversibility.
The pass-back should protect authorship
Clicking approve isn’t the same as being able to stand behind the result. Ownership needs evidence, context, and a real sense of the consequence. Not a button.
For identity-laden, relationship-sensitive, or public work, make the output easy to revise in the user’s own voice, with the consequences in view.
A pass-back checklist
Before an agent returns work:
0 of 8 done
