Skip to content

Add handoff agent-workflow builder (implements #520)#545

Draft
PratikDhanave wants to merge 1 commit into
microsoft:mainfrom
PratikDhanave:feat-handoff-workflow-builder
Draft

Add handoff agent-workflow builder (implements #520)#545
PratikDhanave wants to merge 1 commit into
microsoft:mainfrom
PratikDhanave:feat-handoff-workflow-builder

Conversation

@PratikDhanave

@PratikDhanave PratikDhanave commented Jul 18, 2026

Copy link
Copy Markdown
Contributor

Implements the handoff orchestration gap from #520. Opening as a draft to align on the API/mechanism before finalizing — happy to adjust to the team's steer (the design questions in #520 are resolved here with sensible defaults, noted below).

What

A first-class handoff builder alongside the existing sequential / concurrent / group-chat builders:

wf, err := agentworkflow.NewHandoffWorkflowBuilder(triage, billing, refunds).
    WithHandoff(triage, billing, refunds). // triage may hand off to billing or refunds
    WithHandoff(billing, triage).          // billing may hand back to triage
    WithOutputFrom(triage, billing, refunds).
    Build()

A handoff workflow is a group chat whose next speaker is chosen by the current agent: each agent is given a handoff_to_<target> tool for every target it may hand off to; calling that tool routes the shared conversation to the target. The first agent is the entry agent; a turn with no handoff call ends the workflow.

How (reuse, not a new engine)

  • NewHandoffWorkflowBuilder injects per-agent handoff tools and supplies a handoff-flavored GroupChatManager whose SelectNextAgent routes on the most recent handoff tool call in the previous speaker's turn (a cursor tracks per-turn scanning and is checkpoint-persisted, mirroring the round-robin manager's NextIndex).
  • Rides the existing groupChatHostExecutor, edges, output designations, and prefixingWorkflowContext checkpoint plumbing.
  • One additive change to agentworkflow.Config: a RunOptions []agent.Option field so the builder can inject the handoff tools into each hosted agent's run (hosting.go). No existing signatures change.

Design decisions (the open questions from #520)

  1. Tools, not edges.NET-faithful auto-injected handoff_to_<target> function tools. Because they carry a handler they auto-execute, so the (resolved) call flows into history for the manager to read — no InterceptUnterminatedFunctionCalls needed.
  2. Reuse the group-chat manager — handoff is a GroupChatManager variant; no duplicate engine.
  3. Termination — a turn with no handoff call ends the workflow (plus the host's existing 40-turn safety cap).
  4. Return-to-previous — supported by declaring reverse handoffs (WithHandoff(billing, triage)).
  5. Scope — handoff only; Magentic tracked separately.

Tests

handoff_test.go (white-box, matching this package's convention) covers: routing on a handoff call, hand-back (triage→billing→triage), no-handoff termination, builder validation (nil/non-participant agents & targets), and handoff-manager checkpoint restore. All green under -race -shuffle=on; full suite passes. Updates docs/dotnet-go-sdk-feature-comparison.md.

Open for steer

Naming (WithHandoff vs edge-style), whether handoff instructions should be auto-added to agent system prompts (.NET does), and whether to add an examples/03-workflows sample once the API is agreed — I'll follow up per the team's preference.

…uilder)

Implements the handoff orchestration gap tracked in microsoft#520. A handoff
workflow is a group chat whose next speaker is chosen by the current
agent itself: each agent is given a handoff tool for every target it may
hand off to, and calling that tool routes the shared conversation to the
target. The first agent is the entry agent; a turn with no handoff call
ends the workflow.

Reuses the existing group chat host executor and GroupChatManager
plumbing rather than introducing a new engine: NewHandoffWorkflowBuilder
injects per-agent handoff tools and supplies a handoff-flavored manager
whose SelectNextAgent routes on the most recent handoff tool call in the
previous speaker's turn. Adds a RunOptions field to the hosting Config so
the builder can inject those tools into each hosted agent's run.

Mirrors the existing builders' API (WithName/WithDescription/WithHandoff/
WithOutputFrom/Build) and the round-robin manager's checkpoint pattern.
Covers routing, hand-back, no-handoff termination, builder validation,
and manager checkpoint restore. Updates the .NET/Go feature comparison.

Implements microsoft#520
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant