* Fix orchestration outputs so as_agent() returns the final answer only. Align other orchestration outputs * Fix orchestration output issues from review comments 1. Sample cleanup: Remove commented-out FoundryChatClient block and update prerequisites to reference OPENAI_CHAT_MODEL_ID instead of FOUNDRY_* vars. 2. Sequential approval output: Change _EndWithConversation.end_with_agent_executor_response from a no-op sink to yield response.agent_response. When the last participant is AgentApprovalExecutor (via with_request_info), _EndWithConversation is the output executor so the yield produces the terminal answer. When the last participant is a regular AgentExecutor, _EndWithConversation is not in output_executors so the yield is silently filtered out. 3. Forward data events through WorkflowExecutor: _process_workflow_result now also forwards 'data' events from sub-workflows so that emit_intermediate_data=True on AgentExecutor works correctly when wrapped in AgentApprovalExecutor. 4. Concurrent docstring: Update _AggregateAgentConversations docstring to say 'deterministic participant order' instead of 'completion order'. 5. Add test_concurrent_intermediate_outputs_emits_data_events verifying that ConcurrentBuilder(intermediate_outputs=True) emits per-participant data events alongside the single aggregated output event. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Add tests for sequential workflow with_request_info and intermediate_outputs (#5301) Address PR review comments 2, 3, and 5: - Add test_sequential_request_info_last_participant_emits_output: Verifies that when the last participant is wrapped via with_request_info() (AgentApprovalExecutor), the workflow still emits a terminal output after approval, exercising the _EndWithConversation.end_with_agent_executor_response fallback path. - Add test_sequential_request_info_with_intermediate_outputs_emits_data_events: Verifies that emit_intermediate_data=True works correctly through AgentApprovalExecutor wrapping—WorkflowExecutor._process_result already forwards data events from sub-workflows, so intermediate agent responses surface as data events in the parent workflow. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix pyright type errors from AgentResponse output refactor (#5301) Update cast() calls in _group_chat.py and _magentic.py to use WorkflowContext[Never, AgentResponse] instead of the old WorkflowContext[Never, list[Message]], matching the updated method signatures in _base_group_chat_orchestrator.py. Fix _sequential.py _EndWithConversation.end_with_agent_executor_response to declare WorkflowContext[Any, AgentResponse] so yield_output accepts AgentResponse[None]. Fix _workflow_executor.py data event forwarding to handle nullable executor_id. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix pyright reportUnknownVariableType in _agent.py (#5301) Extract event.data into a typed local variable before the isinstance check to avoid pyright narrowing it to AgentResponse[Unknown]. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix pyright reportMissingImports for orjson in file history samples (#5301) Add pyright: ignore[reportMissingImports] to orjson imports that are already guarded by try/except ImportError, matching the existing pattern used elsewhere in the samples. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Address review feedback for #5301: review comment fixes * Address review feedback for #5301: review comment fixes * Revert sequential_workflow_as_agent sample to FoundryChatClient Reverts the mistaken switch from FoundryChatClient to OpenAIChatClient in the sequential workflow as agent sample. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Address ultrareview feedback: emit_data_events rename + WorkflowAgent reasoning conversion Layered on top of the prior review-feedback work in this branch. Renames: - AgentExecutor.emit_intermediate_data -> emit_data_events (mechanical rename; orchestration semantics live at the orchestration layer, not the general-purpose executor). Forwarded through MagenticAgentExecutor, AgentApprovalExecutor, and all orchestration call sites. - HandoffAgentExecutor._check_terminate_and_yield -> _should_terminate (pure predicate; no longer yields anything). HandoffBuilder docstring rewritten to describe the new per-agent AgentResponse output contract. WorkflowAgent reasoning-content conversion: - Add _rewrite_text_to_reasoning(contents) and _msg_as_reasoning(msg) helpers; the as_agent() path now reframes text content from data events as text_reasoning Content blocks before merging into the AgentResponse. - Consumers iterate msg.contents and branch on content.type — same path they already use for Claude thinking and OpenAI reasoning. No new field on Message/AgentResponse/WorkflowEvent. - Streaming branch constructs fresh AgentResponseUpdate instances instead of mutating shared payloads (regression test added). - Helper _msg_maybe_reasoning consolidates the conditional rewrite at three call sites in the non-streaming conversion. Tests: - TestWorkflowAgentReasoningHelpers + TestWorkflowAgentDataEventReasoningConversion add 9 new tests covering helpers, non-streaming, streaming, mixed content, already-reasoning passthrough, and mutation-safety regression. - Updated test_sequential_as_agent_with_intermediate_outputs_includes_chain to assert text_reasoning content for intermediate agents. * Fix pyright: widen event.data to Any to avoid partial-unknown narrowing The streaming conversion path narrowed event.data via isinstance against generic AgentResponse, producing AgentResponse[Unknown] and tripping reportUnknownVariableType/reportUnknownMemberType. Binding data: Any before the check keeps runtime behavior identical while restoring a fully known type for downstream access. * Clean up design * Scope to agent output semantics only * yield AgentResponseUpdate streaming, AgentResponse non-streaming * Fix mypy/pyright: widen cast types at GroupChat callsites Eight callsites in _group_chat.py still cast to WorkflowContext[Never, AgentResponse] but the base orchestrator methods now accept the wider WorkflowContext[Never, AgentResponse | AgentResponseUpdate] (mode-aware yields). W_OutT is invariant, so the narrower cast is not assignable. Magentic was widened in the same commit; this catches the GroupChat callsites that were missed. * Python: skip flaky Foundry / Foundry Hosting integration tests (#5553) These two integration tests have been failing in the merge queue across multiple unrelated PRs (5301, 5531). Both are marked `@pytest.mark.flaky` with 3 retries, but all attempts fail back-to-back. Skipping both with a reason pointing to #5553 so they can be fixed properly without continuing to block unrelated merges. - packages/foundry_hosting/tests/test_responses_int.py::TestOptions::test_temperature_and_max_tokens - packages/foundry/tests/foundry/test_foundry_embedding_client.py::TestFoundryEmbeddingIntegration::test_text_embedding_live Also includes a one-line uv.lock specifier-ordering normalization auto-applied by the poe-check pre-commit hook. --------- Co-authored-by: Copilot <copilot@github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Orchestration Getting Started Samples
Installation
The orchestrations package is included when you install agent-framework (which pulls in all optional packages):
pip install agent-framework
Or install the orchestrations package directly:
pip install agent-framework-orchestrations
Orchestration builders are available via the agent_framework.orchestrations submodule:
from agent_framework.orchestrations import (
SequentialBuilder,
ConcurrentBuilder,
HandoffBuilder,
GroupChatBuilder,
MagenticBuilder,
)
Samples Overview (by directory)
concurrent
| Sample | File | Concepts |
|---|---|---|
| Concurrent Orchestration (Default Aggregator) | concurrent_agents.py | Fan-out to multiple agents; fan-in with default aggregator returning combined Messages |
| Concurrent Orchestration (Custom Aggregator) | concurrent_custom_aggregator.py | Override aggregator via callback; summarize results with an LLM |
| Concurrent Orchestration (Custom Agent Executors) | concurrent_custom_agent_executors.py | Child executors own Agents; concurrent fan-out/fan-in via ConcurrentBuilder |
| Concurrent Orchestration as Agent | concurrent_workflow_as_agent.py | Build a ConcurrentBuilder workflow and expose it as an agent via workflow.as_agent(...) |
| Tool Approval with ConcurrentBuilder | concurrent_builder_tool_approval.py | Require human approval for sensitive tools across concurrent participants |
| ConcurrentBuilder Request Info | concurrent_request_info.py | Review concurrent agent outputs before aggregation using .with_request_info() |
sequential
| Sample | File | Concepts |
|---|---|---|
| Sequential Orchestration (Agents) | sequential_agents.py | Chain agents sequentially with shared conversation context |
| Sequential Orchestration (Custom Executor) | sequential_custom_executors.py | Mix agents with a summarizer that appends a compact summary |
| Sequential Orchestration as Agent | sequential_workflow_as_agent.py | Build a SequentialBuilder workflow and expose it as an agent via workflow.as_agent(...) |
| Tool Approval with SequentialBuilder | sequential_builder_tool_approval.py | Require human approval for sensitive tools in SequentialBuilder workflows |
| SequentialBuilder Request Info | sequential_request_info.py | Request info for agent responses mid-orchestration using .with_request_info() |
group-chat
| Sample | File | Concepts |
|---|---|---|
| Group Chat with Agent Manager | group_chat_agent_manager.py | Agent-based manager using with_orchestrator(agent=) to select next speaker |
| Group Chat Philosophical Debate | group_chat_philosophical_debate.py | Agent manager moderates long-form, multi-round debate across diverse participants |
| Group Chat with Simple Selector | group_chat_simple_selector.py | Group chat with a simple function selector for next speaker |
| Group Chat Orchestration as Agent | group_chat_workflow_as_agent.py | Build a GroupChatBuilder workflow and wrap it as an agent for composition |
| Tool Approval with GroupChatBuilder | group_chat_builder_tool_approval.py | Require human approval for sensitive tools in group chat orchestration |
| GroupChatBuilder Request Info | group_chat_request_info.py | Steer group discussions with periodic guidance using .with_request_info() |
handoff
| Sample | File | Concepts |
|---|---|---|
| Handoff (Simple) | handoff_simple.py | Single-tier routing: triage agent routes to specialists, control returns to user after each specialist response |
| Handoff (Autonomous) | handoff_autonomous.py | Autonomous mode: specialists iterate independently until invoking a handoff tool using .with_autonomous_mode() |
| Handoff with Code Interpreter | handoff_with_code_interpreter_file.py | Retrieve file IDs from code interpreter output in handoff workflow |
| Handoff with Tool Approval + Checkpoint | handoff_with_tool_approval_checkpoint_resume.py | Capture tool-approval decisions in checkpoints and resume from persisted state |
| Handoff Orchestration as Agent | handoff_workflow_as_agent.py | Build a HandoffBuilder workflow and expose it as an agent, including HITL request/response flow |
magentic
| Sample | File | Concepts |
|---|---|---|
| Magentic Workflow | magentic.py | Orchestrate multiple agents with a Magentic manager and streaming |
| Magentic + Human Plan Review | magentic_human_plan_review.py | Human reviews or updates the plan before execution |
| Magentic + Checkpoint Resume | magentic_checkpoint.py | Resume Magentic orchestration from saved checkpoints |
| Magentic Orchestration as Agent | magentic_workflow_as_agent.py | Build a MagenticBuilder workflow and reuse it as an agent |
Tips
Magentic checkpointing tip: Treat MagenticBuilder.participants keys as stable identifiers. When resuming from a checkpoint, the rebuilt workflow must reuse the same participant names; otherwise the checkpoint cannot be applied and the run will fail fast.
Handoff workflow tip: Handoff workflows maintain the full conversation history including any Message.additional_properties emitted by your agents. This ensures routing metadata remains intact across all agent transitions. For specialist-to-specialist handoffs, use .add_handoff(source, targets) to configure which agents can route to which others with a fluent, type-safe API.
Handoff require_per_service_call_history_persistence: All agents in a handoff workflow must set require_per_service_call_history_persistence=True. HandoffBuilder.build() will raise a ValueError if any participant is missing this flag. This is required because handoff middleware short-circuits tool calls via MiddlewareTermination, and without per-service-call history persistence, local history would store tool results the service never received, causing mismatches on subsequent turns.
Sequential orchestration note: Sequential orchestration uses a few small adapter nodes for plumbing:
input-conversationnormalizes input tolist[Message]to-conversation:<participant>converts agent responses into the shared conversationcompletepublishes the final output event (type='output')
These may appear in event streams (executor_invoked/executor_completed). They're analogous to concurrent's dispatcher and aggregator and can be ignored if you only care about agent activity.
Why FoundryChatClient?
Orchestration samples use FoundryChatClient because they create agents locally and do not require
server-side lifecycle management. FoundryChatClient is a lightweight, project-backed client that fits
patterns like Sequential, Concurrent, Handoff, GroupChat, and Magentic.
Environment Variables
Orchestration samples that use FoundryChatClient expect:
FOUNDRY_PROJECT_ENDPOINT(Azure AI Foundry Agent Service (V2) project endpoint)FOUNDRY_MODEL(model deployment name)
These values are passed directly into the client constructor via os.getenv() in sample code.