AI agents are evolving from simple chatbots into autonomous systems capable of planning tasks, invoking tools, retrieving enterprise data, and collaborating with other services. Building these applications requires more than just connecting an LLM to an API. A production-ready AI agent platform needs orchestration, observability, secure tool access, and scalable infrastructure.

Three technologies complement each other particularly well in the .NET ecosystem:

  • .NET Aspire for orchestrating cloud-native distributed applications.

  • Semantic Kernel for AI orchestration, memory, and plugin execution.

  • Model Context Protocol (MCP) for exposing standardized tools that AI agents can discover and invoke.

Together, they provide a strong foundation for building enterprise-grade AI platforms. This article explores how these technologies work together and demonstrates how to build a production-ready architecture.

Understanding the Role of Each Technology

.NET Aspire

.NET Aspire simplifies the development and orchestration of distributed applications. It provides service discovery, centralized configuration, health checks, telemetry, and dashboarding, making it easier to manage applications composed of multiple services.

It is responsible for infrastructure concerns such as:

  • Service orchestration

  • Configuration management

  • Distributed diagnostics

  • Service discovery

  • Local development experience

Semantic Kernel

Semantic Kernel acts as the AI orchestration layer.

Its responsibilities include:

  • Prompt execution

  • AI planning

  • Function invocation

  • Plugin management

  • Memory integration

  • LLM communication

Instead of manually calling an LLM for every task, Semantic Kernel coordinates AI workflows while keeping business logic organized.

Model Context Protocol (MCP)

MCP standardizes how AI agents discover and invoke external tools.

Rather than building custom integrations for every application, MCP allows agents to communicate with enterprise services using a consistent protocol.

Typical MCP tools include:

  • Customer lookup

  • Product search

  • Inventory queries

  • Ticket creation

  • Document retrieval

  • Workflow automation

How These Technologies Work Together

A production-ready AI platform separates responsibilities rather than combining everything into a single application.

                User
                  │
                  ▼
          ASP.NET Core API
                  │
                  ▼
          Semantic Kernel
                  │
      ┌───────────┴───────────┐
      ▼                       ▼
    LLM                  MCP Server
                              │
             ┌────────────────┴──────────────┐
             ▼                               ▼
      Business Services               Enterprise APIs
             │
             ▼
        SQL / External Systems

In this architecture:

  • ASP.NET Core exposes application endpoints.

  • Semantic Kernel determines how to solve the user's request.

  • MCP provides standardized tool execution.

  • Business services contain application logic.

  • .NET Aspire orchestrates every service while providing centralized monitoring.

This separation makes the platform easier to scale and maintain.

Setting Up a .NET Aspire Solution

Create an Aspire solution and register your services.

var builder = DistributedApplication.CreateBuilder(args);

builder.AddProject<Projects.Api>("api");

builder.AddProject<Projects.McpServer>("mcp");

builder.AddProject<Projects.InventoryService>("inventory");

builder.Build().Run();

Why This Configuration?

Instead of manually configuring networking and service dependencies, Aspire automatically handles service discovery and orchestration.

This reduces infrastructure configuration and makes local development closely resemble production deployments.

Building the AI Orchestration Layer

Semantic Kernel can be registered using dependency injection.

builder.Services.AddKernel()
    .AddOpenAIChatCompletion(
        modelId: "gpt-4.1",
        apiKey: builder.Configuration["OpenAI:ApiKey"]);

Why Use Dependency Injection?

Registering Semantic Kernel through dependency injection allows the kernel to be reused across controllers, services, and background workers. It also simplifies testing by allowing mock implementations during unit testing.

Avoid creating kernel instances manually inside controllers, as this leads to unnecessary object creation and tightly coupled code.

Creating an MCP Tool

Suppose your AI assistant needs to retrieve product information.

Create a business service.

public interface IInventoryService
{
    Task<ProductDto?> GetProductAsync(int id);
}

Implementation:

public class InventoryService : IInventoryService
{
    public async Task<ProductDto?> GetProductAsync(int id)
    {
        // Retrieve product from database
    }
}

Expose the service through an MCP endpoint.

app.MapPost("/tools/product", async (
    int id,
    IInventoryService service) =>
{
    var product = await service.GetProductAsync(id);

    return product is null
        ? Results.NotFound()
        : Results.Ok(product);
});

Why Keep the Endpoint Thin?

Notice that the endpoint contains almost no business logic.

Instead, it delegates the work to the application service. This keeps the MCP layer focused on protocol handling while allowing business logic to be reused by APIs, background jobs, or other services.

End-to-End Production Workflow

Let's consider an enterprise support assistant.

A customer asks:

"Do we still have Product 1205 in stock?"

The workflow is as follows:

  1. The user sends a request to the ASP.NET Core API.

  2. Semantic Kernel analyzes the prompt.

  3. The kernel determines that inventory data is required.

  4. It discovers the Product Lookup MCP tool.

  5. The MCP server validates the request.

  6. The Inventory Service retrieves data from the database.

  7. The MCP server returns structured JSON.

  8. Semantic Kernel combines the tool result with the LLM response.

  9. The user receives a natural language answer containing live inventory information.

This approach prevents the language model from guessing inventory data while ensuring responses are based on real-time enterprise systems.

Adding Observability with Aspire

Modern AI platforms are distributed systems. Without proper monitoring, diagnosing failures becomes difficult.

Aspire automatically integrates with OpenTelemetry, enabling:

  • Request tracing

  • Metrics collection

  • Health checks

  • Dependency monitoring

  • Service diagnostics

This centralized observability allows developers to trace an AI request across multiple services, from the API to the MCP server and database.

Comparison of Responsibilities

TechnologyPrimary ResponsibilityTypical Use Case
.NET AspireApplication orchestrationDistributed applications
Semantic KernelAI orchestrationPlanning and tool invocation
MCPTool communicationEnterprise integrations
ASP.NET CoreHTTP APIsClient communication

Each technology solves a different problem, and combining them creates a well-structured AI platform.

Best Practices

  • Keep AI orchestration separate from business logic.

  • Design MCP tools to perform one clear responsibility.

  • Register services using dependency injection.

  • Use Aspire for service orchestration instead of manual configuration.

  • Return structured JSON from MCP tools.

  • Monitor every AI workflow with OpenTelemetry.

  • Version MCP tools to maintain compatibility.

  • Validate all tool inputs before execution.

Common Mistakes

One common mistake is allowing the language model to access databases directly. AI models should interact with business data through controlled services such as MCP tools rather than unrestricted database access.

Another mistake is embedding business logic inside Semantic Kernel plugins or API controllers. Business rules belong in dedicated application services where they can be tested, reused, and maintained independently.

Teams also sometimes expose every internal API through MCP. Only capabilities that AI agents genuinely need should be published as tools.

Testing and Validation

Before deploying an AI platform, validate every layer independently.

Recommended testing includes:

  • Unit tests for business services

  • Integration tests for MCP endpoints

  • Semantic Kernel plugin testing

  • API contract testing

  • Authentication and authorization testing

  • End-to-end AI workflow testing

  • Load testing for concurrent tool execution

Testing each layer separately makes it easier to isolate failures and maintain reliability as the platform evolves.

Performance Considerations

AI applications introduce additional latency due to LLM interactions, making performance optimization essential.

Consider the following practices:

  • Keep MCP handlers lightweight.

  • Cache frequently requested reference data.

  • Use asynchronous APIs throughout the application.

  • Minimize unnecessary LLM calls by invoking tools only when required.

  • Reuse HTTP clients and AI service instances through dependency injection.

  • Monitor request latency with OpenTelemetry.

Measure performance under production-like workloads rather than relying on assumptions.

Security Considerations

AI platforms expose enterprise capabilities, making security a fundamental requirement.

Follow these recommendations:

  • Require authentication for every MCP tool.

  • Apply role-based or policy-based authorization.

  • Validate all tool parameters.

  • Never expose internal exceptions to AI clients.

  • Store API keys securely using a secret management solution.

  • Encrypt all communication with HTTPS.

  • Implement rate limiting to prevent abuse.

  • Audit every tool invocation for compliance.

Following the principle of least privilege ensures AI agents can only perform explicitly authorized actions.

Troubleshooting

MCP Tools Are Not Discovered

Verify that tool endpoints are correctly registered and accessible. Ensure the MCP server is running and that discovery metadata is available.

Semantic Kernel Does Not Invoke a Tool

Review plugin registration and confirm that the tool description clearly communicates its purpose. Ambiguous descriptions can prevent the model from selecting the appropriate tool.

Service Discovery Issues

If Aspire services cannot communicate, verify project registration and ensure all dependent services are running within the distributed application.

Slow AI Responses

Measure the latency of each stage—LLM requests, MCP execution, database queries, and external API calls—to identify the actual bottleneck rather than assuming the AI model is the cause.

Conclusion

Building a production-ready AI agent platform requires more than integrating an LLM into an application. .NET Aspire, Semantic Kernel, and MCP each address a different aspect of the architecture—distributed application management, AI orchestration, and standardized tool communication. By keeping responsibilities separate, exposing business capabilities through secure MCP tools, and leveraging Aspire for orchestration and observability, developers can build scalable, maintainable, and enterprise-ready AI platforms that are prepared for real-world production workloads.