O novo .NET AI Stack
O .NET AI Stack é a resposta da plataforma .NET a um cenário em que novos modelos, interfaces e padrões arquiteturais de IA surgem em ciclos cada vez mais curtos. Neste artigo, você conhece os blocos que formam esse stack, entende o papel de cada um e descobre um caminho seguro para adotá-los em projetos reais.
O contexto do .NET AI Stack
Hoje, o desenvolvimento de aplicações com inteligência artificial vive uma aceleração constante, porque cada mês traz modelos novos. Por isso, manter um projeto estável e sustentável ao longo do tempo ficou bem mais difícil.
Nesse cenário, a plataforma .NET passa por uma evolução estratégica. Em vez de focar apenas em integrações pontuais com provedores de LLM, o ecossistema se organiza em torno de blocos fundamentais, abstrações estáveis e observabilidade integrada.
Além disso, o .NET AI Stack traz uma visão clara de como construir agentes e workflows de forma idiomática em C#. O vídeo abaixo apresenta essa visão em detalhes.
Por que um AI stack precisa ser estável
Uma das maiores dificuldades em plataformas de IA é que a inovação anda mais rápido que a padronização. Por exemplo, em poucos meses surgem:
- novos modelos com capacidades multimodais, por exemplo;
- mudanças no suporte a chamadas de ferramentas;
- melhorias em respostas estruturadas;
- formatos diferentes de streaming e de tokens de resposta;
- variações em protocolos de integração, como o MCP;
- novas abordagens de agentes e orquestração.
A consequência direta é a fragilidade do código que depende de APIs em mudança constante. Portanto, o objetivo do .NET AI Stack é reduzir esse problema com uma premissa simples: a plataforma oferece primitivas estáveis, e o desenvolvedor só desce para integrações específicas quando precisa.
A proposta não é esconder os SDKs nativos dos provedores. Na verdade, o stack fornece uma base consistente para:
- começar rápido, inclusive em protótipos;
- trocar de provedor com menos atrito;
- aplicar observabilidade e governança;
- suportar aplicações com várias modalidades;
- escalar para cenários com agentes e workflows.
Microsoft.Extensions.AI no .NET AI Stack
O ponto central do .NET AI Stack é o conjunto de bibliotecas Microsoft.Extensions.AI, frequentemente chamado de MEAI. A ideia lembra o que a plataforma já fez com os pacotes Microsoft.Extensions.*: oferecer contratos comuns para reduzir o acoplamento entre a aplicação e as bibliotecas concretas.
No contexto de IA, então, isso significa uma camada com APIs universais para conversar com modelos. Segundo a documentação do Microsoft.Extensions.AI, o pacote Microsoft.Extensions.AI.Abstractions traz os tipos centrais, como IChatClient e IEmbeddingGenerator.
Já o pacote Microsoft.Extensions.AI adiciona utilitários de alto nível, como invocação automática de ferramentas, telemetria e cache. Assim, a maioria das aplicações referencia esse pacote junto com uma implementação concreta, como OllamaSharp ou o cliente da OpenAI.
O exemplo abaixo mostra como a abstração simplifica uma chamada a um modelo local:
using Microsoft.Extensions.AI;
using OllamaSharp;
// O cliente do Ollama implementa a interface IChatClient
IChatClient client = new OllamaApiClient(
new Uri("http://localhost:11434/"), "phi3:mini");
Console.WriteLine(await client.GetResponseAsync("What is AI?"));
Como o código depende apenas de IChatClient, trocar o Ollama por outro provedor exige mudar só a criação do cliente. Para uma visão introdutória do tema, o artigo IA generativa no .NET e C# traz um bom resumo.
O objetivo das abstrações
O MEAI é deliberadamente limitado ao que pode ser tratado como primitivo. Isso significa aceitar que não é possível padronizar tudo e que sempre existirão recursos exclusivos de um provedor.
Em alguns cenários, portanto, usar o SDK nativo continua necessário. Ainda assim, para os fluxos principais, a plataforma oferece um caminho padronizado sem sacrificar a flexibilidade.
Modalidades como princípio de design
Além disso, uma das áreas mais importantes do .NET AI Stack é o foco em modalidades, ou seja, as formas de entrada e saída que os modelos modernos aceitam. Na prática, isso inclui:
- entrada de texto, imagens, áudio e voz;
- saída textual ou formatada em Markdown;
- variações de streaming e segmentação da resposta.
O desafio arquitetural é manter a API consistente mesmo quando a capacidade do modelo evolui. Por isso, o IChatClient já envia e recebe mensagens com conteúdo multimodal, de forma completa ou em streaming.
Com isso, o desenvolvedor pensa menos em qual provedor está usando e mais em qual interação o modelo suporta.
Integrações e interoperabilidade
Na prática, um benefício do MEAI é o reaproveitamento de padrões entre bibliotecas externas. Quando uma biblioteca de terceiros implementa as interfaces do MEAI, o desenvolvedor mantém o mesmo estilo de código para:
- criar clientes;
- configurar o modelo;
- enviar prompts;
- instrumentar chamadas;
- executar requisições.
Esse ponto pesa, pois o ecossistema de IA tende a se fragmentar rapidamente. Por exemplo, um modelo pode estar no Azure, outro no GitHub Models e outro rodando localmente via Ollama.
Mesmo assim, a experiência de desenvolvimento precisa continuar coesa. De fato, a documentação recomenda que autores de bibliotecas implementem as abstrações e que consumidores programem contra elas, em vez de fixar um serviço específico.
Microsoft Agent Framework no .NET AI Stack
Se o MEAI representa os blocos fundamentais, o Microsoft Agent Framework representa o próximo degrau de abstração do .NET AI Stack. Seu foco é dar base sólida para aplicações que saem do chat simples e evoluem para cenários com:
- agentes especializados e coordenação entre eles;
- workflows sequenciais e concorrentes;
- execução com memória e ferramentas;
- integração com ambientes gerenciados.
A própria documentação do framework resume a escolha: use um agente quando a tarefa é aberta ou conversacional, e use um workflow quando o processo tem etapas bem definidas. Além disso, ela lembra que, se uma função comum resolve a tarefa, não vale a pena usar um agente.
Para um panorama completo do framework, consulte a visão geral do Microsoft Agent Framework.
Por que agentes exigem mais do que um chat client
Uma aplicação com um único chat tende a ser simples: recebe o prompt e responde com texto. Ao introduzir agentes, porém, o sistema passa a operar com separação de responsabilidades e orquestração.
É comum que uma solução moderna use papéis bem definidos, como:
- pesquisador, um agente que localiza e valida informações;
- escritor, um agente que gera o conteúdo final;
- coordenador, um agente que decide quem executa cada tarefa.
Essa arquitetura melhora a clareza e a modularidade. Por outro lado, ela aumenta a complexidade do desenvolvimento, dos testes e da instrumentação.
Dois modelos comuns de orquestração
Em geral, a apresentação descreve duas estratégias típicas. Na coordenação por agente controlador, um agente principal chama os demais por meio de ferramentas, e a lógica de decisão fica centralizada nele.
Já na orquestração por workflow, um pipeline explícito define a sequência ou a concorrência das etapas. Assim, o fluxo fica mais determinístico e previsível.
Em ambos os casos, o desafio é permitir que o desenvolvedor itere rápido, depure o comportamento e evolua o sistema com segurança. O artigo sobre como orquestrar agentes com workflows mostra a segunda abordagem na prática.
Dev UI no .NET AI Stack
Em cenários de agentes e workflows, a iteração rápida vira requisito. Por isso, a apresentação anunciou a Dev UI, uma ferramenta para inspecionar, testar e depurar agentes e workflows durante o desenvolvimento.
A proposta é simples: a aplicação expõe os agentes e workflows registrados, e o desenvolvedor interage com eles por um endpoint, tipicamente em uma rota como /devui. Hoje, a documentação do Agent Framework descreve a DevUI como um aplicativo de exemplo com interface web e um backend compatível com a API da OpenAI.
Na prática, a Dev UI permite:
- escolher qual agente ou workflow executar;
- enviar entradas controladas;
- visualizar a sequência de execução;
- inspecionar eventos, decisões e traces;
- iterar sem depender da interface final da aplicação.
Com isso, esse modelo reduz o custo de feedback e evita que cada ajuste exija uma UI própria ou a leitura de logs extensos. Além disso, a ferramenta também acompanha agentes conectados a ambientes gerenciados, inclusive via Aspire.
Cuidados de segurança com a Dev UI
Como se trata de uma ferramenta de desenvolvimento, exponha a Dev UI apenas em ambientes controlados. A própria documentação reforça que ela não serve para produção, já que um console desse tipo representa risco operacional.
Observabilidade no .NET AI Stack com Aspire
Da mesma forma, outro eixo importante do .NET AI Stack é a observabilidade. O .NET Aspire fornece instrumentação integrada para acompanhar o ciclo de vida das chamadas de IA, incluindo:
- perguntas enviadas;
- chamadas de ferramentas;
- respostas geradas;
- rastreamento de dependências;
- latência e tempo de execução.
Ao combinar o Aspire com middleware de instrumentação, você rastreia fluxos de agentes e modelos de forma consistente. Consequentemente, o diagnóstico fica mais simples e depende menos de logs manuais.
No MEAI, essa instrumentação entra como mais uma camada do pipeline do IChatClient. O exemplo abaixo, baseado na documentação oficial, combina telemetria e invocação automática de ferramentas:
using Microsoft.Extensions.AI;
using OllamaSharp;
IChatClient ollamaClient = new OllamaApiClient(
new Uri("http://localhost:11434/"), "llama3.1");
// Cada Use* adiciona um middleware ao pipeline do cliente
IChatClient client = new ChatClientBuilder(ollamaClient)
.UseFunctionInvocation()
.UseOpenTelemetry(sourceName: "MyApp.AI")
.Build();
Em aplicações com tool calling e agentes de vários passos, essa visibilidade se torna essencial. Para aprofundar o tema, leia o artigo sobre observabilidade de agentes e workflows.
Execução local com Ollama e Foundry Local
O desenvolvimento com IA na nuvem envolve custos de computação e consumo de tokens. Por isso, iterar localmente faz diferença tanto no custo quanto na velocidade.
A apresentação cita duas opções de execução local. O Ollama roda modelos locais com praticidade, enquanto o Foundry Local aparece como alternativa da Microsoft para o mesmo fim.
Assim, a ideia central é permitir que o desenvolvedor:
- teste prompts e agentes localmente;
- faça ciclos rápidos de ajuste;
- reduza custos na fase de experimentação;
- migre para provedores na nuvem quando precisar.
Esse padrão segue as práticas modernas: prototipar localmente e promover a solução aos poucos para ambientes com mais capacidade. Como o MEAI abstrai o provedor, essa migração exige pouca mudança no código.
Respostas estruturadas e middleware
O .NET AI Stack também destaca aspectos que nem sempre recebem atenção, como respostas estruturadas, middleware para controle de contexto e utilitários de integração. A intenção é aproximar a experiência do padrão clássico do .NET: composição por extensões e pipelines.
Respostas estruturadas, também chamadas de typed outputs, são cruciais quando:
- o modelo precisa devolver dados processáveis, e não só texto;
- existe validação obrigatória de schema;
- decisões automáticas dependem de campos confiáveis.
No MEAI, o método genérico GetResponseAsync<T> pede ao modelo uma resposta no formato de um tipo .NET:
// Tipo que o modelo deve preencher
public record SupportTicket(string Title, string Category, int Priority);
// Retorna a resposta já convertida para o tipo informado
var response = await client.GetResponseAsync<SupportTicket>(
"Classify this message: my invoice shows a duplicated charge.");
Console.WriteLine(response.Result.Category);
Dessa forma, o restante da aplicação trabalha com objetos tipados em vez de interpretar texto livre.
RAG e ingestão de dados no .NET AI Stack
Além de chat e agentes, uma classe inteira de aplicações depende de RAG, sigla para Retrieval-Augmented Generation. Se o conceito é novo para você, o artigo o que é RAG explica a base.
A apresentação menciona uma frente focada em ingestão e recuperação semântica, chamada Microsoft Extensions for Data Ingestion, ou MEDI. Segundo a documentação do Microsoft.Extensions.DataIngestion, a biblioteca simplifica:
- a leitura de documentos de fontes locais e na nuvem;
- o chunking por cabeçalhos, seções ou semântica;
- o enriquecimento com resumos, palavras-chave e classificação;
- a geração de embeddings;
- o armazenamento em vector stores.
A biblioteca se apoia em três componentes estáveis do ecossistema, que são Microsoft.ML.Tokenizers, Microsoft.Extensions.AI e Microsoft.Extensions.VectorData. Assim, o pipeline de ingestão reaproveita as mesmas abstrações usadas no chat.
Esse tema acompanha a demanda de sistemas corporativos que precisam responder com base em dados proprietários, reduzindo alucinações e aumentando a rastreabilidade. Para ver a ingestão em ação, consulte o artigo sobre ingestão de dados para aplicações .NET com RAG.
Além disso, a busca vetorial em bancos tradicionais, como SQL Server e PostgreSQL, indica uma convergência importante. Em outras palavras, o stack de IA deixa de ser um ecossistema paralelo e passa a integrar a infraestrutura existente.
Templates como ponto de entrada
A apresentação também reforça o papel dos templates como ponto de partida para aprendizado e adoção. O template AI Chat Web App, por exemplo, permite:
- escolher o provedor de IA, como Azure OpenAI, GitHub Models ou Ollama;
- escolher o mecanismo de embeddings e o vector store;
- experimentar a instrumentação e a integração com Aspire;
- estudar código de referência com boas práticas.
Para instalar e criar um projeto pela CLI, a documentação usa os comandos abaixo:
# Instala o pacote de templates de IA
dotnet new install Microsoft.Extensions.AI.Templates
# Cria um app de chat com Ollama e vector store local
dotnet new aichatweb --provider ollama --vector-store local
Na prática, o projeto gerado é um app Blazor que já registra um IChatClient, um IEmbeddingGenerator e um vector store para prototipação. Portanto, em um ecossistema que muda rápido, o template funciona tanto como starter kit quanto como recurso educacional.
Por onde começar com o .NET AI Stack
Uma estratégia segura para adotar o .NET AI Stack segue um caminho progressivo:
- Comece pelo MEAI, usando as abstrações básicas.
- Evolua para o Agent Framework quando houver necessidade de agentes e workflows.
- Use a Dev UI para ciclos rápidos de teste e depuração.
- Adote Aspire e OpenTelemetry para ter observabilidade desde o início.
- Itere localmente com Ollama ou Foundry Local antes de escalar para a nuvem.
- Incorpore RAG com ingestão e vector stores quando o domínio exigir.
Esse caminho reduz o lock-in prematuro e permite um crescimento natural da aplicação. Além disso, cada etapa reaproveita as abstrações da anterior, então nada precisa ser reescrito do zero.
Conclusão
O .NET AI Stack é uma resposta pragmática à complexidade real do desenvolvimento com IA. Ao consolidar os fundamentos no Microsoft.Extensions.AI, o ecossistema oferece uma evolução natural para agentes com o Microsoft Agent Framework.
Além disso, junto com ferramentas como Aspire e Dev UI, a plataforma entrega uma experiência mais estável e escalável. O resultado não tenta competir com cada SDK específico, mas permite criar aplicações robustas, instrumentadas e sustentáveis.
Em um cenário onde o que era novo há dois meses já pode estar desatualizado, a prioridade deixa de ser perseguir tendências. Por fim, o foco do .NET AI Stack passa a ser construir sobre fundamentos sólidos, com espaço para adaptação.
O vídeo abaixo serviu de fonte para este conteúdo.
FAQ
O que é o Microsoft.Extensions.AI?
É um conjunto de bibliotecas com abstrações comuns, como IChatClient e IEmbeddingGenerator, para integrar serviços de IA no .NET sem acoplar o código a um provedor.
Preciso do Agent Framework para usar IA no .NET?
Não. Para chats e chamadas simples, o MEAI basta, e o Agent Framework entra quando a aplicação precisa de agentes, memória ou workflows.
A Dev UI pode ir para produção?
Não. A documentação descreve a Dev UI como ferramenta de exemplo para desenvolvimento e recomenda expô-la apenas em ambientes controlados.
Dá para desenvolver sem pagar por tokens na nuvem?
Sim. Com Ollama ou Foundry Local, você roda modelos localmente durante a experimentação e migra para a nuvem depois.
O que é o MEDI?
É a biblioteca Microsoft.Extensions.DataIngestion, que lê, divide, enriquece e armazena documentos para cenários de RAG.