What Happens When Your AI Feature Fails?
A practical way to identify failure modes, choose explicit application behavior, and test an AI feature before its successful path hides the hard decisions.
Architecture
Designing an AI Service Layer
How to place model access, prompts, retrieval, tools, and application policy behind a maintainable use-case boundary in a .NET application.
Trust Boundaries Around AI Features
How to keep model proposals separate from trusted application behavior with authorization, approval policy, current-state checks, and least privilege.
Why Retrieval Exists
Why application knowledge does not belong in model weights, what retrieval contributes, and when a prompt, database query, or deterministic tool is simpler.
The Model Is Only One Dependency. Map the Rest.
How to map the execution, prerequisite, and operational dependencies around an AI feature and give each interaction a usable failure contract.
Stop Letting Provider SDKs Define Your .NET AI Architecture
How Microsoft.Extensions.AI keeps provider SDKs at the edge of .NET applications through shared abstractions, dependency injection, and middleware.
Calling a Model Is Easy. Running an AI System Is Not
Why a successful model call says little about whether an AI feature is reliable, secure, observable, affordable, and ready to operate in production.
Decide Without Your Default
A mental model for challenging familiar engineering choices before they become foregone conclusions.
Keep public API DTOs separate from domain entities
Use explicit request and response contracts so persistence fields and domain state do not become part of the public API accidentally.
Use Aspire service discovery instead of hardcoded ports
Let Aspire pass service discovery information so application code can use logical service names instead of local port numbers.