Foundry agents in azd

Microsoft Foundry azd extension reaches GA

Microsoft has made the Foundry extension bundle for Azure Developer CLI generally available, adding hosted-agent setup, local testing and deployment through azd.

Article Image Alt

Microsoft says the Microsoft Foundry extension bundle for Azure Developer CLI reached version 1.0 and general availability on 5 November 2026, giving azd a supported path for hosted-agent setup, local testing and deployment. For teams already using azd, the change puts agent and Azure resource configuration alongside application code.

Agent deployment from azure.yaml

Azure Developer CLI provisions Azure resources and deploys application code. The microsoft.foundry extension bundle adds agent setup and local testing, with agent and deployment configuration kept in azure.yaml.

That matters for review and operations. Changes to the agent, model deployment and compute allocation can be reviewed in the same pull request as code changes, and the same configuration can be used locally and in CI/CD.

In Foundry, a hosted agent runs the developer’s own agent code on managed compute. The developer chooses the framework and orchestration logic, while Foundry manages the runtime.

The sample configuration described by Microsoft includes a model deployment, agent source and runtime, compute allocation, and a dependency on the Foundry project. Developers can start without writing infrastructure files, then eject editable Bicep or Terraform files if they need to customise provisioning.

Requirements and installation

The extension requires Azure Developer CLI 1.37.0 or later. Microsoft’s sample also uses a current uv release and Python 3.13 or later.

Teams need an Azure subscription, Foundry permissions and model quota in the selected region. Provisioned resources and model usage incur Azure charges, and deployment options vary by subscription and region.

Installation uses the existing Azure Developer CLI extension model. Developers sign in with azd auth login, then install the bundle with azd ext install microsoft.foundry. If Azure CLI is already signed in, Microsoft advises using the same account and tenant as azd.

Permission requirements depend on whether the workflow reuses an existing Foundry project or creates resources and assigns roles during provisioning. Microsoft’s installation guidance notes that Foundry role names have changed, although the role IDs and core permissions are unchanged.

Build, test and deploy

A new hosted-agent project can be created with azd ai agent init. The setup flow can use the basic Python Agent Framework sample, and the developer chooses a new or existing Foundry project. An existing model deployment can also be reused.

azd provision creates the declared resources, including missing model deployments in a reused project. The flow prompts for model configuration and an available online deployment type, such as Global Standard or Data Zone Standard.

Local testing uses azd ai agent run, which installs dependencies and opens Agent Inspector for the locally running agent. Model calls still use the Azure deployment. A second terminal can invoke the local agent with azd ai agent invoke --local.

Deployment uses azd deploy. The command uploads source to Foundry for a remote build, so a local container build is not required. Deployment output includes playground and endpoint links, and the deployed agent can be invoked with azd ai agent invoke.

The extension also adds operational commands. azd deploy --preview reviews hosted-agent configuration changes, azd ai agent monitor --follow streams logs, and azd ai agent doctor diagnoses setup or permission issues.

CI/CD and evaluation

For automation, azd up packages, provisions and deploys the project. azd pipeline config sets up authentication, repository settings and a workflow for GitHub Actions or Azure DevOps.

Pipelines still need the usual controls. Microsoft’s guidance says the pipeline identity must have the required Azure permissions, each stage should use a separate azd environment, and runtime credentials should be kept in pipeline secrets.

Quality checks can be added through the azure.ai.evaluations extension. The workflow can generate test data and a grading rubric, create an evaluation configuration, register the assets and run the evaluation after deployment. The generated evaluation configuration and non-secret assets can be committed with the code for reuse in CI/CD.

Microsoft also describes a Foundry Skill for coding agents such as GitHub Copilot and Claude Code. It can scaffold the basic Python Agent Framework Responses API sample, configure azure.yaml, help choose the Foundry project, subscription, region and model deployment, and wait for approval before creating Azure resources.

Extension scope and cleanup

microsoft.foundry is a meta-package. It installs the core Foundry extensions for agents, connections, inspector, projects, routines, skills and toolboxes. Optional extensions, including evaluations, datasets, fine-tuning, models and content understanding, are installed separately when a workflow needs them.

Some Foundry-related capabilities keep their own release status. For example, Microsoft marks the Copilot harness opt-in as preview in the installation guidance, and optional extension features can be versioned independently.

Cleanup depends on how the project was created. If the demo used a new Foundry project, azd down deletes the resource group and everything in it after confirmation. If the workflow reused an existing project, azd down leaves the project and its resources, including the hosted agent, in place.

Deciding whether agent configuration belongs in azure.yaml, how hosted-agent deployments move through CI/CD and which permissions are safe to assign are the kinds of implementation issues ECS's Core AI topic covers, alongside agentic AI, Azure AI Foundry, the EU AI Act and responsible AI. Sessions and workshops give attendees access to product group contact and practitioner experience on building, testing and operating agent systems. Bring deployment plans, permission models and evaluation questions to use the conference for discussions that are difficult to settle from command help alone.


This article was written by the ECS editorial team with the assistance of Amal Agent, run.events' AI assistant, which supported the research, drafting and proofreading.