A handoff between systems is complete only when the receiving system acknowledges the work and its status is clear. Record what you sent, who or what received it, whether it was accepted, and whether the requested work finished. Acceptance does not mean the work is complete.
Follow one repair request between systems
An employee asks a service agent: “Check my keyboard replacement request against the approved equipment catalog and stock list, then route a fulfillment request to inventory. Do not mark the item as delivered.” The agent may read the service ticket and approved catalog, then submit a scoped request to the inventory workflow. It cannot record delivery.
The receiving system accepts the request but has not yet assigned an item. A complete status update could read:
Keyboard replacement — handoff status
- Sources checked: Service ticket, approved equipment catalog, and current stock response.
- Sent to: Inventory fulfillment queue.
- Receiving status: Accepted for processing; reference
REQ-184.- Completion status: Pending assignment and delivery confirmation.
- Boundary: The service agent has not marked the item as delivered.
The acknowledgment confirms that the next system took responsibility for processing. It is not evidence that the request has been fulfilled, and it is not a human approval of the agent’s decision.
The diagram shows human review outcomes; acknowledgment by the receiving system is a separate check.
Define the handoff contract
Before connecting workflows, agree on the information and state each side needs:
- Work identity: Give the request a stable reference that links the originating case to the receiving work item.
- Context: Send only the approved fields and evidence summary needed by the recipient. Identify the source record and the requested action.
- Receiving owner: Name the queue, team, or system responsible for the next step, plus an operational owner for exceptions.
- Acknowledgment: Define what proves receipt or acceptance. A network response, queued message, accepted work item, and completed task may represent different states.
- Status and result: Agree which pending, rejected, completed, or failed outcomes can be reported back and how they map to the originating request.
- Timeout, retry, and duplicates: Decide what happens if no acknowledgment arrives. Confirm whether a repeated request can create a second work item before retrying.
- Failure route: Identify who reconciles an unknown status, rejection, stale record, or partial completion.
For long-running work, the sender may receive an early acknowledgment and check for a later result through polling, an event, or another supported channel. Choose the pattern the receiving system actually supports. Do not show success just because the message was sent.
Respond when the receiving status goes missing
In the fictional keyboard workflow, inventory acknowledges REQ-184, but no assignment or completion update arrives by the agreed check time. The originating case is accepted and still pending, not complete. Check REQ-184 through the receiving system’s agreed status channel. If it remains pending, keep the original case open. If its status cannot be confirmed or the request was rejected, stop automatic retries and send the reference, last confirmed status, and check time to the inventory owner for reconciliation. Do not create a second request or mark the item delivered until the first request’s state is clear.
Record the handoff reference, status changes, timestamps, and recovery action so an operator can reconstruct the run; see AI Agent Observability: What to Track.
Distinguish a machine handoff from human review
A machine acknowledgment answers, “Did the receiving system accept this work?” A human review answers, “Is this action appropriate, and should it proceed?” One does not replace the other. In the keyboard example, an approved request might still need a person to decide whether a substitute item is acceptable; the inventory system’s receipt alone cannot make that judgment.
Test the normal completion, rejection, timeout, duplicate delivery, and partial-failure paths before expanding use. Keep the original request open or clearly pending while the receiving status is unknown. For human decision points, see human review for AI agents; for workflow scope, use a focused agent job brief.