A customer asks an AI assistant to move an appointment. The assistant understands the request, checks the policy and routes the conversation to a scheduling specialist. The specialist responds politely. Everyone appears to have done their part.
But the appointment is still unchanged.
This is a useful test of multi-agent architecture: what exactly moved when one agent handed work to another? A transcript? A recommendation? Or an accountable piece of work with a state, an owner and a definition of done?
A transfer of conversation control is not necessarily a transfer of operational responsibility. If a business expects an AI system to finish work, the handoff needs an explicit contract.
The handoff that looks successful
Consider an illustrative customer-service workflow. A front-line agent receives a rescheduling request. It identifies the intent and sends the case to an appointment agent. The second agent can see the conversation and knows the requested new time. It attempts a calendar update, but the booking API times out.
What happens next determines whether this is a dependable workflow or a convincing demonstration. The original agent may have ended its turn. The specialist may be waiting for a retry. The customer may believe the change is complete. Unless the application has a durable record of the work, there may be no reliable place to ask: who owns this request now?
Microsoft Agent Framework documentation distinguishes a handoff, where control moves to the receiving agent, from an agent-as-tool pattern, where the primary agent remains responsible. That describes orchestration behavior, not a guarantee that a business operation was completed. [1]
What a work contract needs to carry
A useful handoff is more precise than please handle this. For a business workflow, the receiving side should have enough structured information to accept, perform or reject the assignment. The following is an illustrative application-level contract, not a standard imposed by any particular framework.
Work ID and business scope. A stable identifier connects every attempt, update and audit event to the same customer request. Tenant, customer and actor references identify the relevant business record without copying unnecessary sensitive data into a prompt.
Requested outcome. Move this booking to Tuesday at 3 PM, subject to availability is a testable outcome. Help the customer with scheduling is not.
Current state and owner. The system should distinguish offered, accepted, blocked, completed and failed work. A proposed recipient is not the same as an accepted owner.
Dependencies and boundaries. The contract identifies the booking reference, approval requirements, expiry or escalation conditions, and which service can perform the change. Permissions still need to be enforced by the receiving application or tool.
Evidence of completion. A successful business-system response is stronger evidence than an agent saying it tried. For example, the booking service might return a confirmed updated booking version.
Retry identity. If the operation can be retried, use a stable request identity. An idempotency key or equivalent mechanism reduces duplicate side effects only when the receiving system supports and correctly enforces deduplication.
The contract should be small. It is not a license to copy an entire customer history into every specialists context. OpenAI Agents SDK documentation notes that a handoff can forward prior conversation history unless the application filters it. This is another reason to distinguish a structured work record from the text supplied to a model. [2]
Acceptance is the missing step
For many workflows, the safer design is a two-stage transfer: offer the work, then record acceptance. This is a recommended application pattern, not a claim that every agent framework implements it automatically.
A front-line agent creates a work item with an owner of record. The orchestrator offers it to a specialist. The specialist or its supervising service checks that it can take the job, then acknowledges the assignment. Only after that acknowledgement does the system change the responsible owner. The ownership change and acceptance acknowledgement should be recorded consistently, using an atomic state transition or equivalent coordination, so crashes or concurrent handoffs cannot leave ownership ambiguous. If acceptance definitively fails, the original owner or a fallback queue retains accountability. If an acknowledgement times out or is lost, the sender must first consult the durable work record: acceptance may already have been recorded. Recovery follows the recorded owner and state, rather than blindly reassigning the job.
This prevents an ambiguous interval in which the sender believes it has delegated the job while the receiver has not actually taken responsibility.
The record then moves through states such as accepted, in progress, awaiting confirmation, completed or failed. State transitions should be observable, and sensitive operations still need separate authorization. The agents prose is not the system of record. The same principle applies to knowledge access: retrieving relevant information does not itself authorize an action, as discussed in Why AI Agents Fail Without Business Context. [4]
A failure case worth designing first
Return to the rescheduling example. The booking API times out after the specialist submits the change. A blind retry may repeat the operation if the receiving system does not reliably recognize duplicate requests. An idempotency key or equivalent mechanism can reduce that risk when supported and correctly enforced. Declaring failure could also mislead the customer if the first request succeeded.
The application should reconcile the external booking state using a stable request or booking identifier. If the outcome is still unknown, the work item remains unresolved and assigned. A human or recovery process can investigate. The work should be marked completed only after the required outcome is verified against the authoritative business system. A confirmed rejection or cancellation may close the work under a different terminal status, but must not be recorded as successful completion.
Durable workflow systems demonstrate why execution history matters. Temporal documents event histories that allow workflows to recover after worker failures. That is evidence for the value of persistent workflow state, not a requirement to use Temporal for every multi-agent application. [3]
The operational question is simple: after a crash, deployment or timeout, can the business recover the work without asking the customer to start again?
What leaders should ask before adding more agents
Adding specialist agents can improve separation of responsibilities, but it also creates more transfer points. Before approving a multi-agent design, ask for one end-to-end demonstration in which a handoff fails.
Show the work item before transfer. Show who owns it while the receiver is unavailable. Show the retry or escalation. Show the external systems confirmation. Finally, show what the customer sees while the outcome is pending.
This is the difference between a convincing demonstration and verified business completion. A system that handles the happy path may still lose work at the boundary between agents. A system that can account for unfinished work is much closer to being ready for real operations.
For teams assessing how agents connect to existing operations, Digital Inspirons AI & Automation approach starts with the business outcome and the systems required to deliver it.
The takeaway
An agent handoff is not complete just because the next agent received a message. For business workflows, responsibility must be accepted, progress recorded and the requested outcome verified.
More agents are not the measure of a better system. Clearer ownership of the work is.