Microsoft、エージェントのオーケストレーションをコードから分離

Most multi-agent apps wire every flow in application code: the sequence of steps, branching, and handoffs between agents all live inside the program, making the orchestration harder to review, version, and change.

Declarative workflows make that orchestration explicit. In YAML, you define how agents coordinate, how state changes, where execution branches, and when people step in. Agent Framework loads the definition into a standard workflow you can run, stream, and compose with code.

Today, declarative workflows reach 1.0 across both Agent Framework SDKs. Python’s agent-framework-declarative package is now 1.0.0, joining the already-stable .NET Microsoft.Agents.AI.Workflows.Declarative package.

Why teams choose declarative workflows

Declarative workflows separate orchestration from application logic, and that separation pays off well beyond cleaner code. Because the workflow is a document rather than a call graph, product owners, solution architects, and developers can review how a workflow behaves without reading framework code. Updating an approval step, adding a new agent handoff, or changing branching logic often becomes a YAML change rather than a code change; something you can diff, review, and ship on its own.

You give up nothing at runtime. A declarative workflow loads into the same Workflow type as a code-first one, so it runs, streams, and composes just the same.

Author in YAML, run as an ordinary workflow

Consider a support desk that routes each incoming request to the right specialist. The entire orchestration is a short, readable list of steps: a triage agent classifies the request, and a condition routes it to the billing, sales, or support agent.

kind: Workflow

trigger:

kind: OnConversationStart

id: support_router

actions:

# A triage agent classifies the incoming request.

• kind: InvokeAzureAgent

id: triage

conversationId: =System.ConversationId

agent:

name: TriageAgent

output:

responseObject: Local.Triage

# Route to the specialist that matches the category.

• kind: If

id: route

condition: =Local.Triage.Category = "Billing"

then:

• kind: InvokeAzureAgent

id: billing

agent:

name: BillingAgent

else:

• kind: If

condition: =Local.Triage.Category = "Sales"

then:

• kind: InvokeAzureAgent

id: sales

agent:

name: SalesAgent

else:

• kind: InvokeAzureAgent

id: support

agent:

name: SupportAgent

The routing lives in the definition, not in application control flow. To add a category or reorder the checks, you edit the list; no executors to rewire.

In Python, use WorkflowFactory to load the YAML definition and create a Workflow instance:

from agent_framework.declarative import WorkflowFactory

factory = WorkflowFactory()

workflow = factory.create_workflow_from_yaml_path("support_router.yaml")

workflow is a standard Workflow - run, stream or compose it like any other.

The agents it names (TriageAgent, BillingAgent, ...) live in your Foundry project.

In .NET, use DeclarativeWorkflowBuilder to load the workflow definition and create a Workflow instance:

using Microsoft.Agents.AI.Workflows;

using Microsoft.Agents.AI.Workflows.Declarative;

// options carries your agent provider and configuration; see the sample for setup.

Workflow workflow = DeclarativeWorkflowBuilder.Build<string>("CustomerSupport.yaml", options);

// From here, run or stream workflow like any other workflow.

These snippets focus on loading the workflow definition. For the full, runnable version of this pattern (with ticketing, escalation, and a human handoff); see the customer support sample (Python, .Net).

What you can build

The router workflow above is intentionally small, but the same building blocks carry real multi-agent work. Each capability has a runnable sample in the repository:

State and expressions: Store values in workflow state and compute new values with Power Fx expressions, such as =If(IsBlank(inputs.name), "World", inputs.name) (sample).

Control flow: Branch on workflow state or agent results using conditions, loops, and jumps (sample).

Agent invocation: Invoke agents and route their responses, from sequential pipelines (marketing) to conditional routing (customer support).

Function, MCP, and HTTP tools: Call application code (function tools, MCP, HTTP) from a step.

Human-in-the-loop: Pause for input or approval and continue when the person responds (sample).

Checkpoint and resume: Persist workflow state and resume execution later (sample).

Declarative definitions load as standard Workflow instances, so you can run and compose them with code-first workflows. Use YAML where it fits and the lower-level APIs when you need custom behavior.

Get started

Install the package for your SDK:

pip install agent-framework-declarative

dotnet add package Microsoft.Agents.AI.Workflows.Declarative

Key takeaways

Declarative workflows give you a way to define orchestration as data rather than code. Author workflows in YAML, review them like configuration, version them with your application, and execute them using the same runtime that powers code-first workflows. With 1.0 now available across Python and .NET, you can confidently build production multi-agent orchestrations while choosing the authoring style that best fits your team.

Explore the documentation and runnable samples:

Docs: Declarative workflows overview

Python samples: python/samples/03-workflows/declarative

.NET samples: dotnet/samples/03-workflows/Declarative

Try a declarative workflow for an orchestration you would otherwise implement in code, then show us what you build. If you have ideas for what should come next, open an issue on GitHub. Thanks for building with us.

The post Move Agent Orchestration/Workflows out of Code with Agent Framework Declarative Workflows 1.0 appeared first on Microsoft Agent Framework.