The article discusses the development of a HelpDesk Copilot, a Contoso IT service desk that utilizes a Microsoft Foundry agent to triage employee questions and provide answers grounded in an IT knowledge base. The system is designed to hand off to humans through a real channel when policy demands it. The architecture consists of three Azure Container Apps, one Foundry Prompt Agent, and an event-driven ticket pipeline. The agent has three capabilities: File Search, create_ticket, and get_ticket_status, which are used to answer employee questions and escalate issues when necessary.The system is built on Azure Container Apps, provisioned entirely with Terraform, and contains zero API keys, with every service-to-service call using Microsoft Entra ID and managed identities. The Foundry account has local key authentication disabled outright. The architecture is designed to be event-driven, with the API publishing ticket events to a Service Bus topic, which are then delivered to a worker through a Dapr subscription. The worker upserts the ticket into Table Storage and posts the payload to a Power Automate HTTP flow, which sends an Adaptive Card to the IT team's Teams channel.The system is designed to be idempotent, with the ticket ID derived deterministically from the conversation ID and subject, ensuring that repeated create_ticket tool calls for the same issue in the same conversation collapse to the same ID instead of creating a duplicate. The system also uses eventual consistency, with the ticket row may not exist for a few seconds while the worker is woken up by KEDA. The architecture is designed to be scalable, with the ability to add new subscriptions to the Service Bus topic without changing the API.The identity model is designed to use Entra ID via DefaultAzureCredential, with each app using a user-assigned managed identity. The API, worker, and frontend each have their own identity, with the API having access to AcrPull, Foundry agent access, Storage Table Data Reader, Key Vault Secrets User, and Service Bus Sender. The worker has access to AcrPull, Storage Table Data Contributor, Key Vault Secrets User, and Service Bus Receiver, while the frontend only has access to AcrPull.The article also discusses the use of Terraform to provision the Azure resources, with the author noting that the obvious-looking resources are not always the correct ones. The author had to use azurerm_cognitive_account to provision the Foundry Agent Service, rather than azapi. The article concludes by noting that the system is designed to be secure, scalable, and event-driven, with a focus on using managed identities and Entra ID to authenticate service-to-service calls.