title: "A Production Checklist for Semantic Kernel in .NET Apps"
date: 2026-05-27
readingTime: 3 min read
tags: ["Semantic Kernel", ".NET", "Azure OpenAI", "Production", "AI"]
Building a Semantic Kernel demo is straightforward. Building a production feature around it requires a different mindset.
The model is only one part of the system. The real production work is in permissions, logging, failure handling, evaluation, and user experience.
Here is the checklist I would use before shipping Semantic Kernel into a .NET business application.
Prompts should guide behavior. They should not become the source of payroll rules, accounting rules, stock valuation rules, or approval policy.
Business logic belongs in tested .NET services. Semantic Kernel should call those services through native plugins.
Each function should do one understandable thing.
Good:
get_customer_balance
get_overdue_invoices
draft_collection_email
Risky:
process_customer_account
handle_finance_task
run_erp_action
Narrow functions are easier to describe, authorize, test, and audit.
For support and compliance, log:
This is especially important when the assistant explains financial, payroll, or inventory data.
The assistant should know what to do when something fails.
Examples:
The UI should expose this clearly instead of pretending the assistant succeeded.
Do not evaluate only happy paths.
Use examples like:
These are the cases that break real systems.
For ERP systems, I would require approval before:
The assistant can draft, summarize, validate, and recommend. The user should commit.
Treat prompts and plugin descriptions as production assets.
When they change, track:
This makes AI behavior less mysterious when support tickets arrive.
Semantic Kernel works best in production when it is boringly engineered. Give it narrow tools, reuse existing services, log the important decisions, and keep humans in control of high-impact actions.
References: