The travel assistant of Nordlicht Reisen GmbH (R-02) runs as an application on a Container App with a managed identity (R-07). It is meant to address a model in the project reiseassistent of the Foundry resource ai-nordlicht without a key being stored anywhere. This lesson shows the .NET side: which packages, how the connection comes about, how a deployment (chat, chat-klein, R-08) is called and how the call fits into the IChatClient of the AI track.
Prior knowledge. The IChatClient, options and middleware are taught by "AI track, lesson T2.1" (through T2.4); model choice by "AI track, lesson T1.3"; resource, project, deployment, quotas and keyless sign-in with Bicep by "AI track, lesson T10.1". The choice of the model per task and the deployment types are the subject of lessons 1.1 and 1.2, the roles of lesson 1.4. None of that is repeated here.
The requirement
All numbers are assumptions of the task.
| No. | Requirement | Type | Measure | Weight | Source |
|---|---|---|---|---|---|
| 2.1-01 | The application calls models of the project without a key. | R | 0 keys in code and configuration | Must | Security (R-07) |
| 2.1-02 | The name of the deployment is in the configuration, never the model in code. | R | 4 names: chat, chat-klein, embed, bild |
Must | Operations (R-08) |
| 2.1-03 | Startup checks that the expected deployments exist in the project. | Q | error at startup instead of at the first customer question | Should | Operations |
| 2.1-04 | Code of the AI track (middleware, counters, tests) stays usable. | F | IChatClient stays the interface |
Should | Development (R-11) |
| 2.1-05 | Every call goes through a counter. | R | 100% of calls | Must | Cost (R-09, R-11) |