Microsoft.Extensions.AI

Trigger On

• building or reviewing .NET code that uses Microsoft.Extensions.AI, Microsoft.Extensions.AI.Abstractions, IChatClient, IEmbeddingGenerator, ChatOptions, or AIFunction
• adding IImageGenerator, local-model chat via Ollama, AI app templates, or the .NET AI quickstarts for assistants and MCP
• choosing between low-level AI abstractions, provider SDKs, vector-search composition, evaluation libraries, and a fuller agent framework
• adding streaming chat, structured output, embeddings, tool calling, telemetry, caching, or DI-based AI middleware
• wiring Microsoft.Extensions.VectorData, Microsoft.Extensions.DataIngestion, MCP tooling, or evaluation packages around a provider-agnostic AI app

Workflow

1. Classify the request first: plain model access, tool calling, embeddings/vector search, evaluation, image generation, local-model prototyping, MCP bootstrap, or true agent orchestration.
2. Default to Microsoft.Extensions.AI for application and service code that needs provider-agnostic chat, embeddings, middleware, structured output, and testability.
3. Reference Microsoft.Extensions.AI.Abstractions directly only when authoring provider libraries or lower-level reusable integration packages.
4. Model IChatClient and IEmbeddingGenerator composition explicitly in DI. Keep options, caching, telemetry, logging, and tool invocation inspectable in the pipeline.
5. Treat chat state deliberately. For stateless providers, resend history. For stateful providers, propagate ConversationId rather than assuming all providers behave the same way.
6. Use Microsoft.Extensions.VectorData and Microsoft.Extensions.DataIngestion as adjacent building blocks for RAG instead of hand-rolling store abstractions prematurely. Model ingestion as an explicit reader -> processor -> chunker -> writer pipeline when the document-preparation path matters.
7. Treat the .NET AI quickstarts as bootstrap paths, not finished architecture. They now cover minimal assistants, MCP client/server flows, local models, app templates, and image generation. Start there for a vertical slice, then harden the DI, telemetry, and evaluation story here.
8. Escalate to dotnet-microsoft-agent-framework when the requirement becomes agent threads, multi-agent orchestration, higher-order workflows, durable execution, or remote agent hosting.
9. Validate with real providers, realistic prompts, and evaluation gates so the abstraction layer actually buys portability and reliability.

Deliver

• a justified package and abstraction choice: Abstractions only vs full Microsoft.Extensions.AI
• a concrete IChatClient / IEmbeddingGenerator composition strategy
• explicit tool-calling, options, state, caching, logging, and telemetry decisions
• vector-search, evaluation, or MCP integration guidance when the scenario needs it
• a clear escalation path to Agent Framework when the problem exceeds provider abstraction

Validate

• the abstraction layer solves a real portability, testability, or composition problem
• provider registration and middleware order stay explicit in DI
• chat state management matches whether the provider is stateless or stateful
• structured output, tool invocation, and embedding flows are typed and observable
• vector store, embedding model, and chunking strategy are consistent
• evaluation or safety gates exist for important prompts and agent-like behaviors
• agentic requirements are not being under-modeled as a simple IChatClient integration

When exact wording, edge-case API behavior, or less-common examples matter, check the local official docs snapshot before relying on summaries.

References

Related skills

Related agents