Keep model name and deployment name in config

Model and deployment choices change over time. You may move between providers, switch Azure OpenAI deployments, test a cheaper model, split routing by endpoint, or roll back after a regression.

Keep those names in configuration instead of scattering them through controllers, agents, services, and background jobs. The application should ask for a configured chat model, embedding model, evaluation model, or deployment name through options or a small routing abstraction.

This is especially important with Azure OpenAI, where the deployment name is not always the same thing as the model name. Hard-coding one string in five places makes a model rollout look like a code refactor.

In .NET, put that decision in the composition root. Register the configured IChatClient once, then let application code depend on the abstraction:

using Azure.AI.OpenAI;
using Azure.Identity;
using Microsoft.Extensions.AI;
using Microsoft.Extensions.DependencyInjection;

string endpoint = builder.Configuration["AzureOpenAI:Endpoint"]
    ?? throw new InvalidOperationException("Missing Azure OpenAI endpoint.");

string deployment = builder.Configuration["AzureOpenAI:ChatDeployment"]
    ?? throw new InvalidOperationException("Missing Azure OpenAI deployment.");

builder.Services.AddChatClient(
    new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
        .GetChatClient(deployment)
        .AsIChatClient());

public sealed class SupportAgent(IChatClient chatClient)
{
    public async Task<string> SummarizeAsync(string input)
    {
        var response = await chatClient.GetResponseAsync(input);
        return response.Text;
    }
}

Now SupportAgent does not know the deployment name, the model version, or the provider. If you need a fast summarization model and a heavier reasoning model, use keyed services or a small routing service at the DI boundary. Keep the keys stable and keep the actual deployment names in configuration.

Configuration does not remove the need for tests. Treat model changes like behavior changes. Run evals, watch latency and cost, and keep enough telemetry to know which model or deployment produced a bad result.

The practical rule: model identity is operational configuration, not domain logic.