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-terraas the example. -
A DeepSeek model deployment. We’ll use
DeepSeek-V3.2as 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 ModelAgnosticAgent2) 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.Identity3) 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 loginMake 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 runThe 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
AIAgentabstraction. - 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!
