Where an agent should hand work back

A human handoff is a piece of the workflow, not a sentence saying someone can intervene. The agent needs a reason to stop, a way to preserve the work, and a route to a person who can make the next decision. That person needs enough context to act without reconstructing the entire run. The system then needs to resume from the decision that was actually made.

Start by separating two situations. An approval happens before a planned action that requires authorization. An exception happens because the workflow cannot continue as expected. They may share an interface, but they ask different questions. Approving a prepared customer message is different from resolving a missing account identifier, and the reviewer should be able to tell which kind of work is waiting.

Mark decisions by their effect

Draw the workflow and mark each step that changes something outside the agent's private working area. Sending a message, changing a customer record, publishing content, and committing a purchase each create consequences beyond a draft. Decide which of those actions require a person and under what conditions. Keep the decision specific to the task and the organization's authority model.

Also mark places where the information may be insufficient. A source could be missing, a policy could conflict with a newer document, or the requester could ask for something outside the workflow. The agent should have an explicit route for those situations. Asking it to continue until it finds an answer can turn a missing fact into a plausible invention.

Give each queue a responsible role

A queue needs an owner and a backup. That may be the on-duty support lead, the project coordinator, or a named team responsible for a particular class of requests. Choose a role that has both the knowledge and authority to decide. A generic notification to a large channel can leave everyone assuming someone else will respond.

Define what happens when nobody is available. The item might remain pending, be reassigned after a specified interval, or return a request for more information. Silence should not count as approval. If a customer is waiting, the customer-facing status should describe the delay truthfully. The internal queue should preserve the reason for waiting so the next person can act without searching through unrelated messages.

Build the review packet

Show the proposed action first. Then show the relevant evidence, the records affected, unresolved questions, and the result of approving. A reviewer should be able to compare the proposal with the original request. For an email, display the actual recipient and complete message. For a record change, show the current value and proposed value. Avoid requiring the reviewer to infer the effect from a broad summary.

Keep supporting context focused. A full raw trace can be available for investigation, but it should not be the only review interface. The person deciding needs the information that bears on the choice. Excess detail can make an approval feel routine and encourage clicking through. A short explanation of why the item needs attention is often more useful than a long narrative of every tool call.

Work through an approval example

Consider a fictional project assistant that prepares a schedule update for a client. It has gathered the current milestones and drafted a message, but sending requires the project lead's approval. The review packet includes the client address, the complete draft, the source record for each date, and a note that one milestone is still provisional. The lead can edit the wording, reject the draft, or request clarification.

If the lead edits a date, the workflow should not assume the rest of the action remains valid automatically. It should validate the edited result and preserve the decision. If the source record changes while approval is pending, the old approval may no longer apply. The system needs a rule for detecting that change and asking for a fresh review where necessary.

Preserve the work across the pause

A handoff may wait longer than the process that created it. Store the pending item durably, with an identifier that lets the application find the correct state. Keep enough information to distinguish a waiting action from a completed one. A reviewer returning the next morning should not find an approval button attached to work that disappeared when a server restarted.

LangGraph's persistence documentation describes checkpoints that support inspection and resumption of graph state. Whatever implementation you choose, test the operational requirement directly: stop the application while an item waits, restart it, and verify that the right person can still review the right proposal. A working pause in a local demo does not answer that question.

Make resumption deliberate

When approval arrives, verify that the person is authorized and that the request still refers to the current proposal. Record the decision and any edits. The system should carry out only the approved action, then confirm the actual result. If execution fails, return an accurate status rather than treating approval itself as proof that the action happened.

The LangGraph interrupt reference notes that resuming can rerun code before the interrupt within a node. That detail matters when an operation has side effects. Design and test the implementation so a resume or retry does not duplicate an external action. Similar care is needed in any system where messages or callbacks may be delivered more than once.

Give exceptions different paths

Not every exception needs the same reviewer. Missing input can often go back to the requester. Conflicting policy may belong with a policy owner. A denied connection may need an administrator. A suspected unauthorized action may require stopping the workflow while an operator investigates. Define these routes in the task brief so the agent does not invent an escalation destination at runtime.

Include the question the person must answer. Please review is weak compared with two approved sources disagree on the delivery date; confirm which date applies. A precise request reduces the amount of investigation and makes it easier to resume safely. If the person cannot resolve it, they should be able to reassign or close the case with a reason instead of leaving it in permanent limbo.

Measure the burden on people

Track how many items enter review, how long they wait, and how often the reviewer changes or rejects the proposal. Interpret these measures together. A low rejection rate may indicate good proposals, but it may also reflect rushed review. A long queue may mean the system is producing too many low-value escalations or that the assigned role has no time to handle them.

Inspect a sample of decisions with the people doing the work. Ask which information was missing and which handoffs could have been resolved earlier by better input validation. Improve the workflow where those patterns are clear. The aim is to make human judgment useful at the right moments, not to celebrate the number of times a person has to rescue a run.

Rehearse the awkward cases

Before launch, test an expired approval, a reviewer who lacks permission, a duplicate callback, a rejected proposal, and a source record that changes while waiting. Verify the outcome in the destination system after resumption. Include a case where no one responds and confirm that the workflow remains pending or closes according to the defined rule.

Your next step is to mark the human decisions on one workflow map and write the review packet for each. Give those packets to the people who would receive them. If they cannot decide from the information provided, improve the packet or narrow the proposed action. A well-designed handoff respects both sides of the process: the agent knows where to stop, and the person knows what to do next.