Gap
docs/dotnet-go-sdk-feature-comparison.md marks the agent-workflow builders as Partial: Go has NewSequentialWorkflowBuilder, NewConcurrentWorkflowBuilder, and NewGroupChatWorkflowBuilder, but the doc notes "Handoff and Magentic builders are not yet implemented." There is no handoff reference anywhere in workflow/ or agent/ today.
Handoff is the missing member of the core orchestration set and the more broadly useful of the two gaps: a triage/router agent hands control to a specialist based on the conversation; the specialist can hand back, or on to another agent.
Proposed shape (seeking design alignment before any code)
A sibling builder in workflow/agentworkflow, matching the existing builders' convention (New…WorkflowBuilder(agents ...*agent.Agent), WithName / WithDescription / WithOutputFrom, Build() (*workflow.Workflow, error)):
agentworkflow.NewHandoffWorkflowBuilder(triage).
WithHandoff(triage, billing, refunds).
WithHandoff(billing, triage).
Build()Modeled on .NET's HandoffBuilder (Microsoft.Agents.AI.Workflows): each participating agent is given handoff tools (one per allowed target); when the agent calls a handoff tool, the workflow routes the turn to that target carrying the shared conversation. Under the hood it should compose onto the existing executor graph / group-chat manager plumbing rather than introduce a new engine.
Design questions I'd want the team's steer on first
- Handoff surfaced as auto-injected function tools (the .NET approach), vs. an edge condition on the agent's chosen target?
- Reuse the group-chat manager machinery, or a dedicated handoff executor?
- Termination: an explicit end agent, a max-turns cap, or a "no handoff called → done" signal?
- Scope handoff only for this issue; track Magentic separately?
Why I'm asking first
This is a feature, not a bug fix, so I don't want to drop an unsolicited large PR that then rots. If the team is open to it and we can agree on the shape (tools-vs-edges especially), I'm happy to implement it with the same test rigor as the recent fixes, matching the .NET semantics for cross-SDK parity.
Gap
docs/dotnet-go-sdk-feature-comparison.mdmarks the agent-workflow builders as Partial: Go hasNewSequentialWorkflowBuilder,NewConcurrentWorkflowBuilder, andNewGroupChatWorkflowBuilder, but the doc notes "Handoff and Magentic builders are not yet implemented." There is nohandoffreference anywhere inworkflow/oragent/today.Handoff is the missing member of the core orchestration set and the more broadly useful of the two gaps: a triage/router agent hands control to a specialist based on the conversation; the specialist can hand back, or on to another agent.
Proposed shape (seeking design alignment before any code)
A sibling builder in
workflow/agentworkflow, matching the existing builders' convention (New…WorkflowBuilder(agents ...*agent.Agent),WithName/WithDescription/WithOutputFrom,Build() (*workflow.Workflow, error)):Modeled on .NET's
HandoffBuilder(Microsoft.Agents.AI.Workflows): each participating agent is given handoff tools (one per allowed target); when the agent calls a handoff tool, the workflow routes the turn to that target carrying the shared conversation. Under the hood it should compose onto the existing executor graph / group-chat manager plumbing rather than introduce a new engine.Design questions I'd want the team's steer on first
Why I'm asking first
This is a feature, not a bug fix, so I don't want to drop an unsolicited large PR that then rots. If the team is open to it and we can agree on the shape (tools-vs-edges especially), I'm happy to implement it with the same test rigor as the recent fixes, matching the .NET semantics for cross-SDK parity.