この記事では、従業員の質問をトリアージし、ITナレッジベースに基づいた回答を提供するMicrosoft Foundryエージェントを活用したContoso ITサービスデスクであるHelpDesk Copilotの開発について論じている。このシステムは、ポリシーによって要求される場合に、実際のチャネルを通じて人間への引き継ぎを行うように設計されている。アーキテクチャは、3つのAzure Container Apps、1つのFoundry Prompt Agent、およびイベント駆動型のチケットパイプラインで構成されている。エージェントは、File Search、create_ticket、get_ticket_statusの3つの機能を持っており、これらは従業員の質問に回答し、必要に応じて問題をエスカレーションするために使用される。このシステムはAzure Container Apps上に構築されており、Terraformによって完全にプロビジョニングされ、APIキーは一切使用せず、すべてのサービス間呼び出しはMicrosoft Entra IDとマネージドIDを使用している。Foundryアカウントでは、ローカルキー認証は完全に無効化されている。アーキテクチャはイベント駆動型になるように設計されており、APIはチケットイベントをService Busトピックに発行し、それがDaprサブスクリプションを通じてワーカーに配信される。ワーカーはチケットをTable Storageにアップサートし、ペイロードをPower Automate HTTPフローに投稿し、それがITチームのTeamsチャネルにAdaptive Cardを送信する。このシステムは冪等性を持つように設計されており、チケットIDは会話IDと件名から決定論的に導き出されるため、同じ会話で同じ問題に対して繰り返しcreate_ticketツールを呼び出しても、重複を作成するのではなく、同じIDに収束する。また、このシステムは結果整合性を使用しており、ワーカーがKEDAによって起動される間、チケット行は数秒間存在しない可能性がある。アーキテクチャはスケーラブルになるように設計されており、APIを変更することなくService Busトピックに新しいサブスクリプションを追加できる。IDモデルは、DefaultAzureCredentialを介してEntra IDを使用するように設計されており、各アプリはユーザー割り当てマネージドIDを使用している。API、ワーカー、フロントエンドはそれぞれ独自のIDを持っており、APIはAcrPull、Foundryエージェントアクセス、Storage Table Data Reader、Key Vault Secrets User、Service Bus Senderへのアクセス権を持つ。ワーカーはAcrPull、Storage Table Data Contributor、Key Vault Secrets User、Service Bus Receiverへのアクセス権を持ち、フロントエンドはAcrPullへのアクセス権のみを持つ。この記事では、AzureリソースのプロビジョニングにTerraformを使用することについても論じており、著者は、明白に見えるリソースが常に正しいとは限らないと指摘している。著者は、azapiではなく、azurerm_cognitive_accountを使用してFoundry Agent Serviceをプロビジョニングする必要があった。この記事は、システムがセキュア、スケーラブル、イベント駆動型になるように設計されており、サービス間呼び出しの認証にマネージドIDとEntra IDを使用することに重点を置いていると結論付けている。