Microsoft Agent Framework Workflows support ships with agent-framework-core.

To install with visualization support:

pip install agent-framework-core graphviz

To export visualization images you also need to install GraphViz.

Begin with the _start-here folder in order. These three samples introduce the core ideas of executors, edges, agents in workflows, and streaming.

Once comfortable with these, explore the rest of the samples below.

Write workflows as plain Python async functions — no graph concepts, no executor classes, no edges. Use native control flow (if/else, loops, asyncio.gather) for branching and parallelism.

Builder-oriented request-info samples are maintained in the orchestration sample set (sequential, concurrent, and group-chat builder variants).

Builder-based tool approval samples are maintained in the orchestration sample set.

For additional observability samples in Agent Framework, see the observability concept samples. The workflow observability sample demonstrates integrating observability into workflows.

Orchestration-focused samples (Sequential, Concurrent, Handoff, GroupChat, Magentic), including builder-based workflow.as_agent(...) variants, are documented in the orchestrations directory.

Workflow Output selection controls which ctx.yield_output(...) calls are visible to callers as type='output' events and through WorkflowRunResult.get_outputs(). The core rule is that output_from is an allow-list for Workflow Output, not a routing rule for every other executor output. Unselected executor payloads are hidden unless intermediate_output_from explicitly selects them as Intermediate Output.

Use output_from and intermediate_output_from as the canonical API:

Invalid selections fail at construction or build time:

Compatibility aliases such as output_executors emit deprecation warnings where supported. New samples and applications should use output_from and intermediate_output_from.

When a workflow is wrapped with workflow.as_agent(), Workflow Output becomes normal agent text content. Intermediate Output becomes text_reasoning content, so AgentResponse.text remains focused on the caller-facing answer while callers can still inspect progress or supporting work from the response messages.

YAML-based declarative workflows allow you to define multi-agent orchestration patterns without writing Python code. See the declarative workflows README for more details on YAML workflow syntax and available actions.

• Sample text inputs used by certain workflows:
  • resources/long_text.txt
  • resources/email.txt
  • resources/spam.txt
  • resources/ambiguous_email.txt

Notes

• Agent-based samples use provider SDKs (Azure/OpenAI, etc.). Ensure credentials are configured, or adapt agents accordingly.

Sequential orchestration uses a few small adapter nodes for plumbing:

• "input-conversation" normalizes input to list[Message]
• "to-conversation:" converts agent responses into the shared conversation
• "complete" publishes the Workflow 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.

Workflow and orchestration samples use FoundryChatClient because they create agents locally and do not need server-managed agent resources. This lightweight, project-backed chat client is a good fit for orchestration patterns such as Sequential, Concurrent, Handoff, GroupChat, and Magentic.

If you need persistent server-side agent resources, use the hosted-agent flows rather than these workflow samples.

Workflow samples that use FoundryChatClient expect:

• FOUNDRY_PROJECT_ENDPOINT (Microsoft 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.