Building a production-grade AI agent in .NET

Using Microsoft Agent Framework, OpenAI, MCP, RAG, and Ollama as building blocks.

One of the most in-demand technical skill sets today is the ability to build AI agents. And it’s not surprising. You hear about such agents everywhere. They do things that were completely unimaginable only a few years ago. Sometimes, they can even go as far as completely automating the tasks that previously required human judgment and were a major part of someone’s job description!

Fortunately, building agents is not that difficult if you already have some software development experience. After all, as I explained previously, an AI agent is nothing other than a piece of software. What makes it an “agent” is the fact that the code inside that piece of software interacts with a model, usually an LLM.

This time, I will take you step by step through the process of building an agent. We will build an agent in the context of a realistic scenario that is similar to what you may encounter in real enterprises. Also, we will cover all the core technical skills that enterprises that are building agents are looking for.

We’ll build a .NET tech support agent using Microsoft Agent Framework. The agent will:

• connect to an OpenAI model,

• expose a chat interface,

• stay inside the scope of technical support,

• use local tools for deterministic support workflows,

• use RAG to search support documentation,

• use MCP to inspect a GitHub repository,

• use agent skills to specialize its behavior,

• and then migrate the model layer to DeepSeek running locally in Ollama to demonstrate how self-hosted models are different from frontier SaaS models.

The interesting part is not just the code. The interesting part is the architecture.

We are not building a magic text generator. We are building a full-on support system where the model is only one component.

What we are building

The agent will be a console-based technical support assistant. A user can ask questions such as:

My GitHub PR build is failing after a .NET SDK upgrade. Can you help me investigate?

The system will then:

1. Check whether the request is in scope.

2. Search approved support documentation using RAG.

3. Pass the user question and retrieved context to the agent.

4. Allow the agent to call tools.

5. Allow the agent to inspect a GitHub repo through MCP.

6. Return a practical support answer with troubleshooting steps.

At a high level, the architecture looks like this:

User
  |
  v
Chat interface
  |
  v
Input guardrails
  |
  v
RAG retrieval from support docs
  |
  v
Microsoft Agent Framework agent
  |
  +--> Local support tools
  |
  +--> GitHub MCP tools
  |
  +--> Agent skills / context providers
  |
  v
Grounded support response

This is a useful pattern because it separates responsibilities.

The model reasons and writes. Tools perform deterministic operations. RAG retrieves trusted knowledge. MCP connects external systems. Guardrails constrain the experience.

That separation is what turns a chatbot into an agent.

Part 1: Build the OpenAI version

We’ll start with an OpenAI-powered version because most enterprises use cloud-hosted frontier models, whether they are made by OpenAI or Anthropic. Later, we’ll swap the model provider to DeepSeek in Ollama to demonstrate how the same setup can work with self-hosted models.

The important design goal is this:

Keep the agent architecture provider-independent wherever possible.

That is why we use Microsoft.Extensions.AI.IChatClient and IEmbeddingGenerator. These abstractions let us replace the model provider without rewriting the agent, tools, RAG pipeline, or MCP integration.

Step 1: Create the .NET project

Create a console application:

dotnet new console -n TechSupportAgent
cd TechSupportAgent

Install the core packages:

dotnet add package Microsoft.Agents.AI
dotnet add package Microsoft.Extensions.AI
dotnet add package Microsoft.Extensions.AI.OpenAI
dotnet add package OpenAI

dotnet add package ModelContextProtocol

dotnet add package Microsoft.Extensions.VectorData
dotnet add package Microsoft.SemanticKernel.Connectors.InMemory --prerelease

For a demo, the in-memory vector store is fine. For production, you probably want a persistent vector database such as Azure AI Search, PostgreSQL with pgvector, Qdrant, Redis, Cosmos DB, or another provider.

What this step is for

This step gives us the building blocks:

• Microsoft.Agents.AI gives us the agent abstraction.

• Microsoft.Extensions.AI gives us provider-neutral AI interfaces.

• Microsoft.Extensions.AI.OpenAI adapts the OpenAI SDK to those interfaces.

• ModelContextProtocol lets us connect to MCP servers.

• Microsoft.Extensions.VectorData gives us vector-store abstractions.

• Microsoft.SemanticKernel.Connectors.InMemory gives us a simple in-memory vector store for prototyping.

In production systems, these abstractions matter. You do not want your whole application hard-coded against one LLM provider. You want the model provider to be replaceable while keeping your domain logic stable.

Step 2: Configure the OpenAI chat model and embedding model

We need two model capabilities:

1. A chat model for conversation and reasoning.

2. An embedding model for RAG search.