Microsoft Foundry Extension for Azure Developer CLI Reaches 1.0: Build, Test and Deploy AI Agents

What actually reached GA​

The announcement comes from John Miller, a senior product manager, on the Azure SDK Blog. It describes the Foundry extension as the layer that adds agent setup and local testing to azd, which already provisions Azure resources and deploys code. Agent and deployment settings live in azure.yaml, next to your code.

The label needs a precise reading. Microsoft Learn lists microsoft.foundry as a meta-package that bundles the seven core Foundry extensions, and says the package contributes no commands of its own. Those extensions include azure.ai.agents, azure.ai.connections, azure.ai.routines, azure.ai.skills and azure.ai.toolboxes. The Learn page also lists the inspector and project extensions. In practice, 1.0 means the recommended one-step install is now at a stable version.

Don't assume everything in the azd ai namespace is GA. An earlier Microsoft post on the azd extension framework going GA said that framework GA does not automatically make every extension, or every capability inside one, generally available. It added that extension owners can release and version features independently. Microsoft Learn's installation page also flags some items as preview. Optional extras such as evaluations, datasets and fine-tuning are installed separately. Check the status of each capability before you rely on it in production.

What you need before you start​

• Azure Developer CLI 1.37.0 or later. Upgrade with azd update. Microsoft Learn gives the same minimum version.
• A current uv release. Standalone installations update with uv self update.
• Python 3.13 or later for the sample in the walkthrough.
• An Azure subscription, Foundry permissions, and model quota in your chosen region.
• Costs. Microsoft says provisioned resources and model usage incur Azure charges.

Sign in and install the bundle:

azd auth login
azd ext install microsoft.foundry

If you are also signed in to Azure CLI (az), use the same account and tenant for both tools. The sample uses DefaultAzureCredential, which can pick up that login for local model calls. A mismatched tenant is an easy way to end up looking at the wrong subscription.

The hosted-agent workflow, step by step​

In Foundry, a hosted agent runs your own agent code on managed compute. You pick the framework and orchestration logic, and Foundry manages the runtime.

1. Initialize. In an empty directory, run azd ai agent init. Point --template at Microsoft's basic Python Agent Framework Responses sample, and add --deploy-mode code and --src .. The --src . option initializes the project in the current directory. You can choose a new or existing Foundry project during setup. To reuse a model deployment, add --model-deployment <existing-deployment-name>.
2. Review azure.yaml. This file describes the agent and the Azure resources it needs. Commit it so that deployment changes go through the same pull request as the code. Each azd environment supplies the target subscription, region and resource settings. You don't have to write infrastructure files up front. If you need to customize provisioning, you can eject editable Bicep or Terraform and keep using azd provision.
3. Provision. azd provision creates the declared resources, including missing model deployments in a reused project. Choose an available online deployment type, such as Global Standard or Data Zone Standard. Options and quota vary by subscription and region.
4. Test locally. Run azd ai agent run. It installs dependencies and opens Agent Inspector. In a second terminal in the project directory, run azd ai agent invoke --local "your prompt". Local testing is not fully offline, because model calls still go to your Azure deployment.
5. Deploy. azd deploy uploads your source to Foundry for a remote build, so you don't need a local container build. The output includes playground and endpoint links. Invoke the deployed agent with azd ai agent invoke "your prompt".

Three commands help day to day:

• azd deploy --preview reviews hosted-agent configuration changes.
• azd ai agent monitor --follow streams logs.
• azd ai agent doctor diagnoses setup and permission problems.

Treat the sample values as sample values​

The sample manifest declares a gpt-5.4-mini OpenAI-format deployment, model version 2026-03-17, the GlobalStandard SKU and capacity 10. The agent service points at a Python 3.13 runtime with main.py as its entry point. It requests 0.5 CPU and 1Gi of memory. These are demo settings. Microsoft doesn't promise that this model, SKU or capacity is available in every region or subscription. If provisioning fails, check quota and regional availability first.

Evaluations and CI/CD​

Evaluation is optional and needs a separate extension. Microsoft's flow looks like this:

1. Install azure.ai.evaluations.
2. Run azd ai eval generate, describe what the agent should do, and choose Dataset and evaluator and Turn.
3. Review the generated dataset and rubric.
4. Run azd ai eval init --name quality, select the generated assets and confirm the judge model.
5. Check evals/azure.eval.yaml and its service reference in azure.yaml.
6. Run azd up to register the assets, then azd ai eval run start --eval quality.

Microsoft says azd ai agent optimize can reuse a configured evaluation as its baseline. It also says to review candidate changes before you deploy one. Generated test data and a model judge are a starting point. They don't prove an agent is ready for production.

For pipelines, run azd up once locally, then run azd pipeline config. That command sets up authentication, repository settings and a workflow for you to review and commit. Microsoft's GitHub Actions excerpt installs azd with Azure/setup-azd@v2 pinned to 1.37.0. It then installs microsoft.foundry and azure.ai.evaluations, and runs azd up --no-prompt. The excerpt is deliberately incomplete, and sign-in must happen before deployment, so keep the generated checkout, sign-in and environment settings.

Microsoft's guidance for pipelines:

• Grant the pipeline identity the Azure permissions it needs.
• Use a separate azd environment for each stage.
• Keep runtime credentials in pipeline secrets.
• Commit evals/azure.eval.yaml and any nonsecret assets it needs.
• Give the pipeline access to the referenced datasets and evaluators.
• Run azd ai eval run start --eval quality --no-prompt after deployment.

Cleanup: read this before running azd down​

This is the step most likely to bite. If the demo created a new Foundry project, azd down deletes its resource group and everything in it. Read the deletion prompt before you confirm. If you reused an existing project, azd down leaves the project and its resources in place, including the hosted agent. You then need to remove anything unwanted separately, and Microsoft points to the quickstart's cleanup guidance for that. Forgetting this can leave a billable agent running.

Using a coding agent instead​

Microsoft also describes a Microsoft Foundry Skill for coding agents such as GitHub Copilot and Claude Code. In an empty folder, you ask the agent to scaffold the basic Python Agent Framework Responses sample with code deployment. The suggested prompt tells it to configure azure.yaml, help you choose the project, subscription, region and model deployment, and wait for your approval before creating Azure resources. It should then test locally and stop. That approval gate is worth keeping, because an agent with Azure permissions can otherwise create billable resources unprompted.

Analysis: what this means for teams​

The main benefit is consolidation. Keeping agent definitions, model deployments and compute settings in azure.yaml means a reviewer can see a prompt-adjacent code change and the infrastructure change in one diff. The same file feeds local runs and CI/CD. That fits the infrastructure-as-code habits many Azure teams already have.

The caveats are real:

• The evidence is Microsoft's own. The performance and productivity benefits are the vendor's claims. Neither Microsoft's announcement nor its documentation offers independent measurements or adoption data.
• The workflow is Azure-specific. Local testing still needs an Azure model deployment, so you can't develop offline.
• Preview features remain. A 1.0 bundle doesn't mean every capability is stable.
• There are alternatives. Microsoft Learn says Foundry hosted agents can also be built through the Python SDK, Visual Studio Code and the portal. Microsoft positions the azd route as the best fit when you want to manage infrastructure and agents together under source control.

Upgrading​

If you already installed the bundle during the beta period, run azd ext upgrade microsoft.foundry. Afterward, azd ext list should show microsoft.foundry plus its core extensions. Individual extensions are versioned independently, so you can pin or upgrade them one at a time. That is useful in CI, where a repeatable build matters more than the newest release.