June 2026 monthly summary for azure-ai-foundry/foundry-samples. Focused on delivering a safer, scalable provisioning path for account-level capability hosts by introducing a declarative opt-in flag, addressing a critical duplication bug, and improving BYO/recovery workflows. Technologies demonstrated include Azure Bicep/ARM templating, modular IaC design, and deployment artifact maintenance. Key changes align with platform conventions and reduce operational risk for customers provisioning capability hosts at scale. What was delivered: - Feature: Added createAccountCapabilityHost opt-in flag to enforce a single account-level capability host; default is false. When enabled, provisioning follows a deterministic path that adheres to platform naming conventions, preserving BYO scenarios and enabling recovery after deletion. The explicit-capability-host path is now gated to prevent double provisioning. - Bug fix: Resolved the duplicate provisioning problem by gating explicit caphost creation behind the opt-in flag, eliminating the scenario where both implicit and explicit caphosts caused deployment timeouts and failures. - Artifacts and docs: Removed legacy createCapHost.sh in favor of the declarative flag-driven approach; updated main.bicep and modules-network-secured/add-account-capability-host.bicep with default naming and conditional behavior; regenerated azuredeploy.json via az bicep build; updated README with usage and recovery scenarios. - Documentation and governance: Ensured BYO and recovery scenarios are documented, clarified platform naming conventions, and aligned module structure for maintainability. Impact: - Reduces provisioning risk, accelerates reliable deployments, and improves recoverability for account-level capability hosts. Business value includes safer provisioning, clearer ownership, and reduced time-to-recovery after deletions. Commit reference: cdacd18dbd1076452df019a92dbff7042479cea3