Construindo aplicações de IA com .NET
Construir aplicações de IA com .NET ficou mais simples porque a plataforma agora oferece blocos padronizados para chat, dados vetoriais, ferramentas externas e agentes. A sessão OD805 do Microsoft Build 2026, apresentada por Bruno Capuano, mostrou como esses blocos se encaixam em uma aplicação real.
Capuano atua no time de Dev Relations do GitHub e da Microsoft. Na apresentação, ele percorreu cada camada do ecossistema, partindo da abstração de chat até a comunicação entre agentes de frameworks diferentes.
Neste artigo, você acompanha a mesma progressão, com exemplos de código e as decisões de design que a sessão destacou.
O cenário da sessão OD805 sobre IA com .NET
A apresentação parte de uma aplicação chamada Zava, que funciona como um centro de suporte. Ela analisa incidentes, gera imagens, faz análises de dados e conversa com sistemas externos.
Por trás da interface, há vários serviços orquestrados com o .NET Aspire. Entre eles estão um agente do Microsoft Agent Framework e um agente do NVIDIA NeMo Toolkit, que conversam por protocolos abertos.
Dessa forma, a Zava serve como fio condutor para cada bloco de IA com .NET apresentado. Cada camada resolve um problema específico, e a soma delas forma a aplicação completa.
A fundação da IA com .NET: Microsoft.Extensions.AI
Todo projeto de IA com .NET começa pela biblioteca Microsoft.Extensions.AI. Ela define uma abstração de chat que não depende de nenhum provedor de modelos.
A interface central é a IChatClient. Com ela, o desenvolvedor conversa com qualquer modelo de linguagem de grande escala (LLM) sem amarrar o código ao SDK de um fornecedor.
Na prática, isso garante portabilidade. A mesma aplicação pode apontar para um modelo no Azure AI Foundry, para um modelo local no Ollama ou para outro provedor compatível, bastando trocar a implementação concreta.
Pacotes e responsabilidades
O pacote Microsoft.Extensions.AI.Abstractions traz os tipos centrais, como IChatClient e IEmbeddingGenerator<TInput, TEmbedding>. Provedores de modelos costumam depender apenas dele.
Já o pacote Microsoft.Extensions.AI referencia as abstrações e adiciona recursos prontos. Entre eles estão a invocação automática de ferramentas, a telemetria com OpenTelemetry e o cache, todos encaixados por injeção de dependência e middleware.
Segundo a documentação oficial do Microsoft.Extensions.AI, esses recursos formam um pipeline. Cada chamada Use envolve o cliente anterior, como acontece com os middlewares do ASP.NET Core.
Primeiro cliente de chat de IA com .NET
Na sessão, criar um cliente autenticado pelo Microsoft Entra ID exigiu apenas três passos. Primeiro, instancia-se o cliente do Azure; em seguida, obtém-se um IChatClient; por fim, envia-se a mensagem.
using Azure.AI.OpenAI;
using Azure.Identity;
using Microsoft.Extensions.AI;
// Autenticação integrada, sem chave de API no código
IChatClient chatClient =
new AzureOpenAIClient(new Uri("https://your-resource.openai.azure.com"), new DefaultAzureCredential())
.GetChatClient("gpt-5")
.AsIChatClient();
ChatResponse response = await chatClient.GetResponseAsync("Summarize the open incidents.");
Console.WriteLine(response.Text);
Com o Azure AI Foundry como backend, a Microsoft recomenda evitar chaves de API. Por isso, o exemplo usa DefaultAzureCredential, que aproveita a identidade gerenciada em produção e o az login durante o desenvolvimento local.
Modelos locais e streaming
Para modelos locais, o padrão de IA com .NET continua o mesmo e o código consumidor não muda. Ollama e Foundry Local seguem a mesma interface, então trocar entre Phi-4-mini, Llama ou Qwen é apenas uma questão de configuração.
Além disso, a IChatClient suporta streaming de tokens de forma nativa, pelo método GetStreamingResponseAsync. Assim, a interface exibe a resposta token a token, e o usuário não fica esperando o texto completo.
// Exibe a resposta conforme os tokens chegam
await foreach (ChatResponseUpdate update in chatClient.GetStreamingResponseAsync("Explain the incident timeline."))
{
Console.Write(update.Text);
}
Dados vetoriais e RAG na IA com .NET
Depois do chat, o próximo passo natural na IA com .NET é dar ao modelo acesso a dados externos. Afinal, os modelos não conhecem os dados privados da organização nem o que aconteceu depois da data de corte do treinamento.
O padrão RAG (Retrieval-Augmented Generation) resolve esse limite. Ele monta um pipeline que lê, fragmenta, enriquece e indexa documentos em um banco vetorial, permitindo buscas semânticas no momento da inferência.
Se você quer revisar o conceito antes de seguir, o artigo o que é RAG explica o padrão do zero.
Para essa finalidade, a IA com .NET conta com dois conjuntos de bibliotecas. O Microsoft.Extensions.VectorData cuida das abstrações de armazenamento e busca, enquanto o Microsoft.Extensions.DataIngestion cuida do pipeline de ingestão.
Microsoft.Extensions.VectorData
O Microsoft.Extensions.VectorData oferece uma camada unificada para diferentes bancos vetoriais. Com ela, o desenvolvedor faz operações de CRUD e buscas vetoriais ou híbridas usando a mesma API.
Entre as implementações disponíveis estão Azure AI Search, Cosmos DB (MongoDB vCore e NoSQL), Elasticsearch, Qdrant, SQL Server, SQLite e armazenamento em memória. Consequentemente, trocar de backend em um projeto de IA com .NET exige mudanças mínimas no código.
O artigo sobre dados vetoriais no .NET aprofunda o modelo de registros e as anotações usadas nas coleções.
Geração de embeddings
A geração de embeddings usa a interface IEmbeddingGenerator<TInput, TEmbedding>. Ela segue o mesmo princípio de abstração da IChatClient, então o provedor fica isolado do restante do código.
Além disso, na sessão, Capuano lembrou que modelos ONNX locais, com poucas dezenas de megabytes, servem bem para aprendizado e desenvolvimento. Por outro lado, modelos de nuvem como o text-embedding-3-small, da OpenAI, atendem melhor cenários multilíngues ou de produção.
O pipeline de ingestão de dados para IA com .NET
A biblioteca Microsoft.Extensions.DataIngestion materializa o fluxo ETL (Extract, Transform, Load) para cenários de IA. Em outras palavras, ela transforma documentos brutos em fragmentos prontos para a busca semântica da IA com .NET.
O pipeline combina quatro categorias de componentes encadeáveis:
- Readers, que carregam documentos de fontes como Markdown, PDF ou Word.
- Chunkers, que dividem os documentos por tokens, cabeçalhos ou similaridade semântica.
- Enrichers, que aplicam sumarização com LLMs, análise de sentimento e extração de palavras-chave.
- Writers, que gravam os fragmentos em um vector store e geram os embeddings automaticamente.
A composição acontece pela classe IngestionPipeline<T>, que encadeia os componentes. Além disso, ela trata falhas parciais, porque o método ProcessAsync retorna um IAsyncEnumerable<IngestionResult> com o resultado de cada documento.
// Encadeia leitor, fragmentador, enriquecedor e gravador
using IngestionPipeline<string> pipeline = new(reader, chunker, writer, loggerFactory: loggerFactory)
{
ChunkProcessors = { summaryEnricher }
};
await foreach (IngestionResult result in pipeline.ProcessAsync(new DirectoryInfo("docs"), searchPattern: "*.md"))
{
// Cada documento é tratado de forma independente
Console.WriteLine($"{result.DocumentId}: {result.Succeeded}");
}
Na demonstração, Capuano usou um leitor de Markdown, um fragmentador por similaridade semântica, um SummaryEnricher e um VectorStoreWriter ligado a um SQLite local. Esse mesmo desenho se adapta a ChromaDB, Azure AI Search ou qualquer outro vector store suportado.
Para um passo a passo completo desse fluxo, veja o artigo sobre ingestão de dados para aplicações .NET com RAG.
MCP: ferramentas externas na IA com .NET
O Model Context Protocol (MCP) é um protocolo aberto, criado pela Anthropic, que padroniza a forma como modelos interagem com ferramentas externas. Para quem ainda não conhece, o artigo o que é MCP apresenta o protocolo.
O ecossistema conta com um SDK oficial de MCP para C#, integrado ao Microsoft.Extensions.AI. Com ele, a aplicação consome servidores MCP públicos e também expõe os próprios servidores, com recursos, ferramentas e prompts.
O servidor MCP do Microsoft Learn
Na prática, a demonstração usou o servidor MCP do Microsoft Learn, hospedado em learn.microsoft.com/api/mcp. Ele dá acesso à documentação oficial publicada no Microsoft Learn.
Com isso, o contraste ficou claro na sessão. Sem o servidor, o modelo admitiu não conhecer a documentação mais recente; com o servidor, ele navegou pelos documentos e respondeu com a versão correta e o link da fonte.
Conectando o cliente MCP
No código de IA com .NET, a integração tem dois passos. Primeiro, você adiciona a invocação automática de funções ao pipeline do IChatClient; depois, cria um transporte HTTP que aponta para o servidor.
using ModelContextProtocol.Client;
// Habilita a chamada automática de ferramentas no pipeline
IChatClient client = chatClient.AsBuilder()
.UseFunctionInvocation()
.Build();
await using McpClient mcpClient = await McpClient.CreateAsync(
new HttpClientTransport(new HttpClientTransportOptions
{
Endpoint = new Uri("https://learn.microsoft.com/api/mcp"),
Name = "MicrosoftLearn"
}));
IList<McpClientTool> tools = await mcpClient.ListToolsAsync();
ChatResponse answer = await client.GetResponseAsync(
"What is the latest version of Microsoft.Extensions.AI?",
new ChatOptions { Tools = [.. tools] });
As ferramentas do servidor entram como opções de chat em cada chamada. Também é possível configurá-las globalmente no cliente.
Contudo, existe uma decisão de design importante aqui. Servidores com centenas ou milhares de ferramentas consomem uma parte relevante da janela de contexto, por isso o SDK permite filtrar e enviar apenas as ferramentas úteis em cada interação.
Agentes de IA com .NET no Microsoft Agent Framework
Com chat, dados vetoriais e ferramentas estabelecidos, o Microsoft Agent Framework (MAF) leva a IA com .NET adiante e acrescenta a camada que transforma um IChatClient em um agente completo.
A definição mínima de um agente pede três elementos: um nome, uma descrição e as instruções de comportamento, ou seja, o system prompt. Internamente, o agente envolve o IChatClient, mas ganha gerenciamento de estado da conversa, integração com MCP, chamadas de ferramentas e padrões de orquestração.
using Microsoft.Agents.AI;
// O agente envolve o IChatClient e recebe as ferramentas do MCP
AIAgent supportAgent = chatClient.AsAIAgent(
instructions: "You analyze support incidents and answer with official documentation.",
name: "SupportAgent",
tools: [.. tools]);
AgentResponse result = await supportAgent.RunAsync("Why does the deployment fail with error 403?");
Console.WriteLine(result.Text);
O MAF suporta vários provedores, como Azure AI Foundry, Azure OpenAI, OpenAI, Ollama e modelos locais pelo Foundry Local. Todos ficam acessíveis pela mesma abstração AIAgent, segundo a visão geral do Microsoft Agent Framework.
Com as ferramentas MCP, o padrão se repete. Você cria o cliente MCP, lista as ferramentas e as entrega ao agente na criação ou em cada chamada; então, o agente decide sozinho quando usá-las.
Para depuração e observabilidade, o framework traz um DevUI. Ele mostra em tempo real o fluxo de execução, com chamadas de ferramentas, traces e resultados intermediários, o que acelera o ajuste de prompts.
Se quiser um panorama do framework antes de avançar, o artigo sobre o Microsoft Agent Framework cobre os conceitos principais.
Workflows e orquestração multiagente
Quando um problema de IA com .NET exige vários agentes especializados, o MAF oferece workflows baseados em grafos. Eles orquestram a colaboração entre os agentes com regras explícitas.
Os padrões de orquestração disponíveis são quatro:
- Sequencial, em que os agentes processam a tarefa em cadeia e passam o resultado adiante.
- Concorrente, em que vários agentes trabalham em paralelo em aspectos diferentes.
- Handoff, em que a responsabilidade passa de um agente para outro conforme uma condição.
- Group chat, em que os agentes colaboram em uma conversa compartilhada.
Por exemplo, um workflow sequencial entre um agente escritor e um agente revisor usa AgentWorkflowBuilder.BuildSequential(). O método recebe a lista de agentes e devolve um workflow executável como um único agente.
// O workflow resultante também é um agente
AIAgent writerAgent = chatClient.AsAIAgent("You write incident reports.", "Writer");
AIAgent reviewerAgent = chatClient.AsAIAgent("You review reports for clarity.", "Reviewer");
AIAgent reportWorkflow = AgentWorkflowBuilder
.BuildSequential(writerAgent, reviewerAgent)
.AsAIAgent();
Console.WriteLine(await reportWorkflow.RunAsync("Write the report for incident 4521."));
Como o workflow é ele mesmo um agente, a composição pode ser recursiva. Assim, padrões complexos viram componentes reutilizáveis de workflows ainda maiores.
Para cenários que pedem durabilidade e checkpoints, o MAF se integra ao SDK do Durable Task. Nesse caso, uma falha em qualquer etapa é recuperada sem executar de novo as etapas já concluídas.
O artigo sobre como orquestrar agentes com workflows detalha cada padrão com mais exemplos.
A2A: interoperabilidade de agentes na IA com .NET
O protocolo A2A (Agent-to-Agent) nasceu no Google e depois passou para a Linux Foundation. Hoje ele é um padrão aberto para a comunicação entre agentes de frameworks diferentes.
Na Zava, um agente do MAF e um agente do NVIDIA NeMo Toolkit conversam via A2A. Cada agente publica um agent card em um endereço /.well-known/, descrevendo capacidades, entradas, saídas e mecanismos de autenticação.
Além disso, o Azure AI Foundry suporta o A2A de forma nativa. Um agente externo entra em um projeto do Foundry como "Custom Scenario" apenas com a URL do seu agent card.
O ecossistema traz bibliotecas tanto para implementar servidores A2A quanto para consumir agentes de terceiros. Portanto, as mesmas estratégias de autenticação do restante da stack de IA com .NET continuam valendo.
A comparação entre os protocolos aparece no artigo MCP ou A2A: qual escolher, útil para decidir onde cada um se encaixa.
Geração de imagens como ferramenta de agente
Outro caso demonstrado na sessão foi a geração de imagens como ferramenta de um agente. Esse exemplo mostra que, na IA com .NET, qualquer capacidade pode virar uma ferramenta.
A integração usa a biblioteca de geração de imagens a partir de texto do .NET AI. Ela abstrai o acesso a modelos como o GPT-Image-2, disponível no Azure AI Foundry.
A função de geração entra no agente como uma ferramenta comum, igual a qualquer outra registrada no MAF. Quando o usuário pede uma imagem, o agente decide chamar a ferramenta, passa a descrição como parâmetro e devolve a imagem na resposta.
Como os blocos de IA com .NET se encaixam
Por fim, vale olhar o conjunto de cima. Cada camada depende da anterior e acrescenta uma única responsabilidade.
| Camada | Biblioteca ou protocolo | Responsabilidade |
|---|---|---|
| Chat | Microsoft.Extensions.AI | Conversar com qualquer modelo |
| Dados | Microsoft.Extensions.VectorData | Armazenar e buscar vetores |
| Ingestão | Microsoft.Extensions.DataIngestion | Preparar documentos para RAG |
| Ferramentas | SDK de MCP para C# | Conectar sistemas externos |
| Agentes | Microsoft Agent Framework | Estado, ferramentas e orquestração |
| Interoperabilidade | A2A | Conversar com agentes de outros frameworks |
Dessa forma, você pode adotar a IA com .NET aos poucos. Uma aplicação simples para no IChatClient, enquanto um sistema multiagente usa todas as camadas.
Conclusão
A sessão OD805 do Microsoft Build 2026 mostrou uma visão coerente e progressiva da IA com .NET. O caminho vai das abstrações de chat e embeddings até a orquestração de agentes heterogêneos por protocolos abertos como MCP e A2A.
Capuano reforçou ao longo da apresentação a ausência de caixas pretas. Cada componente, do IChatClient aos workflows do MAF, é uma biblioteca .NET que qualquer desenvolvedor pode inspecionar, testar e estender.
Para começar, a sessão recomendou dois pontos de entrada. O primeiro é o repositório de amostras "Generative AI for Beginners .NET", no GitHub; o segundo é a documentação "AI apps for .NET developers", no Microsoft Learn.
FAQ
O que é o Microsoft.Extensions.AI?
É uma biblioteca de abstrações agnósticas ao provedor para chat, embeddings e outros recursos de IA generativa no .NET. Com ela, o mesmo código funciona com provedores diferentes sem mudar a lógica de negócio.
Dá para usar modelos locais com o mesmo código da nuvem?
Sim. Ollama e Foundry Local implementam as mesmas interfaces IChatClient e IEmbeddingGenerator, então a troca acontece apenas na configuração do cliente.
O que diferencia um agente do MAF de um IChatClient?
O agente envolve o IChatClient e adiciona estado de conversa, integração com ferramentas e MCP e padrões de orquestração. Para um chat simples sem estado, o IChatClient direto pode bastar.
Como o MCP se integra ao MAF?
O SDK de MCP para C# se integra ao Microsoft.Extensions.AI. As ferramentas do servidor são listadas e entregues ao agente, que decide quando chamá-las.
O protocolo A2A é exclusivo da Microsoft?
Não. O A2A é um protocolo aberto mantido pela Linux Foundation, e a sessão mostrou um agente do MAF conversando com um agente do NVIDIA NeMo Toolkit.
Quais bancos vetoriais o Microsoft.Extensions.VectorData suporta?
Entre outros, Azure AI Search, Cosmos DB, Elasticsearch, Qdrant, SQL Server, SQLite, Couchbase e armazenamento em memória. A comunidade também pode criar novos provedores seguindo as abstrações.
Como evitar que as ferramentas MCP lotem a janela de contexto?
Filtre as ferramentas enviadas em cada chamada e mande apenas as relevantes. Uma estratégia comum é fazer uma pré-seleção semântica antes de montar a requisição.