Create a model agnostic Agent using Microsoft Foundry and Microsoft Agent Framework

Microsoft Agent Framework is the evolution of Microsoft's earlier AI orchestration work, bringing together ideas from projects such as Semantic Kernel and AutoGen into a unified framework for building agentic applications. It gives us a common AIAgent abstraction while letting us choose and switch which AI model powers the agent.

In this post, we are going to build a model-agnostic agent in .NET using Microsoft Agent Framework and Microsoft Foundry. We’ll run the same agent definition against two different model providers, OpenAI and DeepSeek, without introducing provider-specific code into our agent.

At a high level, we’ll:

• Create a .NET console application.
• Connect Microsoft Agent Framework to a Microsoft Foundry project.
• Deploy models from two different providers: OpenAI and DeepSeek.
• Run the same agent definition against both models.
• Use Foundry and Agent Framework to keep provider-specific plumbing away from the application.

Prerequisites

You will need:

• .NET 10 SDK. Agent Framework supports .NET 8 or later; I am using .NET 10 for this example.
• An Azure subscription.
• A Microsoft Foundry project.
• An OpenAI model deployment. We’ll use gpt-5.6-terra as the example.
• A DeepSeek model deployment. We’ll use DeepSeek-V3.2 as the example.
• An identity with permission to use the Foundry project and its model deployments.

1) Create the .NET project

Create a new console application:

dotnet new console -n ModelAgnosticAgent --framework net10.0
cd ModelAgnosticAgent

2) Install Microsoft Agent Framework packages

Install the Foundry integration and Azure authentication packages:

dotnet add package Microsoft.Agents.AI.Foundry --prerelease
dotnet add package Azure.AI.Projects --prerelease
dotnet add package Azure.Identity

3) Deploy two models from different providers

This is the key part of the example.

We are deliberately not building our application around an OpenAI-specific SDK or model client.

Instead, we’ll deploy two models in Microsoft Foundry:

• OpenAI: gpt-5.6-terra
• DeepSeek: DeepSeek-V3.2

These come from completely different model providers, but our application will access both through the same Foundry project and use the same Agent Framework programming model.

Our application knows how to work with an AIAgent. Foundry handles access to the underlying model deployments.

If we later decide that another model gives us better quality, latency, cost, or capabilities, we don't want that decision to require redesigning the application.

Deploy the OpenAI model

Use:

Microsoft Foundry > Discover > Models > gpt-5.6-terra > Deploy > Default settings

Give the deployment a recognizable name, for example:

gpt-5-6-terra

Deploy the DeepSeek model

Now deploy the second model:

Microsoft Foundry > Discover > Models > DeepSeek-V3.2 > Deploy > Default settings

For example:

deepseek-v3-2

We now have models from two different providers available through the same Foundry project.

4) Configure the Foundry connection

Open your Foundry project and copy its project endpoint.

Microsoft Foundry > <your project> > Overview

It should look similar to:

https://<resource>.services.ai.azure.com/api/projects/<project>

One Foundry project endpoint gives our application access to both model deployments. We are not configuring a different endpoint for each model.

Switching the model therefore becomes a configuration decision rather than an architecture decision.

5) Authenticate to Microsoft Foundry

The sample uses DefaultAzureCredential, so it does not need an API key in the source code. For local development, the easiest option is to sign in with the Azure CLI:

az login

Make sure the signed-in identity has access to the Foundry project and its model deployments. The Azure AI User role is typically enough to run this sample. Depending on your organization, an administrator may need to assign this role for you.

The sample excludes managed identity because it is designed to run locally. For an application hosted in Azure, you can enable managed identity and assign the same required access to that identity.

6) Minimal working example

Here is the minimal console application that consumes our models and provides us with a common abstraction:

Change these values:

• YOUR_FOUNDRY_PROJECT_ENDPOINT: the project endpoint copied in the previous step.
• YOUR_OPENAI_MODEL_DEPLOYMENT_NAME: the name of your OpenAI deployment.
• YOUR_DEEPSEEK_MODEL_DEPLOYMENT_NAME: the name of your DeepSeek deployment.

These must be the deployment names from your Foundry project, not necessarily the underlying model names shown in the model catalog.

7) How the model abstraction works

The important part is the CreateAgent function:

AIAgent CreateAgent(string modelDeployment) =>
    projectClient.AsAIAgent(
        model: modelDeployment,
        instructions: instructions,
        name: "M365Assistant");

It receives a deployment name but returns the same AIAgent abstraction in both cases. The instructions, prompt, and code used to run the agent remain unchanged. We only select a different model deployment.

Both agents are then invoked through the same RunAsync method:

Console.WriteLine(await openAiAgent.RunAsync(prompt));
Console.WriteLine(await deepSeekAgent.RunAsync(prompt));

There is no OpenAI-specific client for one call and a DeepSeek-specific client for the other. That is the value of keeping the application centered on the Agent Framework abstraction.

8) Run the application

Run the console application:

dotnet run

The application sends the same prompt to both agents and prints each response separately. The exact wording will vary because the responses are generated independently by the two models.

We now have the same agent instructions and prompt running against models from two different providers, without changing the application’s programming model.

What “model agnostic” means here

Model agnostic does not mean that every model behaves identically. It means that the application depends on a common agent abstraction instead of a provider-specific client.

The following parts remain the same:

• The Foundry project endpoint.
• The AIAgent abstraction.
• The agent instructions and user prompt.
• The code used to invoke the agent.

Some model characteristics can still differ:

• Response quality and style.
• Latency and cost.
• Context window and token limits.
• Tool calling, structured output, and other model capabilities.

This abstraction makes it much easier to compare models or switch providers, but the selected model should still be tested against the capabilities your application requires.

Wrapping up

In this post, we created one agent definition and ran it against OpenAI and DeepSeek model deployments through the same Microsoft Foundry project. The application works with AIAgent, while the deployment name determines which model powers it.

This gives us a clean boundary for experimenting with different models. We can compare quality, latency, cost, and capabilities without redesigning the application each time we change providers.

Hope this helps!