Handoff Orchestration: Routing Ownership with Microsoft Agent Framework

In our previous episode, we moved from parallel review to a moderated room. Security, Compliance, Finance and Customer Success challenged one another until a Chair could call time. That was the right pattern because the work improved through discussion. But not every problem needs a meeting.

Sometimes a customer has one unfolding problem and the system simply needs to make the next owner unmistakable. A cancelled flight starts as triage, becomes a rebooking problem, may turn into an overnight stay and ends with an insurance evidence question. The traveller should not have to repeat the story each time the expertise changes. That is where Handoff orchestration begins.

From a moderated room to visible ownership

Group Chat asks, "who should speak next?"

Handoff asks, "who owns this conversation now?"

That sounds like a small difference until you build the interface, the audit trail and the escalation boundary. In Group Chat, a manager coordinates turn-taking while the participants remain in the room. In Handoff, control itself moves. The receiving specialist is not advising the first agent from the sidelines. It becomes responsible for the next turn.

The Microsoft Agent Framework Handoff documentation describes a mesh-style orchestration where agents can transfer control according to the request and the conversation context. That shape works well for customer support because the point is not consensus. The point is ownership.

For this episode, our example is Live Recovery, an AI-assisted travel disruption service. Maya Chen is stranded at Sydney Airport after QF11 to Los Angeles is cancelled. She has one checked bag, no confirmed rebooking and a medical appointment in Los Angeles at 2 PM the next day.

My Qantas flight QF11 from Sydney to Los Angeles was cancelled after two delays. It is 9 PM and I am still at Sydney Airport with one checked bag and no rebooking. I have a medical appointment in Los Angeles tomorrow at 2 PM. I need the earliest confirmed way home.

Ownership is the pattern

Let's understand the following model first.

Maya still sees one conversation. Behind the scenes, Journey Triage receives the request and transfers it to Flight Recovery. Flight Recovery owns the next turn and asks one relevant question i.e. can Maya take another airline or a connection? When Maya confirms that Qantas has not offered a flight and asks for someone who can authorise the fastest option, the AI mesh reaches a boundary. A real recovery employee, Alex Morgan, must take over that decision.

After Alex responds, ownership returns to the right AI specialist. In our walkthrough that is Travel Cover, because the next unresolved question is what Maya should retain for an insurance claim.

If you pause the system at any moment, the product should answer three questions without asking anyone to reconstruct the transcript:

1. Who owns the next response?
2. Why did ownership move here?
3. Is the workflow waiting for an agent, the traveller or a person?

If those answers are hidden, you do not have a production handoff experience. You have a chat transcript with changing names.

The specialists behind one journey

Live Recovery keeps the agent set deliberately small. Our example is not trying to model an airline. It is trying to make ownership visible.

This is a bounded mesh, not a free-for-all. Each route should exist because the business can explain it. More connections do not make the orchestration more intelligent. They make ownership harder to reason about.

Handoff is not agent-as-tools

This distinction matters because the two patterns can look similar from a distance.

In an agent-as-tools design, the primary agent remains in charge. It calls a specialist like a function, uses the result and continues speaking to the customer. That is useful when one agent owns the task and only needs specialist input. Whereas, handoff is stronger. The receiving agent takes control of the conversation. When Flight Recovery asks Maya about route flexibility, Flight Recovery owns that reply. Journey Triage is not quietly paraphrasing an answer from the background.

That difference should be visible in the product. Maya does not need to know the phrase "Handoff orchestration", but she should know who is helping her now. Accountability is part of the experience, not internal telemetry.

The AI mesh still needs rules

The Agent Framework builder keeps the orchestration shape readable. A start agent is selected, the allowed transfers are registered and the workflow is built.

AIAgent[] specialists =
[
    flightRecoveryAgent,
    stayAndGroundAgent,
    travelCoverAgent,
    loyaltyDeskAgent
];

Workflow workflow = AgentWorkflowBuilder
    .CreateHandoffBuilderWith(journeyTriageAgent)
    .WithHandoffs(journeyTriageAgent, specialists)
    .WithHandoffs(specialists, journeyTriageAgent)
    .WithHandoffs(specialists, humanSupportGateway)
    .Build();

The human support gateway in that mesh is not Alex pretending to be an agent. It is an internal routing signal. Its only job is to say that the current AI specialist has reached a decision boundary and to describe what a person needs to decide. The application then opens a separate human workflow.

That separation is important. A language model can recommend an escalation. It must not manufacture the human approval that the escalation exists to obtain.

There are two different pauses

Interactive Handoff is often explained as a workflow that stops when an agent needs more information from the user. Live Recovery does that when Flight Recovery asks Maya whether she can use another airline. The run waits, Maya replies and the same owner continues with the full context.

A human decision is a different kind of pause. Maya is not expected to answer it. The application must publish a work item for an operator, preserve the workflow state and continue only after that operator resolves the request. Agent Framework gives us a proper boundary for that with RequestPort:

RequestPort humanSupport =
    RequestPort.Create<HumanSupportRequest, HumanSupportResolution>(
        "HumanSupport");

Workflow workflow = new WorkflowBuilder(humanSupport)
    .AddEdge(humanSupport, humanSupportCompletion)
    .WithOutputFrom(humanSupportCompletion)
    .Build();

StreamingRun run = await InProcessExecution.RunStreamingAsync(
    workflow,
    request,
    CheckpointManager.Default,
    cancellationToken: cancellationToken);

await foreach (WorkflowEvent evt in run.WatchStreamAsync())
{
    if (evt is RequestInfoEvent pending)
    {
        // Put the request in the Recovery Operations queue.
        await queue.PublishAsync(pending.Request);
    }
}

When Alex claims the case, the customer sees his name rather than a vague "human agent" label. When he sends the decision, the application responds to the suspended request and the workflow continues:

HumanSupportResolution resolution = new(
    OperatorName: "Alex Morgan",
    Message: responseForMaya,
    NextOwnerId: "insurance");

await run.SendResponseAsync(
    pendingRequest.CreateResponse(resolution));

This is the crux of the demo. The AI-to-AI transfers and the human interruption are related, but they are not the same mechanism. Handoff routes model ownership. RequestPort creates an explicit request and response boundary outside that model conversation.

One case, two carefully different experiences

Maya's screen is intentionally quiet. She sees the disrupted route, her case reference, the current owner and the conversation. When ownership changes, the name and icon change with it. When Alex is reviewing the case, the reply box is locked and a clear status replaces the typing indicator. There is no operations queue, model reasoning or internal confidence score competing for her attention.

Alex sees the other side of the same case. His workspace contains only cases that need a person. The escalation brief states who requested help, why judgement is needed and what decision must be made. The recent conversation arrives with the case, along with the AI specialist's recommendation. Alex claims ownership, edits the response for Maya and chooses which AI specialist should own the next turn.

The result is not two dashboards displaying the same information. It is one workflow expressed through two roles. Maya needs clarity and continuity. Alex needs decision context and control.

That is also why our example does not show chain-of-thought. Alex receives a concise recommendation and the evidence behind the escalation, not a hidden reasoning transcript. Useful operational context is a product requirement, private model deliberation is not.

Context moves and ownership becomes data

When the receiving specialist starts from zero, the customer experiences the handoff as a reset. Live Recovery carries recent messages, the original request, urgency and trip reference into each turn. The human request adds a structured reason, decision and recommendation so Alex does not have to infer the escalation from prose.

The ownership changes are stored separately from the messages:

{
  "from": "Flight Recovery",
  "to": "Alex Morgan",
  "reason": "No confirmed rebooking; a medical deadline needs a human exception decision.",
  "status": "human-review"
}

That event is useful to the interface, audit trail and support team. Do not make future readers infer ownership from message order. Persist it directly.

A decision guide

Use Handoff when the difficult question is who should own the next turn. Stay with Group Chat when the answer improves through discussion, Concurrent when specialists can work independently and Sequential when the process is an ordered pipeline. Human involvement does not change that choice. It sharpens it. The workflow should hand over to a person when authority, risk or judgement leaves the agent mesh and it should say exactly what it is waiting for.

We have now moved from pipelines, to parallel review, to moderated discussion, to routed ownership. Each pattern is a different answer to the same engineering problem, "how do we stop agents from improvising the shape of the system?"

Handoff asks, "who owns this conversation now?"

Magentic orchestration asks, "who should plan, coordinate, verify and adapt the work as it unfolds?" That is where we go next.

Until next time.