[ext-agents] `azd provision <agent>` fails ("no layers defined in azure.yaml") in multi-service projects, leaving manifest resources (toolbox) unprovisioned

[therealjohn]

Summary

In a multi-service azd project (one azure.yaml with multiple azure.ai.agent blocks), azd provision <agent> fails immediately with ERROR: no layers defined in azure.yaml. Because provision never runs, any non-model resources declared in an agent's agent.manifest.yaml resources: block (for example kind: toolbox) are never created. azd deploy <agent> only handles the model (read from azure.yaml's deployments: block), so the toolbox is silently dropped and the failure surfaces only at first invoke.

Background -- the documented contract

The upstream sample agent-framework/responses/04-foundry-toolbox declares a toolbox in its manifest, and its README says azd provision reads resources: and creates the toolbox (plus model deployments, and presumably connections / search indexes / other kind: values). That works on the upstream single-project layout (one azd project per agent).

# agent.manifest.yaml
resources:
  - kind: model
    id: gpt-5.4
    name: AZURE_AI_MODEL_DEPLOYMENT_NAME
  - kind: toolbox
    name: foundry-toolbox-tools
    tools:
      - type: code_interpreter
        name: code_interpreter

Repro

# Repo with multiple agents in one azure.yaml, including one whose
# manifest declares kind: model and kind: toolbox.
azd provision contract-review-pro --no-prompt

Observed

Provisioning Azure resources (azd provision)
Provisioning Azure resources can take some time.

ERROR: no layers defined in azure.yaml

azd provision (without an agent name) fails the same way. There is no flag combination that makes azd provision work on a multi-service project. The error suggests the command is hardcoded to assume the upstream single-project layout (infra/main.bicep + infra/layers/).

Runtime consequence

1. azd deploy <agent> succeeds (image pushed, version registered).
2. First azd ai agent invoke <agent> returns status=failed, error.code=server_error, output=[]. The envelope tells you nothing.
3. Container logs show:

   POST .../toolboxes/<agent>-tools/mcp?api-version=v1 -> 404
   McpError: Session terminated
   ToolExecutionException: Failed to enter context manager for toolbox '<agent>-tools'
   

4. GET .../toolboxes?api-version=v1 returns {"data": []} -- the toolbox was never created.

Expected (one of)

• Best: azd deploy <agent> reads the manifest's resources: block and provisions everything declared there (model, toolbox, connection, ...) before registering the agent version -- self-contained for the multi-service layout.
• Alternative: azd provision <agent> works on multi-service projects, materializing exactly the resources declared in that agent's manifest.
• At minimum (cross-cutting): when azd deploy <agent> encounters a non-model resource kind it does not handle, emit a warning pointing to the supported provisioning path, instead of exiting 0 with the resource silently dropped.

Workaround

Provision the toolbox out-of-band via the SDK (AIProjectClient.beta.toolboxes.create_version(...)), reading the agent's manifest to emit the equivalent call. This works but compensates for a CLI gap, not a missing platform feature.

Impact

Every agent that uses a Foundry Toolbox (Code Interpreter, Web Search, Browser Automation, Computer Use, Bing Grounding, ...) is undeployable from a multi-service azd project without the SDK workaround. This blocks the entire toolbox catalog for the multi-agent layout the samples encourage.

Diagnosing this also required hand-rolling container-log streaming, because the server_error envelope has no traceback; see #8585 (there is no azd ai agent logs command today).

Environment

• azd 1.25.4; azure.ai.agents 0.1.36-preview (also reproduced on 0.1.38-preview)
• Linux (Ubuntu via WSL2)
• Project shape: 1 root azure.yaml, 7 azure.ai.agent service blocks, shared .azure/<env>/