azd ai agent init: azure_ai_search tool resource needs to auto-pair a storage dependent resource

[rogerbarreto]

Summary

When an agent agent.manifest.yaml declares kind: tool / id: azure_ai_search and the user runs azd ai agent init, the generated azure.yaml requests only the azure_ai_search dependent resource. azd provision against the azd-ai-starter-basic template then fails because the starter's azure_ai_search.bicep requires a co-provisioned storage account, but init.go does not auto-pair them.

Root cause

init.go only recognizes two tool ids when scanning the manifest's resources: array for things to add to azure.yaml resources: (which becomes AI_PROJECT_DEPENDENT_RESOURCES at provision time):

if toolResource.Id == "bing_grounding" || toolResource.Id == "azure_ai_search" {
    // prompt for connection name
    resourceDetails = append(resourceDetails, project.Resource{
        Resource:       toolResource.Id,
        ConnectionName: resp.Value,
    })
}

There is no notion of storage here, and no logic that auto-adds storage when azure_ai_search is selected, even though the matching starter bicep requires it. Result: a manifest that declares search alone is silently incomplete and the failure only surfaces during provision.

Repro

1. Author an agent.manifest.yaml with kind: tool / id: azure_ai_search (no storage entry, no sample-local infra).
2. azd ai agent init -m <manifest> (accept the prompt for the search connection name).
3. azd provision against the default azd-ai-starter-basic template.
4. Bicep deployment of the azure-ai-search module fails resolving the existing Storage Account reference because storageAccountResourceId is empty.

Why it matters

Hosted-agent samples are being migrated to the manifest-only flow (drop sample-local bicep, lean on the starter). The pattern works cleanly for chat/embedding models and for bing_grounding. It is the only RAG-relevant tool kind currently broken end-to-end.

Triggering case: microsoft-foundry/foundry-samples-pr#283 (Azure AI Search RAG sample for .NET Agent Framework). The README there documents a manual azure.yaml edit as a workaround:

services:
  <agent-name>:
    config:
      resources:
        - resource: azure_ai_search
          connectionName: search
        - resource: storage
          connectionName: storage

Proposed fix

Pair them in init.go: when the user selects azure_ai_search, append a storage project.Resource entry as well (with a deterministic default connection name) so the generated azure.yaml matches the starter's contract. Could be unconditional, or gated by a follow-up confirmation prompt for users who already have storage wired some other way.

A complementary upstream fix on the starter (make storageAccountResourceId optional in azure_ai_search.bicep) is tracked at Azure-Samples/azd-ai-starter-basic#62, but the more user-friendly fix is in the extension because today the manifest is the only contract a sample author touches.

Happy to send a PR if the direction is agreed.

Related

• Azure-Samples/azd-ai-starter-basic#62 - corresponding starter-side gap
• microsoft-foundry/foundry-samples-pr#283 - sample blocked on this