Semantic Kernel multi-agent orchestration: choose by control contract

Key takeaways

• A group manager controls user input, termination, routing, and result filtering.
• Handoff rules become tools agents call to transfer control.
• Approval-required tools pause execution and emit a request event.
• Agent Framework workflows add checkpoint and resume support beyond Semantic Kernel Process and Team abstractions.

Semantic Kernel multi agent orchestration is easier to evaluate when the pattern name is not the starting point. We use a Pattern Control Contract instead: identify who chooses the next participant, who can stop the run, what pauses for approval, which history crosses a handoff, and what state can be resumed. That turns a promising demo into a set of control boundaries you can inspect. It also keeps agent count from standing in for architecture. If you need the broader taxonomy first, our guide to multi-agent orchestration patterns covers the surrounding design space.

Which Microsoft framework supports Semantic Kernel multi agent orchestration?

Microsoft Agent Framework provides a standard interface for building, orchestrating, and deploying AI agents. The same documentation describes it as the unified successor to Semantic Kernel and AutoGen. That successor relationship matters when an existing Semantic Kernel implementation meets a new multi-agent design: the choice is not just between two pattern labels inside one unchanged surface.

Agent Framework workflows can compose a Copilot SDK agent with Azure OpenAI, Anthropic, and other providers. This makes provider mix one concrete design input. It does not, by itself, resolve routing authority, approval placement, state ownership, or recovery. Those questions still belong to the workflow you build around the agents.

So which framework supports multi-agent orchestration? Microsoft Agent Framework does, through its standard agent and workflow interface. Semantic Kernel remains part of the practical starting point for this decision because its packages, agents, and migration material connect directly to that framework boundary. The useful question is therefore narrower than "Which name has orchestration?" Ask which documented surface exposes the controls your workload needs.

Our open-source AI agent frameworks guide can help place that Microsoft-specific decision beside other framework choices without turning a feature list into the architecture.

The package surface already crosses the framework boundary

The package names show why a clean conceptual boundary can be misleading. The semantickernel-agents-core package includes the ChatCompletionAgent class. In the same documented surface, semantickernel-api defines the Agent Framework's core agent abstractions. Semantic Kernel also provides a service library for getting started with the Agent Framework using OpenAI.

These three pieces play different roles:

• semantickernel-agents-core supplies ChatCompletionAgent.
• semantickernel-api supplies the core agent abstractions.
• The Semantic Kernel service library supplies an OpenAI starting path for Agent Framework.

That package map is more useful than treating "Semantic Kernel" and "Agent Framework" as two sealed boxes. It tells you which class and abstraction you are actually adopting. It also gives a migration review a concrete unit: inspect the package, class, and agent abstraction used at each boundary.

Package identity still does not answer who drives a multi-agent run. A class can represent an agent while routing remains elsewhere. The control contract starts when the workflow must choose whether to continue, ask the user, select another participant, or produce a result. That decision point is where group chat becomes an orchestration design rather than a collection of agent instances.

Who chooses the next agent in group chat?

In a group-chat design, the manager can concentrate four decisions in one contract. The documented group-manager methods can decide from chat history whether to request user input, whether to terminate, which agent runs next, and how to filter the result. Next-agent selection also receives participant descriptions.

Review that contract as an architecture boundary, not as a four-step loop:

The final column is the architecture review. It separates the manager's documented decision authority from state responsibilities that your implementation must assign. Put a component name beside each item. If an item has no owner, record it as a design risk. That exposes the ambiguity a turn sequence hides: choosing the next speaker can be clear while history updates, persistence, and accountability remain implicit.

Magentic One is a group-chat-like orchestration with a special group manager. A historical Semantic Kernel multi-agent demo provides another concrete control point: it configures AgentGroupChat with prompt-defined custom selection and termination strategies, then runs the chat through an InvokeAsync loop. That example locates the selection and stop rules. It does not establish comparative performance, failure behavior, or current API completeness.

How does handoff orchestration transfer control?

Handoff orchestration moves routing into a tool-mediated path. A specialized handoff executor registers handoff tools on agents from configured handoff rules. An agent can then transfer control by calling the relevant tool.

The executor owns the rest of that transition. It inspects the agent response for handoff tool calls and routes control to the target agent. Before the next agent receives the conversation history, the executor filters out the handoff-related function calls and tool results. Those internal workflow mechanics therefore do not enter the forwarded history and confuse the receiving model.

This contract differs from a group manager even when the visible result is the same agent taking the next turn. In the group-manager contract, a manager selects the participant from history and participant descriptions. In the handoff contract, an agent calls a registered tool and the executor routes to that tool's target. The control question is not merely who speaks next. It is where the routing decision is expressed and which component carries it out.

Deterministic steps can sit beside agents

A workflow does not have to make every step agentic. A manually built pipeline can mix hosted agents with deterministic executors. That gives the orchestration a place for fixed execution paths alongside model-driven participants.

Approval is one boundary with a named pause mechanism. When an approval-required tool is reached, the workflow pauses and emits a RequestInfoEvent containing ToolApprovalRequestContent. The pause is part of the execution contract, not an informal convention around an agent response. A UI or another workflow component can receive a specific request object rather than infer that approval is needed from prose.

The same workflow surface can expose selected participant outputs without treating every internal message as a final result. WithIntermediateOutputFrom marks those outputs with workflow.OutputTagIntermediate. This creates a named distinction between chosen intermediate output and the workflow's eventual completion.

Together, deterministic executors, approval events, and intermediate-output tags make three different boundaries explicit: fixed execution, a paused approval request, and output that should be surfaced before the final result. Our agent orchestration example provides another way to examine orchestration as an execution path rather than a diagram of agent roles.

Examples make state and approval visible

Semantic kernel agents examples are most useful when they reveal the machinery around the model calls. One Microsoft multi-agent learning sample demonstrates workflow-state tracking through an MCP server implementation. Another example in that learning material demonstrates human-in-the-loop approval workflows with UI coordination.

The state-tracking example gives the state boundary a concrete home: the MCP server implementation. The approval example gives the pause a visible coordination surface in the UI. Neither requires you to treat "human in the loop" or "stateful" as a free-standing capability label. You can point to the implementation responsible for the state and to the interface involved in the approval workflow.

These examples are demonstrations of named mechanics. They do not prove production readiness, behavior under retry, or recovery from interruption. That distinction is useful when reviewing a sample: record the mechanism it actually exposes, then leave any unshown operating behavior open for your own test.

For framework selection, this means an example can answer "Where is state tracked?" or "How is approval coordinated?" without answering "What resumes after failure?" Resume behavior needs its own documented control surface.

Session reuse and checkpoint storage are explicit migration choices

Migration makes continuity explicit. When porting Semantic Kernel code that relies on implicit session reuse, the documented pattern is to call agent.create_session() and pass the returned session into run calls. Session continuity is therefore represented by an object the caller creates and supplies.

Recovery has a separate boundary. For multi-agent orchestration, Microsoft Agent Framework workflows expose checkpoint and resume capabilities that Semantic Kernel Process and Team abstractions do not. A session and a checkpoint should not be treated as interchangeable labels: one claim covers explicit session reuse, while the other covers checkpoint and resume support in workflows.

Checkpoint storage also brings application responsibilities with it. In the documented Go surface, checkpoint managers serialize state as JSON. That state remains trusted application state. Filesystem checkpoint files should be protected and restricted to authorized processes. If you implement a custom checkpoint store, that store owns its access control, integrity, and durability guarantees.

Agent Framework workflows expose checkpoint and resume capability. Storage protections and guarantees remain part of the application contract. The selection test is concrete: identify the session passed to each run, the state captured by a checkpoint, and the store responsible for protecting it.

What can an orchestration trace reveal?

An orchestration trace can show the execution path that a final answer hides. Agent observability can record tool calls, reasoning chains, state transitions, memory reads and writes, model responses, and their execution sequence for a user request. This gives a debugging review more than the last model response.

Across a longer run, traces can connect model calls, retrieved context, tool activity, handoffs, and state changes across traces and sessions. That connected record can identify where execution diverged. For a multi-agent workflow, the useful unit is the chain of events around routing and state, not an isolated model call.

Operational telemetry adds another view. Tracking token use, model routing, tool-call volume, and cost per successful task can support budgets, detect runaway sessions, and tune run efficiency. These measures do not replace execution traces. They answer a different operating question about resource use across the run.

A compact trace inventory should therefore include:

• the ordered tool calls, model responses, and state transitions;
• memory reads and writes;
• retrieved context, handoffs, and state changes across sessions;
• token use, model routing, and tool-call volume;
• cost per successful task.

Observability does not choose the pattern or prevent failure. It makes the executed path available for inspection, which lets routing, state, and resource behavior become testable parts of the harness.

Use a framework-selection checklist before committing

Framework selection depends on the language ecosystem, the need for autonomous or deterministic orchestration, and the tradeoff between vendor simplicity and flexibility with added complexity. The checklist below connects those adoption questions to the control boundaries already exposed by the documented surfaces.

Framework-selection checklist

One more implementation boundary belongs beside the table. A custom agent that uses the documented declarative architecture must inherit from DeclarativeSpecMixin for YAML-based construction and be registered with @register_agent_type. That requirement is specific enough to test before a team commits to a declarative custom-agent path.

Choose the smallest framework surface that exposes the controls your workflow actually needs. Vendor simplicity can reduce choices, while added flexibility brings added complexity. Language and orchestration needs decide which side of that tradeoff fits the work.

Before you commit, compare this contract with our broader multi-agent orchestration patterns guide. If the terms around routing and coordination still blur together, review our agent orchestration glossary, then apply the checklist to the workflow you intend to operate.