How to Build an AI Agent in ASP.NET Core 10 Using Microsoft Agent Framework and C# – Complete Guide (2026)
How to Build an AI Agent in ASP.NET Core 10 Using Microsoft Agent Framework and C# – Complete Guide (2026)
An order-support assistant becomes useful when it can look up the right order, explain what it found, and prepare the next action. It becomes risky when a convincing model response is treated as permission to change somebody’s data. This tutorial builds the useful part while keeping the permission boundary in ordinary C#.
You will build an AI agent in ASP.NET Core 10 using Microsoft Agent Framework, connect it to OpenAI, expose a small set of product and order tools, maintain separate conversation sessions, stream responses, and require an authenticated human approval before an order is cancelled.
How do you build an AI agent in ASP.NET Core 10?
Register a supported model client, create an AIAgent with instructions and C# function tools, create an AgentSession for each conversation, and invoke RunAsync or RunStreamingAsync from an authenticated API endpoint. Keep authorization, validation, budgets, and approval decisions in server-side code. A system prompt cannot replace those checks.
The example uses synthetic products and orders. It does not integrate a payment gateway, send email, access the filesystem, or issue refunds. Its cancellation approval path changes only the in-memory demonstration order store.
1. What is an AI agent, and how is it different from a chatbot?
An AI agent is software that uses a model to choose actions toward a goal, within capabilities supplied by an application. In this tutorial, the goal is helping a customer understand an order or request cancellation. The capabilities are three typed C# functions. The application decides which customer is signed in and whether a proposed change is allowed.
A traditional chatbot often follows predefined intents and responses. An LLM chatbot generates language. A tool-using agent can additionally request operations such as reading an order. These categories overlap: a chatbot UI can front an agent, and a model can answer without using any tools. “Agent” does not mean unlimited autonomy or reliable reasoning.
The official framework overview describes agents, tools, context providers and workflows. This article uses one agent with local tools. A multi-agent workflow can separate triage, specialist work and review, but each extra participant adds state transitions and model calls. Start with a single agent unless a measured requirement justifies orchestration.
ASP.NET Core is the HTTP and identity boundary. Agent Framework coordinates model messages and tool invocation. The model proposes the next step. Application services enforce business rules. The approval endpoint is the only component allowed to commit cancellation. This separation makes the important behavior testable without asking a model to behave safely.
2. Stable packages, preview features and provider choices
At the research date, Microsoft.Agents.AI.OpenAI 1.27.0 is a stable NuGet release compatible with .NET 10. The sample pins that version rather than copying a blanket --prerelease instruction. Package release status and feature availability must be checked independently.
| Component | Status checked for this guide | Decision |
|---|---|---|
| Microsoft.Agents.AI.OpenAI | 1.27.0, stable | Used for local OpenAI-backed agents |
| ASP.NET Core / Microsoft.AspNetCore.OpenApi | 10.0 release line | Use current serviced 10.0 patch |
| Microsoft.Agents.AI.Hosting.OpenAI | 1.27.0-alpha.261030.1, prerelease | Not required; use normal Minimal API endpoints |
| Hosted tools, managed agents and other integrations | Provider/package-specific | Verify the exact integration before adopting |
The OpenAI hosting adapter remains prerelease at this check. That does not prevent hosting a stable provider-backed agent inside an ordinary ASP.NET Core application. This guide does not install the hosting adapter, workflow packages, a harness, or an MCP client.
Microsoft’s OpenAI provider documentation recommends the Responses client as the primary option, particularly for hosted tools. Chat Completions remains supported. We use it deliberately for local function tools and application-managed conversation history. Switching to Responses requires reviewing history ownership and feature behavior, not merely renaming a method.
Choose an active model in the OpenAI model catalog that supports Chat Completions, function calling and the output-token parameter used here. Set its ID in configuration. An empty default is intentional: model availability, account access, retirement dates and supported parameters change. No old model alias is silently assumed.
3. Microsoft Agent Framework versus Semantic Kernel and AutoGen
| Framework | Programming focus | Practical choice |
|---|---|---|
| Microsoft Agent Framework | Agent/session abstractions, tools and explicit workflows | New agent-focused .NET work after validating required integrations |
| Semantic Kernel | Kernel-centric AI integration, plugins and existing orchestration code | Maintain working integrations; migrate with tests and a concrete benefit |
| AutoGen | Conversational and event-driven multi-agent patterns | Evaluate existing systems and orchestration requirements before migration |
The Semantic Kernel migration guide maps kernel-dependent agents to Agent Framework’s agent creation and session APIs. The AutoGen migration guide explains conceptual mappings for Python; it is not a promise of drop-in C# source compatibility. Do not mix examples from the three SDKs in one project or assume every package in an older tutorial has the same lifecycle.
A useful migration plan records observable behavior first: which tool runs, what identity it receives, what state survives, and how approval resumes after failure. Replace one boundary at a time. A framework change alone does not establish security, lower latency or better answer quality.
4. Prerequisites, project creation and secure configuration
Install a current serviced .NET 10 SDK, an editor that supports it, and Postman or curl. You need a funded OpenAI API project with permission to use your selected model. A ChatGPT interface subscription should not be treated as proof of API access. Docker is optional. All sample data is in memory, so no database or vector store is required.
Create the project in a solution directory. In Visual Studio, choose ASP.NET Core Web API, target .NET 10, and use a project named SupportAgent.Api. The CLI path below uses the empty web template so there are no generated sample endpoints to remove.
Replace the project file with the following. The provider brings the matching OpenAI and Microsoft.Extensions.AI dependencies transitively. Avoid adding arbitrary older direct references. The OpenAPI patch wildcard is a setup convenience: after restore, record the resolved version and commit a dependency lock file for reproducible builds.
Create every application file below inside SupportAgent.Api. Keep the test project as a sibling directory. All application types use the namespace SupportAgent.Api. No repository abstraction is necessary for this deliberately small in-memory domain.
Keep secrets out of this file. Set development values with user secrets, replacing every placeholder yourself:
The two demo keys must be distinct, randomly generated and between 32 and 256 characters. They authenticate sample callers; they are not OpenAI keys. Never send the provider key in a Postman request to this API. Environment variable equivalents include AI__ApiKey, AI__Model, DemoAuth__AliceKey and DemoAuth__BobKey.
Microsoft’s secret storage guidance distinguishes development user secrets from production secret management. User secrets are not an encrypted production vault. Use a controlled secret store or deployment secret mechanism, restrict process access, and rotate credentials. Set AllowedHosts to the actual deployment host before production.
5. Request DTOs, sample products and order services
The HTTP contract accepts a session ID and message. It does not accept a customer ID. The authenticated principal determines ownership. Tool results expose only the fields needed to answer an order question; internal ownership information stays in the service.
The following service seeds Alice’s order A100 and Bob’s order B200. Both reference product KB-01. These are invented demonstration records, not customer data. The lock makes each sample state transition atomic within this process.
Preparing a cancellation records an expiring proposal; it does not change the order. Repeated preparation of the same pending action reuses its proposal. A decision checks the owner, expiry, current order version and status. A repeated decision returns the first recorded result during the proposal lifetime. After ten minutes, the client must request a fresh proposal.
A production database implementation needs an atomic transaction, an optimistic concurrency token, durable idempotency records and an audit trail. An in-process lock cannot coordinate multiple servers. Do not replace this lock with an unprotected read-then-write sequence when moving to SQL Server.
6. Demonstration authentication and authorization
This handler maps a secret demo key to a fixed user claim. Identity never comes from model output, an order ID or a request-body field. Hash comparisons use a fixed-time comparison, and the supplied key is never logged. This is a convenient local testing mechanism, not a complete production identity system.
For production, validate access tokens issued by a trusted identity provider, check issuer, audience, expiry and intended permissions, and bind ownership to stable tenant/user identifiers. Browser clients also need a considered session and CSRF design; do not embed these demo keys in public JavaScript. See the related ASP.NET Core 10 JWT authentication tutorial for the API authentication concepts.
7. Create the agent and expose custom C# function tools
The three tools are deliberately narrow. Product lookup reads a catalog. Order lookup filters by the owner bound when the agent is created. Cancellation preparation stages a proposal. There is no mutating cancellation tool available to the model.
The official function-tool documentation shows how AIFunctionFactory.Create creates callable tools and how description attributes explain parameters. The OpenAI AsAIAgent overload accepts ChatClientAgentOptions; ChatOptions carries instructions, tools and the output limit.
The OpenAI client can be shared, but each conversation receives its own agent with tools bound to its authenticated owner. The tool signatures do not contain an owner parameter that the model can override. If Bob asks for A100, the C# service returns the same generic not-found error as an unknown order.
Function calling is a loop, not a direct database connection from the model. The model emits a function name and arguments; application code executes the registered function and returns a result. The model can then answer or request another function. The OpenAI function-calling guide describes this exchange. Tool selection is probabilistic, so the API’s authoritative pending proposals are returned separately from the generated narrative.
For a simpler provider-only introduction, see integrating the OpenAI API in ASP.NET Core 10. Here, the additional responsibilities are tool execution, isolated state and permission boundaries.
8. AgentSession, conversation memory and concurrency
Create one AgentSession and reuse it for the turns in that conversation. Microsoft’s multi-turn guide demonstrates this API. Creating a fresh session for every chat request discards context; sharing one session across customers risks cross-user context exposure.
This store permits at most four active conversations per user and 100 per process, with a fixed 30-minute lifetime and 20 attempted turns. It rejects overlapping requests instead of silently interleaving message history. A failed or cancelled run marks the session unusable because history might already have advanced. Starting a new session is a conservative recovery policy, not a universal framework requirement.
The memory and persistence documentation explains that Chat Completions uses local chat history by default. This is short-term conversation context. It is not a vector database, a durable customer profile or a long-term RAG memory system. Session expiry limits the conversation lifetime, but the sample only removes expired entries when adding new sessions; production needs scheduled cleanup and retention controls.
For scale-out, use a supported persistence design, encrypt stored history, bind it to tenant and user, enforce retention/deletion, and coordinate concurrent writes across instances. Storing a live AgentSession object in a generic distributed-cache entry is not sufficient. Review serialization and provider-managed conversation state for your exact agent type.
9. Implement chat, streaming and authenticated approval endpoints
The endpoints use the authenticated owner, validate a maximum 2,000-character message, acquire the session gate and propagate cancellation. The 45-second linked cancellation budget covers model and tool processing. In-memory tools are synchronous because they do no I/O; real database or HTTP tools should use asynchronous APIs and propagate their cancellation token.
The normal endpoint returns text, available token counts and server-side pending approvals. Usage can be absent; null is not zero. The streaming endpoint emits newline-delimited JSON: delta records followed by done. It forwards text only, keeping internal tool traffic out of the public transport. It is not an OpenAI-compatible protocol or an SSE endpoint.
The running-agents documentation covers RunAsync and RunStreamingAsync. Once a streaming response has started, the server cannot change its HTTP status to 500. The code instead sends a safe error record when the client is still connected. Clients must require the final done record to consider the run successful; an HTTP 200 alone is insufficient.
Do not automatically replay an interrupted stream. The application may already have advanced the conversation or prepared a proposal. Cancellation is cooperative and is not a guarantee that a provider stopped processing or stopped billing immediately.
10. Register services, safe errors, OpenAPI and rate limits
Errors return safe ProblemDetails responses, not raw provider exception messages. The handler records the exception type, status and trace ID. It intentionally omits prompt text, authentication headers and exception details that may include confidential payloads. Add restricted diagnostic logging only after reviewing redaction and retention.
In .NET 10, handled exceptions can have middleware diagnostics suppressed. This handler writes its own safe event rather than assuming the middleware will log every handled failure. See Microsoft’s error-handling documentation and the related ASP.NET PB IExceptionHandler guide. Authentication failures, malformed requests and rate-limit rejections can follow their middleware’s own response shape; not every non-success response is produced by this handler.
Authentication runs before the user-partitioned limiter. The policy allows ten requests per minute per demo user with no queue, including session creation and approval calls. It is a per-process safeguard, not a distributed quota or complete DDoS defense. Microsoft’s rate-limiting guide explains policy configuration and ordering.
OpenAPI is available at /openapi/v1.json only in Development. This package does not automatically add a Swagger UI. Use Postman below, or add and configure a supported UI separately. The health endpoint verifies that the web process is running; it deliberately does not call the model or prove provider readiness.
11. Build locally and test the API with Postman
Execution disclosure: these are instructions for you to run. No build, unit test, live model call, Docker run or IIS deployment was performed while preparing this article. Exact generated text, token counts, IDs, timestamps and chunk boundaries will vary.
Run with the Development environment selected in your launch profile. Trust the development certificate instead of disabling certificate checks globally. In Postman create a private local environment with baseUrl=https://localhost:7043 and aliceKey equal to your configured Alice demo key. Set X-Demo-Key: {{aliceKey}} and Content-Type: application/json. Do not share an environment export containing secrets.
Create a conversation
Send POST {{baseUrl}}/api/sessions with no request body. The expected status is 200. Save the actual returned ID as sessionId. This creates local conversation state, not a persisted account profile.
Read an order through the agent
Send POST {{baseUrl}}/api/chat:
A tool-capable model should request order/product information and return an answer grounded in the sample data. The following shows the response shape, not a transcript. Null token values below mean no reported usage is being asserted:
Prepare cancellation, review it, then approve
Send another chat request with the same session and message Please prepare cancellation of order A100. The model may ask a clarifying question; inspect the response instead of assuming a proposal exists. When the tool runs, pendingApprovals contains a server-generated proposal ID, order ID and expiry. The order remains Processing.
After reviewing that action, copy the actual proposal ID into proposalId. Send POST {{baseUrl}}/api/approvals/{{proposalId}}/confirm using Alice’s key:
The comment lines above explain the two JSON documents; paste only the request object into Postman. Sending { "approved": false } records Rejected instead. A later true request for that same proposal returns the first decision. Ask the agent to re-read A100 after approval to observe the authoritative updated status; do not rely on a stale statement in its previous answer.
Test isolation and expected failure paths
| Test | Expected behavior |
|---|---|
| No valid X-Demo-Key | 401 before calling the model |
| Blank message or empty session ID | 400 |
| Alice session ID with Bob’s key | 404; no session access |
| Bob asks for A100 | Tool returns generic order-not-found data; chat itself can still be HTTP 200 |
| Bob confirms Alice’s proposal ID | 404 |
| Concurrent requests to one session | 409 for the overlapping request |
| Expired session / proposal | 410 while retained, or 404 after cleanup |
| Request exceeds the configured limiter | 429; wait for a new window |
| Run budget exceeded before headers start | 504 safe error; create a new session |
| Order changed before approval | 409; request a new proposal |
Also test prompt injection attempts, such as asking the agent to ignore ownership or cancel without approval. The expected invariant is unchanged server state unless the separate authorized approval request succeeds. Do not score security solely by whether the model says “I cannot do that.” Check the underlying service result.
Stream responses
Send the same chat JSON to POST /api/chat/stream. Inspect raw NDJSON as records arrive. A client should concatenate delta.text values, process the final pending approvals, and handle error or a missing done. Postman versions and proxies may buffer output; curl’s no-buffer option is useful:
Trust the localhost certificate for the client in use. A stream can produce several text chunks or none before a tool finishes. Tool processing time still contributes to perceived latency.
Unit-test deterministic business rules without a model
Create a separate test project from the solution directory. These tests exercise service behavior and do not need an OpenAI key. Replace the generated test file with the following:
The five tests cover cross-user reads, proposal-only behavior, unauthorized approval, duplicate confirmation and rejection finality. They were not run here. Add integration tests for HTTP authentication, limiter partitioning, session isolation, malformed JSON, cancellation and streaming failure. Use a fake model client for repeatable orchestration tests, and keep a separate opt-in live-model evaluation suite with a spending limit.
A useful evaluation set includes correct order lookup, another user’s order, nonexistent products, contradictory instructions, oversized inputs and repeated approval attempts. Record tool calls and final state, not just whether the generated sentence resembles an expected phrase. A model upgrade should rerun this set before rollout.
12. Human approval, prompt injection and tool permissions
This sample implements application-level approval: the model can create a proposal, but only a separate authenticated endpoint can mutate an order. It does not implement a suspended native approval-required tool run. A boolean sent to an API proves an authenticated request, not the physical presence of a human. A production UI must display the exact action, obtain deliberate consent, and use appropriate roles, step-up authentication and audit controls. Do not give the agent a generic HTTP tool with the caller’s approval credentials.
Agent Framework also supports native tool approval with ApprovalRequiredAIFunction. That approach pauses execution and resumes with the correlated approval response in the same session. If you adopt it, persist the pending request and decision, bind them to the correct identity, and test timeouts, rejection and replay. Do not deserialize a user-supplied message and treat it as proof that approval was previously recorded.
Prompt injection can arrive through a user message, a product description, retrieved text or another tool result. Instructions asking the model to ignore malicious content are useful guidance, but do not establish a security boundary. The application must still filter data by owner, validate arguments, restrict destinations and verify sensitive actions.
- Least privilege: expose only narrow tools. Avoid arbitrary SQL, shell commands, filesystem paths or unrestricted URLs.
- Server-side authorization: derive tenant and user identity from validated credentials. Apply ownership filtering inside every data-access tool.
- Data minimization: return necessary fields only. Never send API keys, full customer records or authentication tokens to the model.
- Safe rendering: treat generated text as untrusted. Encode HTML and sanitize any permitted markup in a future UI.
- Outbound controls: restrict network access and validate any URL before introducing a retrieval or HTTP tool.
- Approval integrity: expire proposals, revalidate order versions, record the decision and enforce idempotency in the same transaction as the mutation.
The demo’s proposal records expire and are not durable. They are not a compliance audit log. A restart resets orders and decisions; a real order system must preserve both independently of chat history.
13. Logging, observability, performance and model cost
The non-streaming endpoint logs a conversation ID, duration and available input/output usage. It avoids raw prompts and responses. Usage is provider-reported metadata and may be absent or vary with the integration. Reconcile application usage with provider billing and consider every model call in a tool loop, rather than assuming one HTTP request equals one generation.
The official observability documentation describes OpenTelemetry integration for agent and chat-client traces. The sample includes structured application logs, not a configured telemetry exporter. Add tracing in a separate operational change, keep sensitive-data collection disabled by default, and review attributes before exporting to a shared backend.
| Control in this example | What it limits | What it does not guarantee |
|---|---|---|
| 2,000-character messages | Incoming user text size | A fixed token count or total history size |
| 600 output tokens | Requested per-completion output | A hard total tool-loop spending ceiling |
| 45-second cancellation budget | Cooperative request processing time | Immediate provider cancellation or zero further charges |
| 20 turns and 30-minute expiry | Conversation lifetime | Semantic summarization or precise context-window management |
| 10 requests/minute/user/process | Local request admission | An organization-wide provider quota |
Before a public launch, add explicit tool-loop/iteration limits supported by the selected SDK, history reduction, per-user token/spend budgets, distributed quotas and provider-side project limits. Review how retries multiply total calls. Do not silently retry sensitive operations; use durable idempotency and a narrowly scoped retry policy where appropriate.
Measure end-to-end latency, model-call duration, tool duration, cancellation rate, tool failures and cost per successfully resolved request. Cache stable catalog data at the service boundary with an appropriate TTL, not a personalized answer under a shared key. Return concise tool results and avoid sending unrelated history. No benchmark or latency improvement is claimed here.
Separate conversation correctness from response speed. A shorter answer that used the wrong owner’s data is a failed request. A cached order status can become incorrect after cancellation. Choose cache invalidation, history retention and model settings based on business requirements, then measure with representative traffic.
14. Docker and IIS deployment considerations
Build from the SupportAgent.Api directory. The SDK stage compiles the application; the smaller ASP.NET runtime stage runs it as the built-in non-root app user. Use current serviced images and pin reviewed image digests in production. The Dockerfile contains no secrets.
Supply configuration through your deployment secret mechanism rather than Docker build arguments or an image layer. The container listens on HTTP 8080 for a trusted reverse proxy; terminate public HTTPS at that boundary. Configure ASP.NET Core forwarded headers for explicitly trusted proxies before HTTPS redirection, and set the real AllowedHosts value. Do not blindly trust forwarded headers from the public internet. Review Microsoft’s ASP.NET Core container guidance.
For IIS, publish with dotnet publish -c Release, install the current .NET 10 Hosting Bundle, configure the site and certificate, and grant the application identity only the required access. Preserve the generated web.config. Configure production secrets through an access-controlled mechanism. See Microsoft’s IIS hosting documentation and the related ASP.NET PB IIS deployment guide.
Test streaming through the real proxy: buffering, idle timeouts and disconnect propagation can differ from localhost. App-pool recycling, container restarts and scale-out all invalidate this sample’s in-memory sessions and decisions. Before running multiple instances, replace the stores with durable designs and distributed concurrency controls. A model-connected API also needs monitored outbound DNS/network access and graceful provider-outage behavior.
Production readiness checklist
- Replace demo keys with your identity provider and tenant-aware permissions.
- Persist orders, proposals, decisions and session state with explicit retention.
- Apply database concurrency checks and transactional idempotency.
- Set trusted proxy, HTTPS, host and request-size configuration.
- Establish spend limits, distributed admission controls and tool-loop bounds.
- Validate redacted telemetry, alerting and incident recovery.
- Run unit, integration, adversarial and live-model evaluations in staging.
- Verify dependency advisories and resolve/pin serviced package and image versions.
15. Troubleshooting common Agent Framework problems
| Symptom | Likely cause | What to check |
|---|---|---|
| AsAIAgent or AgentSession does not compile | Mixed package generations or stale examples | Inspect dotnet list package --include-transitive; align references and namespaces |
| Startup asks to configure AI:ApiKey or demo keys | Missing secrets, wrong environment or lost UserSecretsId | Run user-secrets init after saving the project file; inspect configuration privately |
| Provider says model not found or access denied | Wrong model ID, project permission or retired model | Check the current model catalog and account access; never log the key |
| Unsupported parameter or function calling | Selected model/client capability mismatch | Use a documented compatible model and review supported options |
| Agent invents an order status | Tool not selected or insufficient grounding | Inspect tool traces and evaluate instructions; business state remains authoritative |
| Agent forgets previous messages | New session each call, expiry or application restart | Reuse the returned session ID; implement persistence for deployment |
| 409 active request | Concurrent calls to the same session | Serialize client sends and wait for completion |
| Session cannot continue after a failure | Conservative broken-session policy | Create a new conversation; investigate before replaying |
| Cancellation is only proposed | Expected safety boundary | Review pendingApprovals and call the authenticated approval endpoint |
| 404 for another customer’s order | Ownership protection | Use the correct identity; do not weaken the service filter |
| Stream appears all at once | Client or reverse-proxy buffering | Inspect raw NDJSON and proxy settings; test no-buffer client behavior |
| 429 or intermittent failures | Local limiter or provider admission limits | Distinguish origin in restricted logs; reduce load and apply bounded backoff |
| Order state reverts on restart | In-memory demonstration store | Use a durable business database and approval log |
Community investigation surfaced recurring questions about session lifecycle and approval recovery. For example, GitHub issue #8575 reports a failed native approval-resume scenario. An issue report is not proof that every current version has that problem: check its current status and reproduce against your pinned dependency set. It does explain why failure/replay tests belong in an agent tutorial.
If the output is wrong, separate three questions: did the model choose the intended tool, did the tool receive the intended arguments, and did the service enforce the correct policy? Adding more prompt text only addresses part of the first question.
16. Frequently asked questions
Do I need Semantic Kernel to use Microsoft Agent Framework?
No. This implementation uses Microsoft.Agents.AI.OpenAI and its dependencies directly. Existing Semantic Kernel applications should follow the official migration guidance rather than mixing incompatible examples.
Can I use Azure OpenAI or another provider?
Yes, supported providers have their own integration setup. The authentication, tool and business-service boundaries can remain conceptually similar, but client construction, model identifiers, hosted tools and state behavior must be checked against that provider’s documentation. An OpenAI key is not an Azure deployment credential.
Is AgentSession permanent memory?
No. A session represents conversation state. This sample keeps it only in one process. Durable storage, retention and cross-session knowledge require explicit design; adding RAG is a separate feature.
Can the model cancel an order by itself?
No mutating cancellation function is registered. It can prepare a proposal. The actual change requires a separate authenticated approval request that rechecks business rules. A chat message saying yes does not invoke that endpoint.
Is a prompt injection defense enough to secure tools?
No. Restrict tool capabilities, enforce ownership in code, validate inputs and require appropriate approval for sensitive actions. Treat model output and retrieved text as untrusted input.
Why use Chat Completions when Responses is recommended?
This bounded example uses supported local tools and local conversation history. Responses is the documented primary choice for richer hosted-tool scenarios. Review state ownership and compatibility when choosing or migrating clients.
Does ASP.NET Core 10 include Swagger UI automatically?
No. The sample exposes a development OpenAPI document. The testing steps use Postman. A UI needs its own supported package and configuration.
Can I deploy this exact sample to several servers?
The code can be hosted, but its in-process order, approval, session and limiter state is unsuitable for coordinated multi-instance behavior. Replace those boundaries before scale-out.
Was this code compiled and tested?
No. It was documentation-reviewed, not executed in the authoring environment. Run the supplied build, deterministic tests and live-provider scenarios locally before treating it as a validated application. No API screenshot or benchmark is presented as evidence.
Does an AI agent automatically require a vector database?
No. This agent retrieves structured order data through C# services. A vector store becomes relevant when semantic retrieval over documents is part of the requirement. Do not add it merely because the application uses an LLM.
17. Conclusion: a useful agent needs enforceable boundaries
Building an ASP.NET Core 10 AI agent is more than returning a model’s text. The practical work is deciding which tools exist, how they receive identity, where conversation state lives, and which actions require a separate approval. Agent Framework supplies the agent/session and tool-invocation building blocks; your application still owns business correctness.
The next step is to run this example locally, verify cross-user isolation and approval behavior, and evaluate a compatible model against real support questions using non-sensitive data. Then replace the demonstration stores and authentication before production. Keep changes small enough that a failed model response cannot bypass an ordinary C# rule.
Useful follow-up articles for this topic cluster
- Persisting AgentSession history with tenant isolation and distributed concurrency.
- Designing durable, auditable agent approval workflows with transactional idempotency.
- Building an agent evaluation suite for tool authorization and prompt injection regressions.
These are proposed future topics only; no additional posts are created as part of this tutorial.
18. References and further reading
Official documentation and NuGet pages were checked on 4 November 2026. API reference pages can show a different documentation snapshot from the latest package; resolve your exact dependencies and build before adopting a changed example. Some provider documentation still includes prerelease installation commands. This guide pins the stable provider while explicitly excluding the alpha hosting adapter.
- Framework overview
- Official repository and release history
- Stable OpenAI provider package
- Prerelease OpenAI hosting adapter
- OpenAI provider/client choices
- Function tools
- AsAIAgent C# overloads
- ChatClientAgentOptions API
- AgentResponse API and usage
- Streaming update API
- Running agents
- Multi-turn conversations
- Memory and persistence
- Native human-in-the-loop tool approval
- Semantic Kernel migration
- AutoGen migration (Python)
- Observability
- OpenAI function-calling protocol
- Current OpenAI model catalog
- Development secret storage
- ASP.NET Core rate limiting
- ASP.NET Core exception handling
- ASP.NET Core containers
- ASP.NET Core IIS hosting
Research scope and useful search intent
The research reviewed Microsoft Learn, package listings, the official repository and issue reports, alongside community tutorial search results. Searches targeting Stack Overflow did not surface a directly useful current AgentSession question to cite. No community snippet was used as authority for the implementation. Existing tutorials covered getting started, state and tools; this guide adds an integrated order workflow with ownership enforcement, explicit approval and failure-aware streaming. That is an editorial focus, not a claim that other tutorials omit every one of these subjects.
Primary search intent is “Microsoft Agent Framework ASP.NET Core.” Related developer questions include “C# AI agent function calling,” “AgentSession conversation memory,” “ASP.NET Core AI agent streaming,” and “human approval for AI tools.” No reliable keyword-volume or competition dataset was available in this workflow, so no search-volume, CPC or ranking numbers are claimed. Direct answers, accurate terminology, official links and original diagrams are intended to help readers and answer engines understand the content; they cannot guarantee search visibility or AdSense revenue.
Comments
Post a Comment