How to Integrate an AI Agent into an ASP.NET Core Application?

Microsoft.Extensions.AI provides common .NET abstractions such as IChatClient and IEmbeddingGenerator<TInput,TEmbedding>.

This gives applications a consistent way to interact with different AI services.

It’s useful when your application needs:

→ Chat

→ Text generation

→ Embeddings

→ Model interaction

→ AI middleware

→ Provider flexibility

Microsoft explicitly describes this layer as a common abstraction for AI services rather than an agent framework itself.

When your application needs goal-oriented, multi-step behavior, Microsoft Agent Framework provides the agent abstraction, tools, sessions, workflows, and hosting capabilities.

Microsoft’s current guidance positions Agent Framework for agentic applications and multi-step orchestration.

Microsoft Foundry Agent Service provides a managed environment for building, deploying, and scaling AI agents. It supports prompt agents and hosted agents, along with tools, identity, observability, versioning, and other enterprise capabilities.

So the choice can broadly look like:

Good agent use cases have a clear goal and access to useful tools.

For example: Customer support agent

→ Find customer account

→ Retrieve order information

→ Check delivery status

→ Search support knowledge

→ Create support ticket

→ Escalate when required

This is more useful than simply adding a chatbot that answers questions.

Microsoft currently supports multiple ways to host agents.

You can host an Agent Framework application yourself inside an ASP.NET Core application, expose it through protocols such as A2A or AG-UI, or use Microsoft Foundry Agent Service as a managed runtime.

Self-hosted

Your ASP.NET Core application controls routing, identity, authorization, storage, deployment, scaling, and request policies.

Microsoft specifically recommends this pattern when the agent endpoint needs to integrate closely with existing application infrastructure.

Managed with Microsoft Foundry

Foundry Agent Service manages the agent runtime, conversations, tools, identity, observability, and scaling.

This can make sense when the organization wants a managed platform around its agents.

Microsoft’s current .NET AI ecosystem supports providers, including Azure OpenAI, Microsoft Foundry, OpenAI, Ollama, Google Gemini, and Amazon Bedrock.

Microsoft.Extensions.AI provides a common abstraction layer across supported providers.

For enterprise applications already operating on Azure, Microsoft Foundry and Azure OpenAI can be natural choices depending on the application’s requirements.

Instructions define the agent’s role, goals, boundaries, and expected behavior.

The instruction layer should establish clear boundaries around what the agent can and cannot do.

For enterprise applications, those boundaries become particularly important when the agent can access customer records, financial information, internal documents, or business operations.

Tools are what allow an agent to interact with the application.

A tool might call:

→ An ASP.NET Core service

→ An internal API

→ A database

→ A search system

→ A document repository

Microsoft Foundry Agent Service currently supports built-in tools as well as custom tools and MCP servers.

This means your existing business capabilities can become controlled tools available to the agent.

An agent becomes considerably more useful when it can work with the organization’s own information.

For knowledge-heavy use cases, retrieval-augmented generation can provide the agent with relevant information before generating a response.

For action-oriented use cases, tools and APIs allow the agent to interact with business systems.

The important architectural distinction is:

Knowledge → retrieval

Action → tools/API

That separation helps keep the system easier to control and maintain.

ASP.NET Core already provides authentication and authorization mechanisms that can be applied around application endpoints and services.

For agent integrations, access should be limited according to:

→ User identity

→ Roles

→ Permissions

→ Data access

→ Tool permissions

→ Business policies

Microsoft Foundry Agent Service includes Microsoft Entra identity, RBAC, content filters, and virtual network isolation as part of its enterprise capabilities.

Agents often need context across multiple interactions.

Microsoft’s current agent model supports sessions, which allows an agent to maintain context between turns. The Foundry platform also uses conversations to persist interaction history.

For example:

User: Check my latest order.

Agent: Your order is scheduled for Friday.

User: Can you change the delivery address?

The second request depends on information from the first interaction and may also require an authorization check before the agent performs an action.

Microsoft Agent Framework provides hosting libraries specifically for ASP.NET Core.

The hosting layer handles registration and configuration of agents and workflows through the application’s dependency injection infrastructure.

Depending on the application, agents can be exposed through:

→ ASP.NET Core endpoints

→ OpenAI-compatible endpoints

→ A2A

→ AG-UI

Microsoft’s current hosting documentation lists these as supported hosting approaches.

For web-based agent experiences, AG-UI can stream agent events to the client using server-sent events.

An agent can produce different results depending on the prompt, model, tools, retrieved information, and user input.

Testing should therefore cover more than whether an API returns a successful response.

Evaluate:

→ Answer quality

→ Tool selection

→ Tool parameters

→ Retrieval accuracy

→ Unauthorized actions

→ Incorrect assumptions

→ Failure handling

→ Response latency

→ Cost

→ Security

→ Regression across model changes

Microsoft’s current .NET AI ecosystem includes evaluation libraries for assessing AI feature quality and regression behavior.

Production monitoring should help your team understand:

→ What the user asked

→ Which tools the agent called

→ Which model was used

→ How long the request took

→ What errors occurred

→ How much the request cost

→ Whether the agent achieved the intended outcome

Microsoft Foundry Agent Service currently provides tracing, metrics, evaluations, and Application Insights integration for agent observability.

The cost depends on the agent’s complexity, AI model, number of tools, APIs, data sources, security requirements, and deployment environment. A simple agent connected to a few APIs requires less development than a multi-step enterprise agent working across several systems. Ongoing costs can also include model usage, cloud infrastructure, monitoring, and maintenance. A technical assessment can provide a more accurate project estimate.

The timeline depends on the application’s existing architecture, the agent’s capabilities, integrations, data requirements, and testing needs. A focused AI agent connected to existing APIs can be developed faster than an enterprise agent requiring multiple systems and complex workflows. Planning, security, evaluation, and production deployment should also be included in the timeline. The final estimate depends on the specific use case.

An AI agent can be designed with enterprise security controls around identity, authorization, data access, tool permissions, and application endpoints. Sensitive actions can require human approval before execution. Microsoft technologies such as Microsoft Entra ID, role-based access control, content filtering, and network isolation can also support enterprise AI deployments. Security requirements should be defined as part of the agent architecture.

Yes, but database access should be controlled through appropriate application services, APIs, or purpose-built tools rather than giving the agent unrestricted database access. This allows developers to control which information the agent can retrieve or modify. Permissions, validation, logging, and business rules should remain part of the application layer.

An AI agent can do both. When connected to approved tools and APIs, it can retrieve information and perform defined actions within an application. Actions can include creating records, updating information, searching systems, generating documents, or triggering workflows. Sensitive operations can be protected with authorization checks and human approval.