Skip to main content
Items marked (preview) in this article are currently in public preview. This preview is provided without a service-level agreement, and we don’t recommend it for production workloads. Certain features might not be supported or might have constrained capabilities. For more information, see Supplemental Terms of Use for Microsoft Azure Previews.
The azure.yaml file is the single Azure Developer CLI (azd) project configuration for a hosted agent project. It declares your Foundry resources — the project, model deployments, connections, toolboxes, skills, routines, and the agents themselves — as a set of services, and it tells azd how to provision and deploy them. This unified file replaces the earlier two-file model that split configuration between agent.manifest.yaml and agent.yaml. To learn how to compose and author this file step by step, see Author azure.yaml for hosted agents.

How azd uses azure.yaml

The Azure Developer CLI streamlines the developer-to-cloud workflow. It handles two things: provisioning Azure resources, such as Foundry projects, model deployments, and container registries; and deploying your code to those resources. For hosted agents, the azure.ai.agents extension adds agent-specific commands such as azd ai agent init and azd ai agent run. Every azd project has an azure.yaml file at its root. For agent projects, this file is the source of truth for both the agent configuration and the deployment configuration.

Environments

An environment is a named configuration, such as dev, staging, or prod, that stores settings for a particular deployment. Each environment tracks the Azure subscription and location, the resource group and resource names, and any custom variables you set. Settings are stored locally in .azure/<env-name>/.env. You can have multiple environments for the same project.

Core commands

The split-service model

Under services, each entry is a named service with a host field that identifies the kind of Foundry resource it declares. Services reference each other through the uses field, which forms a dependency graph that azd resolves at provision and deploy time. A typical project has one azure.ai.project service that owns the model deployments and one azure.ai.agent service that depends on it.

Minimal example

Full example

The following project adds a connection, a toolbox, and private networking.

Top-level fields

azure.ai.project service

The project service provisions or connects to a Foundry project and owns its model deployments.

deployments

A deployment entry can also be an external file include: - $ref: ./deployments/embeddings.yaml.

network

Set network to provision a network-secured account. The peSubnet field is required and establishes the account private endpoint. Add agentSubnet to inject the agent runtime into your own subnet (bring your own virtual network), or omit it to use the Microsoft-managed network. For a complete walkthrough, see Hosted agent private networking.

azure.ai.agent service

The agent service carries the agent definition and its build and deploy settings. It’s the service that replaces the old agent.yaml.

protocols

For the full protocol specification, see Hosted agent runtime contract.

env

The ${ } syntax references azd environment variables from .azure/<env>/.env.
Don’t declare FOUNDRY_PROJECT_ENDPOINT in env. The platform injects it automatically into hosted containers, and azd ai agent run sets it for local development. Declaring it here is redundant and risks shadowing the platform value.

container

Set cpu from "0.25" up to "4.0", and memory from 0.5Gi up to 8.0Gi.

azure.ai.connection service

A connection links the project to an external resource. The service key is the connection name, and the service depends on the project through uses.

azure.ai.toolbox service

A toolbox is a named bundle of tools that agents reference. Connection-backed tools name an azure.ai.connection service through the connection field.
An agent references a toolbox by adding the toolbox service name to both uses and its toolboxes list.

azure.ai.skill and azure.ai.routine services

A azure.ai.skill service defines a reusable behavioral guideline that agents reference by name. A azure.ai.routine service defines a trigger (schedule or event) and an action that invokes an agent. Both depend on the resources they use through uses. For details, see Discover tools in Foundry Tools and Use routines.

Dependencies with uses

The uses field declares the services a given service depends on. azd uses this graph to order provisioning and to wire references, such as an agent’s connections and toolboxes.

File includes with $ref

Any service or list entry can be replaced with a reference to an external YAML or JSON file. Relative paths resolve from the file that contains the $ref. Remote URLs aren’t supported.
File includes let you keep large agent definitions in their own files and share definitions across projects.

Variable substitution

Two substitution syntaxes can appear in azure.yaml:

Infrastructure and deploy modes

Bicep-less by default

azd ai agent init is bicep-less by default: it doesn’t write an infra/ directory, and azd synthesizes the infrastructure from your azure.yaml services at provision time. To materialize infrastructure-as-code files, eject them: When infra is present in azure.yaml, azd uses those files instead of synthesizing infrastructure.

Deploy modes

A hosted agent deploys in one of two modes: For source deploys, the codeConfiguration field on the agent service captures the runtime and entry point. For prebuilt images, set the image field on the agent service and skip the Dockerfile build.

JSON schema validation

Add the schema reference for IDE autocompletion: