PHP 8.5 brings several useful runtime improvements. It includes better diagnostics, with fatal errors now providing a backtrace, which can make troubleshooting easier. It also adds the pipe operator (|>) for cleaner, more readable code, along with broader improvements in syntax, performance, and type safety. You can take advantage of these improvements while continuing to use the deployment and management experience you already know in App Service.

For the full list of features, deprecations, and migration notes, see the official PHP 8.5 release page: https://www.php.net/releases/8.5/en.php

Getting started

1. Create a PHP web app in Azure App Service
2. Configure a PHP app for Azure App Service

Introduction

Enterprises running ASP.NET Framework workloads on Windows Server with IIS face a familiar dilemma: modernize or stay put. The applications work, the infrastructure is stable, and nobody wants to be the person who breaks production during a cloud migration. But the cost of maintaining aging on-premises servers, patching Windows, and managing IIS keeps climbing.

Azure App Service has long been the lift-and-shift destination for these workloads. But what about applications that depend on Windows registry keys, COM components, SMTP relay, MSMQ queues, local file system access, or custom fonts? These OS-level dependencies have historically been migration blockers — forcing teams into expensive re-architecture or keeping them anchored to VMs.

Managed Instance on Azure App Service changes this equation entirely. And the IIS Migration MCP Server makes migration guided, intelligent, and safe — with AI agents that know what to ask, what to check, and what to generate at every step.

What Is Managed Instance on Azure App Service?

Managed Instance on App Service is Azure’s answer to applications that need OS-level customization beyond what standard App Service provides. It runs on the PremiumV4 (PV4) SKU with IsCustomMode=true, giving your app access to:

The key constraint: Managed Instance on App Service requires PV4 SKU with IsCustomMode=true. No other SKU combination supports it.

Why Managed Instance Matters for Legacy Apps

Consider a classic enterprise ASP.NET application that:

• Reads license keys from HKLM\SOFTWARE\MyApp in the Windows Registry
• Uses a COM component for PDF generation registered via regsvr32
• Sends email through a local SMTP relay
• Writes reports to D:\Reports\ on a local drive
• Uses a custom corporate font for PDF rendering

With standard App Service, you’d need to rewrite every one of these dependencies. With Managed Instance on App Service, you can:

• Map registry reads to Key Vault secrets via Registry Adapters
• Mount Azure Files as D:\ via Storage Adapters
• Enable SMTP Server via install.ps1
• Register the COM DLL via install.ps1 (regsvr32)
• Install the custom font via install.ps1

Zero application code changes required.

Note: When migrating your web applications to Managed Instance on Azure App Service, in the majority of use cases zero application code changes may be required — but depending on your specific web app, some code changes may be necessary.

Microsoft Learn Resources

• Managed Instance on App Service Overview
• Azure App Service Documentation
• App Service Migration Assistant Tool
• Migrate to Azure App Service
• Azure App Service Plans Overview
• PremiumV4 Pricing Tier
• Azure Key Vault
• Azure Files
• Azure Migrate application and code assessment for .NET
• Install Azure Migrate application and code assessment for .NET
• Interpret the analysis results

Why Agentic Migration? The Case for AI-Guided IIS Migration

The Problem with Traditional Migration

Microsoft provides excellent PowerShell scripts for IIS migration — Get-SiteReadiness.ps1, Get-SitePackage.ps1, Generate-MigrationSettings.ps1, and Invoke-SiteMigration.ps1. They’re free, well-tested, and reliable. So why wrap them in an AI-powered system?

Because the scripts are powerful but not intelligent. They execute what you tell them to. They don’t tell you what to do.

Here’s what a traditional migration looks like:

1. Run readiness checks — get a wall of JSON with cryptic check IDs like ContentSizeCheck, ConfigErrorCheck, GACCheck
2. Manually interpret 15+ readiness checks per site across dozens of sites
3. Decide whether each site needs Managed Instance or standard App Service (how?)
4. Figure out which dependencies need registry adapters vs. storage adapters vs. install.ps1 (the “Managed Instance provisioning split”)
5. Write the install.ps1 script by hand for each combination of OS features
6. Author ARM templates for adapter configurations (Key Vault references, storage mount specs, RBAC assignments)
7. Wire together PackageResults.json → MigrationSettings.json with correct Managed Instance fields (Tier=PremiumV4, IsCustomMode=true)
8. Hope you didn’t misconfigure anything before deploying to Azure

Even experienced Azure engineers find this time-consuming, error-prone, and tedious — especially across a fleet of 20, 50, or 100+ IIS sites.

What Agentic Migration Changes

The IIS Migration MCP Server introduces an AI orchestration layer that transforms this manual grind into a guided conversation:

The core value proposition: the AI knows the Managed Instance provisioning split. It knows that registry access needs an ARM template with Key Vault-backed adapters, while SMTP needs an install.ps1 section enabling the Windows SMTP Server feature. You don’t need to know this. The system detects it from your IIS configuration and source code analysis, then generates exactly the right artifacts.

Human-in-the-Loop Safety

Agentic doesn’t mean autonomous. The system has explicit gates:

• Phase 1 → Phase 2: “Do you want to assess these sites, or skip to packaging?”
• Phase 3: “Here’s my recommendation — Managed Instance for Site A (COM + Registry), standard for Site B. Agree?”
• Phase 4: “Review MigrationSettings.json before proceeding”
• Phase 5: “This will create billable Azure resources. Type ‘yes’ to confirm”

The AI accelerates the workflow; the human retains control over every decision.

Architecture: How the MCP Server Works

The system is built on the Model Context Protocol (MCP), an open protocol that lets AI assistants like GitHub Copilot, Claude, or Cursor call external tools through a standardized interface.

┌──────────────────────────────────────────────────────────────────┐
│  VS Code + Copilot Chat                                          │
│    @iis-migrate orchestrator agent                               │
│      ├── iis-discover   (Phase 1)                                │
│      ├── iis-assess     (Phase 2)                                │
│      ├── iis-recommend  (Phase 3)                                │
│      ├── iis-deploy-plan (Phase 4)                               │
│      └── iis-execute    (Phase 5)                                │
└─────────────┬────────────────────────────────────────────────────┘
              │  stdio JSON-RPC (MCP Transport)
              ▼
┌──────────────────────────────────────────────────────────────────┐
│  FastMCP Server (server.py)                                      │
│    13 Python Tool Modules (tools/*.py)                           │
│      └── ps_runner.py (Python → PowerShell bridge)               │
│            └── Downloaded PowerShell Scripts (user-configured)    │
│                  ├── Local IIS (discovery, packaging)            │
│                  └── Azure ARM API (deployment)                  │
└──────────────────────────────────────────────────────────────────┘

The server exposes 13 MCP tools organized across 5 phases, orchestrated by 6 Copilot agents (1 orchestrator + 5 specialist subagents).

Important: The PowerShell migration scripts are not included in this repository. Users must download them from GitHub and configure the path using the configure_scripts_path tool. This ensures you always use the latest version of Microsoft’s scripts, avoiding version mismatch issues.

The 13 MCP Tools: Complete Reference

Phase 0 — Setup

configure_scripts_path

Purpose: Point the server to Microsoft’s downloaded migration PowerShell scripts.

Before any migration work, you need to download the scripts from GitHub, unzip them, and tell the server where they are.

"Configure scripts path to C:\MigrationScripts"

Phase 1 — Discovery

1. discover_iis_sites

Purpose: Scan the local IIS server and run readiness checks on every web site.

This is the entry point for every migration. It calls Get-SiteReadiness.ps1 under the hood, which:

• Enumerates all IIS web sites, application pools, bindings, and virtual directories
• Runs 15 readiness checks per site (config errors, HTTPS bindings, non-HTTP protocols, TCP ports, location tags, app pool settings, app pool identity, virtual directories, content size, global modules, ISAPI filters, authentication, framework version, connection strings, and more)
• Detects source code artifacts (.sln, .csproj, .cs, .vb) near site physical paths

Output: ReadinessResults.json with per-site status: | Status | Meaning | |——–|———| | READY | No issues detected — clear for migration | | READY_WITH_WARNINGS | Minor issues that won’t block migration | | READY_WITH_ISSUES | Non-fatal issues that need attention | | BLOCKED | Fatal issues (e.g., content > 2GB) — cannot migrate as-is |

Requires: Administrator privileges, IIS installed.

2. choose_assessment_mode

Purpose: Route each discovered site into the appropriate next step.

After discovery, you decide the path for each site:

• assess_all: Run detailed assessment on all non-blocked sites
• package_and_migrate: Skip assessment, proceed directly to packaging (for sites you already know well)

The tool classifies each site into one of five actions:

• assess_config_only — IIS/web.config analysis
• assess_config_and_source — Config + source code analysis (when source is detected)
• package — Skip to packaging
• blocked — Fatal errors, cannot proceed
• skip — User chose to exclude

Phase 2 — Assessment

3. assess_site_readiness

Purpose: Get a detailed, human-readable readiness assessment for a specific site.

Takes the raw readiness data from Phase 1 and enriches each check with:

• Title: Plain-English name (e.g., “Global Assembly Cache (GAC) Dependencies”)
• Description: What the check found and why it matters
• Recommendation: Specific guidance on how to resolve the issue
• Category: Grouping (Configuration, Security, Compatibility)
• Documentation Link: Microsoft Learn URL for further reading

This enrichment comes from WebAppCheckResources.resx, an XML resource file that maps check IDs to detailed metadata. Without this tool, you’d see GACCheck: FAIL — with it, you see the full context.

Output: Overall status, enriched failed/warning checks, framework version, pipeline mode, binding details.

4. assess_source_code

Purpose: Analyze an Azure Migrate application and code assessment for .NET JSON report to identify Managed Instance-relevant source code dependencies.

If your application has source code and you’ve run the assessment tool against it, this tool parses the results and maps findings to migration actions:

The tool matches rules from the assessment output against known Managed Instance-relevant patterns. For a complete list of rules and categories, see Interpret the analysis results.

Output: Issues categorized as mandatory/optional/potential, plus install_script_features and adapter_features lists that feed directly into Phase 3 tools.

Phase 3 — Recommendation & Provisioning

5. suggest_migration_approach

Purpose: Recommend the right migration tool/approach for the scenario.

This is a routing tool that considers:

• Source code available? → Recommend the App Modernization MCP server for code-level changes
• No source code? → Recommend this IIS Migration MCP (lift-and-shift)
• OS customization needed? → Highlight Managed Instance on App Service as the target

6. recommend_target

Purpose: Recommend the Azure deployment target for each site based on all assessment data.

This is the intelligence center of the system. It analyzes config assessments and source code findings to recommend:

Each recommendation comes with:

• Confidence: high or medium
• Reasoning: Full explanation of why this target was chosen
• Managed Instance reasons: Specific dependencies that require Managed Instance
• Blockers: Issues that prevent migration entirely
• install_script_features: What the install.ps1 needs to enable
• adapter_features: What the ARM template needs to configure
• Provisioning guidance: Step-by-step instructions for what to do next

7. generate_install_script

Purpose: Generate an install.ps1 PowerShell script for OS-level feature enablement on Managed Instance.

This handles the OS-level side of the Managed Instance provisioning split. It generates a startup script that includes sections for:

The script can auto-detect needed features from config and source assessments, or you can specify them manually.

8. generate_adapter_arm_template

Purpose: Generate an ARM template for Managed Instance registry and storage adapters.

This handles the platform-level side of the Managed Instance provisioning split. It generates a deployable ARM template that configures:

Registry Adapters (Key Vault-backed):

• Map Windows Registry paths (e.g., HKLM\SOFTWARE\MyApp\LicenseKey) to Key Vault secrets
• Your application reads the registry as before; Managed Instance redirects the read to Key Vault transparently

Storage Adapters (three types): | Type | Description | Credentials | |——|————-|————-| | AzureFiles | Mount Azure Files SMB share as a drive letter | Storage account key in Key Vault | | Custom | Mount storage over private endpoint via VNET | Requires VNET integration | | LocalStorage | Allocate local SSD on the Managed Instance as a drive letter | None needed |

The template also includes:

• Managed Identity configuration
• RBAC role assignments guidance (Key Vault Secrets User, Storage File Data SMB Share Contributor, etc.)
• Deployment CLI commands ready to copy-paste

Phase 4 — Deployment Planning & Packaging

9. plan_deployment

Purpose: Plan the Azure App Service deployment — plans, SKUs, site assignments.

Collects your Azure details (subscription, resource group, region) and creates a validated deployment plan:

• Assigns sites to App Service Plans
• Enforces PV4 + IsCustomMode=true for Managed Instance — won’t let you accidentally use the wrong SKU
• Supports single_plan (all sites on one plan) or multi_plan (separate plans)
• Optionally queries Azure for existing Managed Instance plans you can reuse

10. package_site

Purpose: Package IIS site content into ZIP files for deployment.

Calls Get-SitePackage.ps1 to:

• Compress site binaries + web.config into deployment-ready ZIPs
• Optionally inject install.ps1 into the package (so it deploys alongside the app)
• Handle sites with non-fatal issues (configurable)

Size limit: 2 GB per site (enforced by System.IO.Compression).

11. generate_migration_settings

Purpose: Create the MigrationSettings.json deployment configuration.

This is the final configuration artifact. It calls Generate-MigrationSettings.ps1 and then post-processes the output to inject Managed Instance-specific fields:

Important: The Managed Instance on App Service Plan is not automatically created by the migration tools. You must pre-create the App Service Plan (PV4 SKU with IsCustomMode=true) in the Azure portal or via CLI before generating migration settings. When running generate_migration_settings, provide the name of your existing Managed Instance plan so the settings file references it correctly.

{
  "AppServicePlan": "mi-plan-eastus",
  "Tier": "PremiumV4",
  "IsCustomMode": true,
  "InstallScriptPath": "install.ps1",
  "Region": "eastus",
  "Sites": [
    {
      "IISSiteName": "MyLegacyApp",
      "AzureSiteName": "mylegacyapp-azure",
      "SitePackagePath": "packagedsites/MyLegacyApp_Content.zip"
    }
  ]
}

Phase 5 — Execution

12. confirm_migration

Purpose: Present a full migration summary and require explicit human confirmation.

Before touching Azure, this tool displays:

• Total plans and sites to be created
• SKU and pricing tier per plan
• Whether Managed Instance is configured
• Cost warning for PV4 pricing
• Resource group, region, and subscription details

Nothing proceeds until the user explicitly confirms.

13. migrate_sites

Purpose: Deploy everything to Azure App Service. This creates billable resources.

Calls Invoke-SiteMigration.ps1, which:

1. Sets Azure subscription context
2. Creates/validates resource groups
3. Creates App Service Plans (PV4 with IsCustomMode for Managed Instance)
4. Creates Web Apps
5. Configures .NET version, 32-bit mode, pipeline mode from the original IIS settings
6. Sets up virtual directories and applications
7. Disables basic authentication (FTP + SCM) for security
8. Deploys ZIP packages via Azure REST API

Output: MigrationResults.json with per-site Azure URLs, Resource IDs, and deployment status.

The 6 Copilot Agents

The MCP tools are orchestrated by a team of specialized Copilot agents — each responsible for a specific phase of the migration lifecycle.

@iis-migrate — The Orchestrator

The root agent that guides the entire migration. It:

• Tracks progress across all 5 phases using a todo list
• Delegates work to specialist subagents
• Gates between phases — asks before transitioning
• Enforces the Managed Instance constraint (PV4 + IsCustomMode) at every decision point
• Never skips the Phase 5 confirmation gate

Usage: Open Copilot Chat and type @iis-migrate I want to migrate my IIS applications to Azure

iis-discover — Discovery Specialist

Handles Phase 1. Runs discover_iis_sites, presents a summary table of all sites with their readiness status, and asks whether to assess or skip to packaging. Returns readiness_results_path and per-site routing plans.

iis-assess — Assessment Specialist

Handles Phase 2. Runs assess_site_readiness for every site, and assess_source_code when source code assessment results are available. Merges findings, highlights Managed Instance-relevant issues, and produces the adapter/install features lists that drive Phase 3.

iis-recommend — Recommendation Specialist

Handles Phase 3. Runs recommend_target for each site, then conditionally generates install.ps1 and ARM adapter templates. Presents all recommendations with confidence levels and reasoning, and allows you to edit generated artifacts.

iis-deploy-plan — Deployment Planning Specialist

Handles Phase 4. Collects Azure details, runs plan_deployment, package_site, and generate_migration_settings. Validates Managed Instance configuration, allows review and editing of MigrationSettings.json. Does not execute migration.

iis-execute — Execution Specialist

Handles Phase 5 only. Runs confirm_migration to present the final summary, then only proceeds with migrate_sites after receiving explicit “yes” confirmation. Reports results with Azure URLs and deployment status.

The Managed Instance Provisioning Split: A Critical Concept

One of the most important ideas Managed Instance introduces is the provisioning split — the division of OS dependencies into two categories that are configured through different mechanisms:

┌──────────────────────────────────────────────────────────────┐
│            MANAGED INSTANCE PROVISIONING SPLIT                │
├─────────────────────────────┬────────────────────────────────┤
│  ARM Template               │  install.ps1                   │
│  (Platform-Level)           │  (OS-Level)                    │
├─────────────────────────────┼────────────────────────────────┤
│  Registry Adapters          │  COM/MSI Registration          │
│    → Key Vault secrets      │    → regsvr32, RegAsm, msiexec │
│                             │                                │
│  Storage Mounts             │  SMTP Server Feature           │
│    → Azure Files            │    → Install-WindowsFeature    │
│    → Local SSD              │                                │
│    → VNET private storage   │  MSMQ                          │
│                             │    → Message queue setup        │
│                             │                                │
│                             │  Crystal Reports Runtime       │
│                             │    → SAP MSI installer          │
│                             │                                │
│                             │  Custom Fonts                  │
│                             │    → Copy to C:\Windows\Fonts  │
└─────────────────────────────┴────────────────────────────────┘

The MCP server handles this split automatically:

• assess_source_code detects which dependencies fall into which category
• recommend_target reports both adapter_features and install_script_features
• generate_adapter_arm_template builds the ARM template for platform features
• generate_install_script builds the PowerShell startup script for OS features

You don’t need to remember which goes where — the system decides and generates the right artifacts.

End-to-End Walkthrough: From Discovery to Running on Managed Instance

Here’s what a complete migration conversation looks like:

You: “@iis-migrate I want to migrate my IIS applications to Azure”

Phase 1 — Discovery:

Agent runs discover_iis_sites, presents a table:

Site	Status	Framework	Source Code?
HRPortal	READY_WITH_ISSUES	v4.8	Yes (.sln found)
PayrollAPI	READY	v4.8	No
IntranetCMS	BLOCKED (>2GB)	v4.7.2	No

Phase 2 — Assessment:

Agent runs assess_site_readiness for HRPortal — finds GACCheck and RegistryCheck failures. Runs assess_source_code using source code assessment report — confirms COM interop, registry access, and SMTP usage.

Phase 3 — Recommendation:

Agent runs recommend_target:

• HRPortal → MI_AppService (high confidence) — COM, registry, SMTP dependencies
• PayrollAPI → AppService (high confidence) — no OS dependencies

Generates install.ps1 for HRPortal (SMTP + COM sections). Generates ARM template with registry adapter (Key Vault-backed) for HRPortal.

Phase 4 — Deployment Planning:

Agent collects subscription/RG/region, validates PV4 availability. Packages both sites. Generates MigrationSettings.json with two plans:

• mi-plan-hrportal (PremiumV4, IsCustomMode=true) — HRPortal
• std-plan-payrollapi (PremiumV2) — PayrollAPI

Phase 5 — Execution:

Agent shows full summary with cost projection. You type “yes”. Sites deploy. You get Azure URLs within minutes.

Prerequisites & Setup

Quick Start

# Clone and set up the MCP server
git clone https://github.com/<your-org>/iis-migration-mcp.git
cd iis-migration-mcp
python -m venv .venv
.venv\Scripts\activate
pip install -r requirements.txt

# Download Microsoft's migration scripts (NOT included in this repo)
# From: https://appmigration.microsoft.com/api/download/psscripts/AppServiceMigrationScripts.zip
# Unzip to C:\MigrationScripts (or your preferred path)

# Start using in VS Code with Copilot
# 1. Copy .vscode/mcp.json.example → .vscode/mcp.json
# 2. Open folder in VS Code
# 3. In Copilot Chat: "Configure scripts path to C:\MigrationScripts"
# 4. Then: @iis-migrate "Discover my IIS sites"

The server also works with any MCP-compatible client — Claude Desktop, Cursor, Copilot CLI, or custom integrations — via stdio transport.

Data Flow & Artifacts

Every phase produces JSON artifacts that chain into the next phase:

Phase 1: discover_iis_sites ──→ ReadinessResults.json
                                      │
Phase 2: assess_site_readiness ◄──────┘
         assess_source_code ───→ Assessment JSONs
                                      │
Phase 3: recommend_target ◄───────────┘
         generate_install_script ──→ install.ps1
         generate_adapter_arm ─────→ mi-adapters-template.json
                                      │
Phase 4: package_site ────────────→ PackageResults.json + site ZIPs
         generate_migration_settings → MigrationSettings.json
                                      │
Phase 5: confirm_migration ◄──────────┘
         migrate_sites ───────────→ MigrationResults.json
                                      │
                                      ▼
                              Apps live on Azure
                              *.azurewebsites.net

Each artifact is inspectable, editable, and auditable — providing a complete record of what was assessed, recommended, and deployed.

Error Handling

The MCP server classifies errors into actionable categories:

Conclusion

The IIS Migration MCP Server turns what used to be a multi-week, expert-driven project into a guided conversation. It combines Microsoft’s battle-tested migration PowerShell scripts with AI orchestration that understands the nuances of Managed Instance on App Service — the provisioning split, the PV4 constraint, the adapter configurations, and the OS-level customizations.

Whether you’re migrating 1 site or 10, agentic migration reduces risk, eliminates guesswork, and produces auditable artifacts at every step. The human stays in control; the AI handles the complexity.

Get started: Download the migration scripts, set up the MCP server, and ask @iis-migrate to discover your IIS sites. The agents will take it from there.

This project is compatible with any MCP-enabled client: VS Code GitHub Copilot, Claude Desktop, Cursor, and more. The intelligence travels with the server, not the client.

To get started, go to the Kudu/SCM site for your app:

<sitename>.scm.azurewebsites.net

From there, open the new Deployments experience.

You can now deploy your app by simply dragging and dropping a zip file containing your code. Once your file is uploaded, App Service shows you the contents of the zip so you can quickly verify what you’re about to deploy.

If your application is already built and ready to run, you also have the option to skip server-side build. Otherwise, App Service can handle the build step for you.

When you’re ready, select Deploy.

From there, the deployment starts right away, and you can follow each phase of the process as it happens. The experience shows clear progress through upload, build, and deployment, along with deployment logs to help you understand what’s happening behind the scenes.

After the deployment succeeds, you can also view runtime logs, which makes it easier to confirm that your app has started successfully.

This experience is ideal if you’re getting started with Azure App Service and want the quickest path from code to a running app. For production workloads and teams with established release processes, you’ll typically continue using an automated CI/CD pipeline (for example, GitHub Actions or Azure DevOps) for repeatable deployments.

We’re continuing to improve the developer experience on App Service for Linux. Give it a try and let us know what you think.

Recent Investments

Premium v4 (Pv4)

Azure App Service Premium v4 delivers higher performance and scalability on newer Azure infrastructure while preserving the fully managed PaaS experience developers rely on.

Premium v4 offers expanded CPU and memory options, improved price-performance, and continued support for App Service capabilities such as deployment slots, integrated monitoring, and availability zone resiliency.

These improvements help teams modernize and scale demanding workloads without taking on additional operational complexity.

App Service Managed Instance

App Service Managed Instance extends the App Service model to support Windows web applications that require deeper environment control. It enables plan-level isolation, optional private networking, and operating system customization while retaining managed scaling, patching, identity, and diagnostics. Managed Instance is designed to reduce migration friction for existing applications, allowing teams to move to a modern PaaS environment without code changes.

Faster Runtime and Language Support

Azure App Service continues to invest in keeping pace with modern application stacks. Regular updates across .NET, Node.js, Python, Java, and PHP help developers adopt new language versions and runtime improvements without managing underlying infrastructure.

Reliability and Availability Improvements

Ongoing investments in platform reliability and resiliency strengthen production confidence. Expanded Availability Zone support and related infrastructure improvements help applications achieve higher availability with more flexible configuration options as workloads scale.

Deployment Workflow Enhancements

Deployment workflows across Azure App Service continue to evolve, with ongoing improvements to GitHub Actions, Azure DevOps, and platform tooling. These enhancements reduce friction from build to production while preserving the managed App Service experience.

A Platform That Grows With You

These recent investments reflect a consistent direction for Azure App Service: active development focused on performance, reliability, and developer productivity. Improvements to runtimes, infrastructure, availability, and deployment workflows are designed to work together, so applications benefit from platform progress without needing to re-architect or change operating models.

The recent General Availability of Aspire on Azure App Service is another example of this direction. Developers building distributed .NET applications can now use the Aspire AppHost model to define, orchestrate, and deploy their services directly to App Service — bringing a code-first development experience to a fully managed platform.

We are also seeing many customers build and run AI-powered applications on Azure App Service, integrating models, agents, and intelligent features directly into their web apps and APIs. App Service continues to evolve to support these scenarios, providing a managed, scalable foundation that works seamlessly with Azure’s broader AI services and tooling.

Whether you are modernizing with Premium v4, migrating existing workloads using App Service Managed Instance, or running production applications at scale - including AI-enabled workloads - Azure App Service provides a predictable and transparent foundation that evolves alongside your applications.

Azure App Service continues to focus on long-term value through sustained investment in a managed platform developers can rely on as requirements grow, change, and increasingly incorporate AI.

Get Started

Ready to build on Azure App Service? Here are some resources to help you get started:

• Create your first web app — Deploy a web app in minutes using the Azure portal, CLI, or VS Code.
• App Service documentation — Explore guides, tutorials, and reference for the full platform.
• Aspire on Azure App Service — Now generally available. Deploy distributed .NET applications to App Service using the Aspire AppHost model.
• Pricing and plans — Compare tiers including Premium v4 and find the right fit for your workload.
• App Service on Azure Architecture Center — Reference architectures and best practices for production deployments.

Aspire brings a code-first model for building, running, and deploying distributed applications, with AppHost as the place where services, dependencies, and topology are declared. On Azure App Service, this means developers can keep the familiar Aspire programming model while using a fully managed platform for hosting, security patching and scaling. You can read more about the benefits of Aspire here.

If you’re new to Aspire on App Service, the fastest path is our Quickstart, which walks you through creating an Aspire starter app and deploying it to App Service

This release adds Deployment Slots support so you can adopt safer deployment patterns (staging → validate → swap). Here is a code snippet showing you how to add a slot.

var builder = DistributedApplication.CreateBuilder(args);

builder.AddAzureAppServiceEnvironment("<appsvc64>")
    .WithDeploymentSlot("dev");

var apiService = builder.AddProject<Projects.AspireApp64_ApiService>("apiservice")
    .WithHttpHealthCheck("/health")
    .WithExternalHttpEndpoints();

builder.AddProject<Projects.AspireApp64_Web>("webfrontend")
    .WithExternalHttpEndpoints()
    .WithHttpHealthCheck("/health")
    .WithReference(apiService)
    .WaitFor(apiService);

builder.Build().Run();

1. If the production slot does not already exist, this creates both the production slot and the staging slot with identical code.
2. If the production slot already exists, the deployment goes only to the staging slot.

[NOTE]

Scaling: Manual scaling is supported (via AppHost code or the Azure portal), and you can also setup rule-based scaling. Automatic scaling is not yet supported in the current experience.

Learn more about the configuration options for Aspire on App Service here.

We’d love for you to try Aspire on App Service and tell us what you’re building - your feedback helps shape what we ship next.

How do you choose between client-side and server-side agents?

This is an important question that points to a fundamental choice in Agent Framework: client-side agents vs. server-side agents. I’m not going to go into extreme detail here; my goal for this post is to show you how to build client-side multi-agent systems with ChatClientAgent and Azure App Service, but I will highlight the key differences and trade-offs that are going through my mind when considering this to help you make an informed decision.

In Part 2, I mentioned:

“In my next blog post, I’ll demonstrate an alternative approach using a different agent type—likely the Azure OpenAI ChatCompletion agent type—which doesn’t create server-side Foundry resources. Instead, you orchestrate the agent behavior yourself while still benefiting from the Agent Framework’s unified programming model.”

Today, I’m delivering on that promise! We’re going to rebuild the same travel planner sample using ChatClientAgent—a client-side agent type that gives you complete control over orchestration, chat history, and agent lifecycle.

In this post, we’ll explore:

• ✅ Client-side agent orchestration with full workflow control
• ✅ ChatClientAgent architecture and implementation patterns
• ✅ When to choose client-side vs. server-side agents
• ✅ How Azure App Service supports both approaches equally well
• ✅ Managing chat history your way (Cosmos DB, Redis, or any storage you choose)

🔗 Full Sample Code: https://github.com/Azure-Samples/app-service-maf-openai-travel-agent-dotnet

The Key Question: Who’s in Charge?

When building multi-agent systems with Agent Framework, you face a fundamental architectural decision. Microsoft Agent Framework supports multiple agent types, but the choice typically comes down to:

Server-Side (Foundry Agents - Part 2)

• Azure AI Foundry manages agent lifecycle, threads, and execution
• Agents exist as Azure resources in your AI Project
• Conversation history stored in Foundry threads
• Built-in orchestration patterns and features

Client-Side (ChatClientAgent - This Post)

• Your application code manages agent lifecycle and orchestration
• Agents are C# objects created on-demand
• Conversation history stored wherever you choose (Cosmos DB, Redis, etc.)
• You write the orchestration logic yourself

Both approaches run well on Azure App Service—the platform doesn’t care which agent type you use. What matters is which approach fits your requirements better.

What’s Different: ChatClientAgent Architecture

Let’s see what changes when you switch from Foundry agents to ChatClientAgent.

The Same Multi-Agent Workflow

Both samples implement the exact same travel planner with 6 specialized agents:

1. Currency Converter Agent - Real-time exchange rates
2. Weather Advisor Agent - Forecasts and packing tips
3. Local Knowledge Agent - Cultural insights
4. Itinerary Planner Agent - Day-by-day schedules
5. Budget Optimizer Agent - Cost allocation
6. Coordinator Agent - Final assembly

The agents collaborate through the same 4-phase workflow:

• Phase 1: Parallel information gathering (Currency + Weather + Local)
• Phase 2: Itinerary planning
• Phase 3: Budget optimization
• Phase 4: Final assembly

Same workflow, different execution model.

How ChatClientAgent Works

Here’s the architecture stack for the client-side approach:

The architecture shows:

• Your Application Code: TravelPlanningWorkflow orchestrating 6 ChatClientAgents with client-side chat history
• Microsoft.Agents.AI: ChatClientAgent wrapper adding instructions and tools
• Microsoft.Extensions.AI: IChatClient abstraction with Azure OpenAI implementation
• Azure Services: Azure OpenAI, Cosmos DB for chat history, and external APIs

Key components:

1. TravelPlanningWorkflow - Your orchestration code that coordinates agent execution
2. ChatClientAgent - Agent Framework wrapper that adds instructions and tools to IChatClient
3. IChatClient - Standard abstraction from Microsoft.Extensions.AI
4. Client-Side Chat History - Dictionary storing conversation per agent (you manage this!)
5. Azure OpenAI - Direct chat completion API calls (no AI Project endpoint needed)
6. Cosmos DB - Your choice for chat history persistence

Implementation: BaseAgent Pattern

Here’s how you create a ChatClientAgent in code:

public abstract class BaseAgent : IAgent
{
    protected readonly ChatClientAgent Agent;
    
    protected abstract string AgentName { get; }
    protected abstract string Instructions { get; }
    
    // Constructor for simple agents without tools
    protected BaseAgent(
        ILogger logger,
        IOptions<AgentOptions> options,
        IChatClient chatClient)
    {
        Agent = new ChatClientAgent(chatClient, new ChatClientAgentOptions
        {
            Name = AgentName,
            Instructions = Instructions
        });
    }
    
    // Constructor for agents with tools (weather, currency APIs)
    protected BaseAgent(
        ILogger logger,
        IOptions<AgentOptions> options,
        IChatClient chatClient,
        ChatOptions chatOptions)
    {
        Agent = new ChatClientAgent(chatClient, new ChatClientAgentOptions
        {
            Name = AgentName,
            Instructions = Instructions,
            ChatOptions = chatOptions // Tools via AIFunctionFactory
        });
    }
    
    public async Task<ChatMessage> InvokeAsync(
        IList<ChatMessage> chatHistory, 
        CancellationToken cancellationToken = default)
    {
        var response = await Agent.RunAsync(
            chatHistory, 
            thread: null, 
            options: null, 
            cancellationToken);
            
        return response.Messages.LastOrDefault() 
            ?? new ChatMessage(ChatRole.Assistant, "No response generated.");
    }
}

What’s happening here?

• You create a ChatClientAgent by wrapping an IChatClient
• You provide instructions (the agent’s system prompt)
• Optionally, you provide tools via ChatOptions (using AIFunctionFactory)
• When you call RunAsync, you pass the chat history yourself
• The agent returns a response, and you decide what to do with the chat history

Compare this to Foundry agents where you create the agent once in Azure AI Foundry, and the platform manages threads and execution for you.

Client-Side Chat History Management

One of the biggest differences is you control the chat history:

public class WorkflowState
{
    // Each agent gets its own conversation history
    public Dictionary<string, List<ChatMessage>> AgentChatHistories { get; set; } = new();
    
    public List<ChatMessage> GetChatHistory(string agentType)
    {
        if (!AgentChatHistories.ContainsKey(agentType))
        {
            AgentChatHistories[agentType] = new List<ChatMessage>();
        }
        return AgentChatHistories[agentType];
    }
}

Workflow orchestration:

// Phase 1: Currency Converter Agent
var currencyChatHistory = state.GetChatHistory("CurrencyConverter");
currencyChatHistory.Add(new ChatMessage(ChatRole.User, 
    $"Convert {request.Budget} {request.Currency} to local currency for {request.Destination}"));

var currencyResponse = await _currencyAgent.InvokeAsync(currencyChatHistory, cancellationToken);
currencyChatHistory.Add(currencyResponse); // You manage the history!

// Store in workflow state for downstream agents
state.AddToContext("CurrencyInfo", currencyResponse.Text ?? "");

Benefits:

• Store chat history in Cosmos DB, Redis, SQL, or any data store
• Query conversation history with your own logic
• Implement custom retention policies
• Export chat logs for analytics or compliance

With Foundry agents, chat history lives in Foundry threads—you don’t directly control where or how it’s stored. This may be fine for many scenarios, but if you need custom storage or compliance, client-side management is powerful.

Tool Integration with AIFunctionFactory

External API tools (weather, currency) are registered as C# methods:

// Weather Service
public class NWSWeatherService : IWeatherService
{
    [Description("Get weather forecast for a US city")]
    public async Task<WeatherForecast> GetWeatherAsync(
        [Description("City name (e.g., 'San Francisco')")] string city,
        [Description("State code (e.g., 'CA')")] string state,
        CancellationToken cancellationToken = default)
    {
        // Implementation calls NWS API
    }
}

// Register as tools with ChatClientAgent
var weatherTools = AIFunctionFactory.Create(weatherService);
var chatOptions = new ChatOptions { Tools = weatherTools };

var agent = new ChatClientAgent(chatClient, new ChatClientAgentOptions
{
    Name = "WeatherAdvisor",
    Instructions = "Provide weather forecasts and packing recommendations...",
    ChatOptions = chatOptions
});

The agent can now call GetWeatherAsync via function calling—same capability as Foundry agents, but configured in code instead of the portal.

Why Choose Client-Side Agents (ChatClientAgent)?

Here’s when ChatClientAgent shines:

✅ Full Orchestration Control

You write the workflow logic:

// Phase 1: Run 3 agents in parallel (your code!)
var currencyTask = GatherCurrencyInfoAsync(request, state, progress, cancellationToken);
var weatherTask = GatherWeatherInfoAsync(request, state, progress, cancellationToken);
var localTask = GatherLocalKnowledgeAsync(request, state, progress, cancellationToken);

await Task.WhenAll(currencyTask, weatherTask, localTask);

// Phase 2: Sequential itinerary planning (your code!)
await PlanItineraryAsync(request, state, progress, cancellationToken);

With Foundry agents, orchestration patterns are limited to what the platform provides.

✅ Cost-Effective

No separate agent infrastructure:

• ChatClientAgent: Pay only for Azure OpenAI API calls
• Foundry Agents: Pay for Azure OpenAI + AI Project resources + agent storage

For high-volume scenarios, this can add up to significant savings.

✅ DevOps-Friendly

Everything in code:

• Agent definitions tracked in Git
• Testable with unit tests
• CI/CD pipelines deploy everything together
• No manual portal configuration steps
• Infrastructure as Code (Bicep) covers all resources

✅ Flexible Chat History

Store conversations your way:

• Cosmos DB for global distribution and rich queries
• Redis for ultra-low latency caching
• SQL Database for complex relational queries
• Blob Storage for long-term archival
• Custom encryption and retention policies

✅ Provider Flexibility

Works with any IChatClient:

• Azure OpenAI (this sample)
• OpenAI directly
• Local models via Ollama
• Azure AI Foundry model catalog
• Custom chat implementations

Switching providers is just a configuration change—no agent re-creation needed.

✅ Multi-Agent Coordination Patterns

Implement complex workflows:

• Parallel execution (Phase 1 in our sample)
• Sequential dependencies (Phase 2-4)
• Conditional branching based on agent responses
• Agent-to-agent negotiation
• Hierarchical supervisor patterns
• Custom retry logic per agent

You have complete freedom to orchestrate however your scenario requires.

Why Choose Server-Side Agents (Azure AI Foundry)?

To be fair, Foundry agents from Part 2 have their own advantages and this post isn’t about dismissing them. They are a powerful option for many scenarios. Here are some reasons to choose Foundry agents:

✅ Managed Lifecycle

Platform handles the heavy lifting:

• Agents persist as Azure resources
• Threads automatically manage conversation state
• Runs track execution progress server-side
• No orchestration code to write or maintain

✅ Built-In Features

Rich capabilities out of the box:

• File search for RAG scenarios
• Code interpreter for data analysis
• Automatic conversation threading
• Built-in retry and error handling

✅ Portal UI

Configure without code:

• Create agents in Azure AI Foundry portal
• Test agents interactively
• View conversation threads and runs
• Adjust instructions without redeployment

✅ Less Code

Simpler for basic scenarios:

// Foundry Agent (Part 2 sample)
var agent = await agentsClient.CreateAgentAsync(
    "gpt-4o",
    instructions: "You are a travel planning expert...",
    tools: new List<ToolDefinition> { new FunctionTool(...) });

var thread = await agentsClient.CreateThreadAsync();
var run = await agentsClient.CreateRunAsync(thread.Id, agent.Id);

No need to manage chat history, orchestration logic, or tool registration in code.

When to Choose Which Approach

Here’s my take on a decision guide. This isn’t exhaustive, but it covers key considerations. Others may disagree based on their priorities, but this is how I think about it:

Use ChatClientAgent when:

• You need complex multi-agent coordination
• Cost optimization is important
• You want full control over orchestration
• Code-first DevOps is a priority
• You need custom chat history management

Use Foundry Agents when:

• Simple single-agent or basic multi-agent scenarios
• You want built-in RAG and file search
• Portal-based configuration is preferred
• Quick prototyping and experimentation
• Managed infrastructure over custom code

Azure App Service: Perfect for Both

Here’s the great part: Azure App Service supports both approaches equally well.

The Same Architecture

Both samples use identical infrastructure.

What’s the same:

• ✅ Async request-reply pattern (202 Accepted → poll status)
• ✅ Service Bus for reliable message delivery
• ✅ Cosmos DB for task state with 24-hour TTL
• ✅ WebJob for background processing
• ✅ Managed Identity for authentication
• ✅ Premium App Service tier for Always On

What’s different:

• ChatClientAgent: Azure OpenAI endpoint directly (https://ai-xyz.openai.azure.com/)
• Foundry Agents: AI Project endpoint (https://ai-xyz.services.ai.azure.com/api/projects/proj-xyz)
• ChatClientAgent: Chat history in Cosmos DB (your control)
• Foundry Agents: Chat history in Foundry threads (platform managed)

Azure App Service doesn’t care which you choose. It just runs your .NET code, processes messages from Service Bus, and stores state in Cosmos DB. The agent execution model is an implementation detail. You can easily switch between approaches without changing your hosting platform, and even use a hybrid approach if desired.

Get Started Today

Ready to try client-side multi-agent orchestration on Azure App Service?

🔗 GitHub Repository: https://github.com/Azure-Samples/app-service-maf-openai-travel-agent-dotnet

The repository includes:

• ✅ Complete .NET 9 source code with 6 specialized ChatClientAgents
• ✅ Infrastructure as Code (Bicep) for one-command deployment
• ✅ Web UI with real-time progress tracking
• ✅ Comprehensive README and architecture documentation
• ✅ External API integrations (weather, currency)
• ✅ Client-side chat history management with Cosmos DB

Deploy in Minutes

# Clone the repository
git clone https://github.com/Azure-Samples/app-service-maf-openai-travel-agent-dotnet.git
cd app-service-maf-openai-travel-agent-dotnet

# Login to Azure
azd auth login

# Provision infrastructure and deploy the API
azd up

This provisions:

• Azure App Service (P0v4 Premium Windows)
• Azure Service Bus (message queue)
• Azure Cosmos DB (state + chat history storage)
• Azure AI Services (AI Services resource)
• GPT-4o model deployment (GlobalStandard 50K TPM)

Then manually deploy the WebJob following the README instructions.

Compare with Part 2

Want to see the differences firsthand? Deploy both samples:

Part 2 - Server-Side Foundry Agents:
🔗 https://github.com/Azure-Samples/app-service-maf-workflow-travel-agent-dotnet

Part 3 - Client-Side ChatClientAgent (this post):
🔗 https://github.com/Azure-Samples/app-service-maf-openai-travel-agent-dotnet

Same travel planner, same workflow, same results—different execution model. Try both and see which fits your needs!

Key Takeaways

• ✅ Microsoft Agent Framework offers choice: Client-side (ChatClientAgent) vs. Server-side (Foundry Agents)
• ✅ ChatClientAgent gives you full control: Orchestration, chat history, agent lifecycle—you manage it all in code
• ✅ Foundry Agents give you convenience: Managed infrastructure, built-in features, portal UI—let the platform handle the details
• ✅ Azure App Service supports both equally: Same async request-reply pattern, same WebJob architecture, same infrastructure
• ✅ Pick the right tool for your needs: Complex coordination and cost control → ChatClientAgent. Simple scenarios and managed infrastructure → Foundry Agents.

Whether you choose client-side or server-side agents, Azure App Service provides the perfect platform for long-running AI workloads—reliable, scalable, and fully managed.

What’s Next?

This completes our three-part series on building AI agents with Microsoft Agent Framework on Azure App Service:

• Part 1: Introduction to Agent Framework and async request-reply pattern
• Part 2: Multi-agent systems with server-side Foundry Agents
• Part 3 (this post): Client-side multi-agent orchestration with ChatClientAgent

What would you like to see next? More advanced orchestration patterns? Integration with other Azure services?

Let me know in the comments what you’d like to learn about next and I’ll do my best to deliver!

“Thanks for the example. Nice job! Just curious (I still have to investigate the ins and outs of MAF) but why didn’t you use the workflow pattern/classes of MAF? I thought that was meant to be the way to connect agents and let them cooperate (even in long running job situations).”

— Michel_Schep

Great question! You’re absolutely right in questioning this—the initial sample I created was designed to demonstrate the async request-reply architecture for handling long-running operations on App Service with a single agent. Today, we’re taking the next step: a multi-agent workflow sample that addresses exactly what you asked about and is the next leap in building agentic apps in the cloud.

In this post, we’ll explore:

• ✅ Building multi-agent systems with specialized, collaborating AI agents
• ✅ When to create agents in code vs. using Azure AI Foundry portal
• ✅ Orchestrating complex workflows with parallel and sequential execution
• ✅ Real-world patterns for production multi-agent applications

🔗 Full Sample Code: https://github.com/Azure-Samples/app-service-maf-workflow-travel-agent-dotnet

Why Multi-Agent Systems?

The single-agent pattern I showed last week works great for straightforward tasks. But real-world AI applications often need specialized expertise across different domains. That’s where multi-agent systems shine.

The Travel Planning Challenge

Imagine planning a trip to Tokyo. You need:

• Currency expertise for budget conversion and exchange rates
• Weather knowledge for packing recommendations and seasonal planning
• Local insights about customs, culture, and etiquette
• Itinerary skills to create day-by-day schedules
• Budget optimization to allocate funds across categories
• Coordination to assemble everything into a cohesive plan

With a single agent handling all of this, you get a “jack of all trades, master of none” situation. The prompts become complex, the agent loses focus, and results can be inconsistent.

Enter Multi-Agent Workflows

Instead of one generalist agent, we can create 6 or more specialized agents, each with a focused responsibility:

1. Currency Converter Agent - Real-time exchange rates (Frankfurter API integration)
2. Weather Advisor Agent - Forecasts and packing tips (National Weather Service API)
3. Local Knowledge Agent - Cultural insights and customs
4. Itinerary Planner Agent - Day-by-day activity scheduling
5. Budget Optimizer Agent - Cost allocation and optimization
6. Coordinator Agent - Final assembly and formatting

Each agent has:

• 🎯 Clear, focused instructions specific to its domain
• 🛠️ Specialized tools (weather API, currency API)
• 📊 Defined inputs and outputs for predictable collaboration
• ✅ Testable behavior that’s easy to validate

Additionally, if you wanted to extend this even further, you could create even more agents and give some of your specialist agents even more knowledge by connecting additional tools and MCP servers. The possibilities are endless, and I hope this post inspires you to start thinking about what you can build and achieve.

What Makes This Possible? Microsoft Agent Framework

All of this is powered by Microsoft Agent Framework—a comprehensive platform for building, deploying, and managing AI agents that goes far beyond simple chat completions.

Understanding Agent Framework vs. Other Approaches

Before diving into the details, it’s important to understand what Agent Framework is. Unlike frameworks like Semantic Kernel where you orchestrate AI behavior entirely in your application code with direct API calls, Agent Framework provides a unified abstraction for working with AI agents across multiple backend types.

Agent Framework supports several agent types (see documentation):

1. Simple agents based on inference services - Agents built on any IChatClient implementation, including:
   • Azure OpenAI ChatCompletion
   • Azure AI Foundry Models ChatCompletion
   • OpenAI ChatCompletion and Responses
   • Any other Microsoft.Extensions.AI.IChatClient implementation
2. Server-side managed agents - Agents that live as Azure resources:
   • Azure AI Foundry Agent (used in this sample)
   • OpenAI Assistants

3. Custom agents - Fully custom implementations of the AIAgent base class

4. Proxy agents - Connections to remote agents via protocols like A2A

In this sample, we use Azure AI Foundry Agents—the server-side managed agent type. When you use these Foundry agents:

• Agents are Azure resources - They exist on the server-side in Azure AI Foundry, not just as code patterns
• Execution happens on Foundry - Agent runs execute on Azure’s infrastructure with built-in state management
• You get structured primitives - Agents, Threads, and Runs are first-class concepts with their own lifecycles
• Server-side persistence - Conversation history and context are managed by the platform

This server-side approach is convenient because the platform manages state and execution for you. However, other agent types (like ChatCompletion-based agents) give you more control over orchestration while still benefiting from the unified Agent Framework programming model.

In my next blog post, I’ll demonstrate an alternative approach using a different agent type—likely the Azure OpenAI ChatCompletion agent type—which doesn’t create server-side Foundry resources. Instead, you orchestrate the agent behavior yourself while still benefiting from the Agent Framework’s unified programming model.

If you’re new to Agent Framework, here’s what makes it special:

• 🔄 Persistent Agents: Server-side agents that maintain context across multiple interactions, not just one-off API calls
• 💬 Conversation Threads: Organized conversation history and state management that persists across agent runs
• 🎯 Agent Runs: Structured execution with progress tracking and lifecycle management—you can monitor exactly what your agents are doing
• 🔁 Multi-Turn Interactions: Complex workflows with iterative AI processing, where agents can refine and improve their outputs
• 🛠️ Tool Integration: Extensible function calling and integration capabilities—agents can call external APIs, execute code, and interact with real-world systems

In our sample, Agent Framework handles:

• Creating and managing 6 specialized agents programmatically
• Maintaining conversation context as agents collaborate
• Tracking execution progress across workflow phases
• Managing agent lifecycle (creation, execution, cleanup)
• Integrating external APIs (weather, currency) seamlessly

The beauty of Agent Framework is that it makes complex multi-agent orchestration feel natural. You focus on defining what your agents should do, and the framework handles the infrastructure, state management, and execution—all running on Azure AI Foundry with enterprise-grade reliability.

The Multi-Agent Workflow

Here’s how these agents collaborate to create a comprehensive travel plan in the sample I put together:

Execution Phases

Phase 1: Parallel Information Gathering (10-40%)

• Currency, Weather, and Local Knowledge agents execute simultaneously
• No dependencies = maximum performance
• Results stored in workflow state for downstream agents

Phase 2: Itinerary Planning (40-70%)

• Itinerary Planner uses context from all Phase 1 agents
• Weather data influences activity recommendations
• Local knowledge shapes cultural experiences
• Currency conversion informs budget-conscious choices

Phase 3: Budget Optimization (70-90%)

• Budget Optimizer analyzes the proposed itinerary
• Allocates funds across categories (lodging, food, activities, transport)
• Provides cost-saving tips without compromising the experience

Phase 4: Final Assembly (90-100%)

• Coordinator compiles all agent outputs
• Formats comprehensive travel plan with tips
• Returns structured, user-friendly itinerary

Benefits of This Architecture

• ✅ Faster Execution: Parallel agents complete in ~30% less time
• ✅ Better Quality: Specialized agents produce more focused, accurate results
• ✅ Easy Debugging: Each agent’s contribution is isolated and traceable
• ✅ Maintainable: Update one agent without affecting others
• ✅ Scalable: Add new agents (flight booking, hotel search) without refactoring
• ✅ Testable: Validate each agent independently with unit tests

The Complete Architecture

Here’s how everything fits together on Azure App Service:

This architecture builds on the async request-reply pattern from our previous post, adding:

• ✅ Multi-agent orchestration in the background worker
• ✅ Parallel execution of independent agents for performance
• ✅ Code-generated agents for production-ready DevOps
• ✅ External API integration (weather, currency) for real-world data
• ✅ Progress tracking across workflow phases (10% → 40% → 70% → 100%)

Get Started Today

Ready to build your own multi-agent workflows on Azure App Service? Try out the sample today!

🔗 GitHub Repository: https://github.com/Azure-Samples/app-service-maf-workflow-travel-agent-dotnet

The repository includes:

• ✅ Complete .NET 9 source code with 6 specialized agents
• ✅ Infrastructure as Code (Bicep) for one-command deployment
• ✅ Complete web UI with real-time progress tracking
• ✅ Comprehensive README with architecture documentation
• ✅ External API integrations (weather, currency)

Deploy in Minutes

git clone https://github.com/Azure-Samples/app-service-maf-workflow-travel-agent-dotnet.git
cd app-service-maf-workflow-travel-agent-dotnet
azd auth login
azd up

The azd up command provisions:

• Azure App Service (P0v4 Premium)
• Azure Service Bus (message queue for async processing)
• Azure Cosmos DB (state storage with 24-hour TTL)
• Azure AI Foundry (AI Services + Project for Agent Framework)
• GPT-4o model deployment (GlobalStandard 50K TPM)

Then manually deploy the WebJob following the README instructions.

What’s Next? Extend This Pattern

This sample demonstrates production-ready patterns you can extend:

🛠️ Add More Specialized Agents

• Flight Expert Agent - Search and compare flight prices
• Hotel Specialist Agent - Find accommodations based on preferences
• Activity Planner Agent - Book tours, restaurants, events
• Transportation Agent - Plan routes, transit passes, car rentals

🤝 Implement Agent-to-Agent Communication

• Agents negotiate conflicting recommendations
• Hierarchical structures with supervisor agents
• Voting mechanisms for decision-making

🧠 Add Advanced Capabilities

• RAG (Retrieval Augmented Generation) for destination-specific knowledge bases
• Memory to remember user preferences across trips
• Vision models to analyze travel photos and recommend similar destinations
• Multi-language support for international travelers

📊 Production Enhancements

• Authentication - Microsoft Entra AD for user identity
• Application Insights - Distributed tracing and custom metrics
• VNet Integration - Private endpoints for security
• Auto-Scaling - Scale workers based on queue depth
• Webhooks - Notify users when their travel plan is ready

Key Takeaways

• ✅ Multi-agent systems provide specialized expertise and better results than single generalist agents
• ✅ Azure App Service provides a simple, reliable platform for long-running multi-agent workflows
• ✅ Async request-reply pattern with Service Bus + Cosmos DB ensures scalability and resilience
• ✅ External API integration makes agents more useful with real-world data
• ✅ Parallel execution of independent agents dramatically improves performance

Whether you’re building travel planners, document processors, research assistants, or other AI-powered applications, multi-agent workflows on Azure App Service give you the flexibility and sophistication you need.

Learn More

• Microsoft Agent Framework Documentation - Complete guide to Agent Framework
• Original Blog Post - Single-agent async patterns on App Service
• Azure App Service Best Practices - Production deployment patterns
• Async Request-Reply Pattern - Architecture guidance
• Azure App Service WebJobs - Background processing documentation

We Want to Hear From You!

Thanks again to Michel_Schep for the great question that inspired this follow-up sample!

Have you built multi-agent systems with Agent Framework? Are you using Azure App Service to host your AI and intelligent apps? We’d love to hear about your experience in the comments below.

Questions about multi-agent workflows on App Service? Drop a comment and our team will help you get started.

Happy building! 🚀

We’re publishing two Azure Pipelines (Azure DevOps / VSTS) YAML samples to make this easy.

VSTS samples

• vsts-blessed-sitecontainers.yml For built-in runtimes on App Service for Linux (for example, Python or Node on the built-in stack).
  • Builds your app, zips it, and deploys it using AzureWebApp@1.
  • In the same deploy step, it sends a sitecontainersConfig payload that defines one or more sidecar containers by image, port, and config.
  • Your app keeps running on the App Service runtime; the sidecars run next to it.
• vsts-only-sitecontainers.yml For containerized apps (Web App for Containers style).
  • Builds and pushes multiple images (main app container + sidecars) to your container registry.
  • Uses AzureWebAppContainer@1 to deploy them all together to App Service for Linux.
  • One container is marked "isMain": true; the rest are "isMain": false.

Both samples assume Azure App Service for Linux and the sidecar model, where containers in the same app can talk to each other over localhost.

How the pipelines work

1. Build and Publish
   • vsts-blessed-sitecontainers.yml: sets up your language/runtime, installs dependencies, and produces a ZIP artifact of your app. It also uses Docker tasks to build and publish the sidecar container.
   • vsts-only-sitecontainers.yml: uses Docker tasks to build and push multiple container images.
2. Deploy to App Service for Linux
   • Code-based flow: AzureWebApp@1 deploys the ZIP and sidecar containers defined in sitecontainersConfig.
   • Container flow: AzureWebAppContainer@1 deploys your main container and sidecars, defined in sitecontainersConfig.

That’s it: one pipeline run builds, packages, and deploys your main app plus its helper containers.

Quick start

1. Pick a template
   • Built-in runtime on App Service for Linux? Use vsts-blessed-sitecontainers.yml.
   • Already running containers? Use vsts-only-sitecontainers.yml.

2. Add it to your repo Save the YAML as azure-pipelines.yml (or add it as a new pipeline in Azure DevOps).

3. Fill in the placeholders
   • azureServiceConnectionId / azureSubscription: your Azure RM service connection.
   • webAppName / appName: the target App Service for Linux app.
   • resourceGroup: where that app lives.
   • containerRegistry, image names, and ports for each container in the multi-container case.
   • Each container in sitecontainersConfig declares its port and whether it’s the main app or a sidecar.

4. Run it in Azure DevOps Create a new pipeline from YAML, authorize the service connections, and run.

5. Check your app In the Azure portal, go to Deployment Center->Containers and your App Service will now show your primary app plus the sidecar containers defined in the pipeline.

Customize to fit

These YAMLs are starting points. You can:

• Add test/lint stages before deployment so you only ship good builds.
• Swap the agent pool (ubuntu-latest vs your own self-hosted pool).
• Deploy to a staging slot first, then swap to production.
• Tune each sidecar in sitecontainersConfig: env vars, ports, credentials, etc.

You don’t have to redesign CI/CD every time you want to add observability, a cache container, or a small inference helper next to your app — you just describe the containers and ship.

Learn more

• Deploy to Azure App Service using Azure Pipelines Full walkthrough for setting up Azure Pipelines with App Service, including service connections and the AzureWebApp@1 / AzureWebAppContainer@1 tasks.

• Sidecars on App Service for Linux How sidecars work, how isMain is used, networking rules (localhost between containers), and common patterns like telemetry/OTEL agents, API helpers, and lightweight caches.

Drop these templates into your pipeline, point them at your app, and you’ve got repeatable CI/CD for multi-containers in App Service.

A quick look at what the new runtime gives you:

1. Faster, more modern JavaScript Node.js 24 ships with the V8 13.6 engine and npm 11. You get newer JavaScript capabilities like RegExp.escape, Float16Array for tighter numeric data, improved async context handling, global URLPattern, and better WebAssembly memory support. All of this means cleaner code and better performance without extra polyfills or libraries. This release line is an even-numbered release and has moved into Long Term Support (LTS) in October 2025, which makes it a safe target for production apps.

2. Cleaner built-in testing workflows The built-in node:test runner in Node.js 24 now automatically waits on nested subtests, so you get reliable, predictable test execution without wiring up manual await logic or pulling in a third-party test framework. That means fewer flaky “test didn’t finish” errors in CI.

For full release details, see the official Node.js 24 release notes: https://nodejs.org/blog/release/v24.0.0

Bring your Node.js 24 app to App Service for Linux, scale it, monitor it, and take advantage of the latest runtime improvements.

Why Python 3.14 matters

Python 3.14 (released October 7, 2025) lands with real performance and runtime improvements.

• Faster under load. Internal interpreter work reduces overhead in common call paths and improves memory behavior, which can translate to lower latency and less CPU churn in web apps and APIs.
• Smarter concurrency. Python 3.14 continues the rollout of subinterpreters and a free-threaded build (no GIL), making it easier to take advantage of multi-core parallelism for CPU-bound or high-throughput workloads. In 3.14, that free-threaded mode is more mature and shows significantly better multi-threaded performance than earlier releases.
• Developer quality-of-life. You get a more helpful interactive REPL (better highlighting and error hints), cleaner typing through deferred annotations, and new template string syntax (“t-strings”) for safe, structured interpolation.

All of that is now available to you on App Service for Linux.

What you should do next

If you’re currently running an older Python version on App Service for Linux, this is a good moment to validate on 3.14:

1. Stand up a staging app or deployment slot on Python 3.14.
2. Run your normal tests and watch request latency, CPU, and memory.
3. Confirm that any native wheels or pinned dependencies you rely on install and import cleanly.

Most apps will only need minor adjustments — and you’ll walk away with a faster, more capable runtime on a platform that keeps the underlying infrastructure patched and production-ready for you.