AI Agents | The .NET Blog

Microsoft Agent Framework Parte 3: De Ferramentas a Workflows — As Peças se Encaixam

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Esta publicação foi traduzida automaticamente. Para a versão original, clique aqui.

Se você tem seguido a série Building Blocks for AI no .NET, sabe que a Parte 1 nos deu IChatClient (a interface universal de modelos) e a Parte 2 nos deu Microsoft.Extensions.VectorData (busca semântica e RAG). Ambos são fundamentais e úteis por si só. Mas é aqui que tudo começa a se conectar.

A Parte 3 é sobre o Microsoft Agent Framework — e honestamente, é a peça que eu estava esperando ver chegar no .NET. A versão 1.0 foi lançada em abril. A API é estável. É hora de construir agentes de verdade.

O que é um Agente (vs. um Chatbot)

Antes de mergulhar no código, vamos esclarecer essa distinção. Um chatbot recebe input, chama um modelo, retorna output. Loop simples.

Um agente tem autonomia. Ele pode raciocinar sobre uma tarefa, decidir quais ferramentas usar, chamá-las, avaliar resultados e decidir o que fazer a seguir — tudo sem que você escreva lógica passo a passo para cada cenário. Você dá a ele ferramentas e instruções, e ele cuida da orquestração.

Pense assim: IChatClient é como ter uma conversa. Um agente é como delegar uma lista de tarefas para alguém.

Seu Primeiro Agente em 10 Linhas

dotnet add package Microsoft.Agents.AI

AIAgent agent = new AzureOpenAIClient(
 new Uri(endpoint),
 new DefaultAzureCredential())
 .GetChatClient(deploymentName)
 .AsAIAgent(
 instructions: "You are good at telling jokes.",
 name: "Joker");

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate."));

O método de extensão .AsAIAgent() é a ponte. Mesmo padrão que .AsIChatClient() do MEAI — envolve o SDK do provedor em uma abstração estável. Funciona com Azure OpenAI, OpenAI, GitHub Models, Microsoft Foundry ou modelos locais.

Streaming também funciona:

await foreach (var update in agent.RunStreamingAsync("Tell me a joke about a pirate."))
{
 Console.Write(update);
}

Dando Ferramentas ao Agente

É aqui que os agentes param de ser chatbots sofisticados. Ferramentas são funções que o modelo pode decidir chamar com base no que o usuário pede. Sem lógica de roteamento da sua parte — o modelo descobre por si mesmo.

[Description("Get the weather for a given location.")]
static string GetWeather(
 [Description("The location to get the weather for.")] string location)
 => $"The weather in {location} is cloudy with a high of 15°C.";

AIAgent agent = chatClient.AsAIAgent(
 instructions: "You are a helpful assistant",
 tools: [AIFunctionFactory.Create(GetWeather)]);

Duas coisas a notar. Primeiro, AIFunctionFactory é do MEAI — a mesma factory de ferramentas que você usaria com um IChatClient normal. Se você já tem ferramentas definidas para cenários de chat, elas funcionam aqui também.

Segundo, os atributos Description importam muito. É como o modelo entende o que uma ferramenta faz e quando usá-la. Trate-os como documentação para sua IA, não para humanos.

Sessões: Conversas com Memória Real

AgentSession session = await agent.CreateSessionAsync();

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate.", session));

Console.WriteLine(await agent.RunAsync(
 "Now add some emojis and tell it in the voice of a pirate's parrot.",
 session));

Sem sessão, cada chamada a RunAsync é stateless. Com sessão, o agente sabe a qual piada você está se referindo. AgentSession preserva o histórico de conversa entre os turnos.

Para serviços sem estado em produção, as sessões serializam de forma limpa:

JsonElement sessionState = await agent.SerializeSessionAsync(session);
// ... armazene em algum lugar ...
var restoredSession = await agent.DeserializeSessionAsync(sessionState);
Console.WriteLine(await agent.RunAsync("What were we just talking about?", restoredSession));

Isso é crítico se seu agente roda em ambiente serverless ou com escalonamento horizontal.

AIContextProvider: Memória Persistente Entre Sessões

Sessões preservam o histórico dentro de uma sessão. Mas e sobre conhecer coisas sobre um usuário entre sessões? AIContextProvider cuida disso.

Tem dois hooks:

ProvideAIContextAsync — executa antes de cada interação, injeta contexto no agente
StoreAIContextAsync — executa depois de cada interação, permite aprender e persistir

O padrão é elegante: você pode empilhar múltiplos providers — um para preferências do usuário, um para interações recentes, um que consulta seu store VectorData para documentos relevantes. Este último é exatamente o padrão RAG da Parte 2, agora executando automaticamente a cada chamada do agente.

Workflows Multiagente

É aqui que o framework merece seu nome. Inclui um sistema de workflows baseado em grafos onde executors (agentes, funções, o que for) se conectam via arestas.

Alguns padrões suportados nativamente:

Sequencial: A saída do Agente A alimenta o Agente B
Concorrente (fan-out/fan-in): Despacha para múltiplos agentes em paralelo, coleta resultados
Roteamento condicional: Roteia trabalho para diferentes agentes com base na saída
Loops escritor-crítico: Um agente escreve, outro avalia, loop até aprovação
Sub-workflows: Compõe workflows hierarquicamente

Um exemplo de escritor-crítico:

WorkflowBuilder builder = new(writerAgent);
builder
 .AddEdge(writerAgent, criticAgent)
 .AddEdge(criticAgent, writerAgent, condition: result => !result.IsApproved)
 .WithOutputFrom(criticAgent, condition: result => result.IsApproved);
var workflow = builder.Build();

Limpo, legível, e o roteamento baseado em condições significa que você não escreve a lógica do loop você mesmo.

Human-in-the-Loop

Nem tudo deve rodar de forma completamente autônoma. Para operações sensíveis — escritas em banco de dados, transações financeiras, envio de comunicações — você quer que um humano aprove antes do agente executar.

O framework tem suporte integrado para isso via FunctionApprovalRequestContent e FunctionApprovalResponseContent. O agente propõe a chamada de ferramenta, seu código de aplicação a apresenta ao usuário, e a resposta determina se a execução prossegue.

Essa é a forma correta de pensar em agentes em ambientes corporativos: não completamente autônomos, mas autonomia com guardrails.

O Quadro Completo

Se você der um passo atrás:

MEAI te dá uma interface universal para qualquer modelo
VectorData dá aos seus agentes acesso ao conhecimento da sua organização através de busca semântica
Agent Framework orquestra tudo — usa IChatClient internamente, compõe com context providers, e coordena através de workflows

Cada peça foi projetada para se compor com as outras. Confira o post original de Jeremy Likness e o repositório GitHub do Agent Framework para os exemplos completos.

Conclusão

O post Parte 3 do Microsoft Agent Framework fecha o loop da série de building blocks. Para desenvolvedores .NET que querem construir agentes de IA — não apenas chatbots, mas agentes reais que usam ferramentas, lembram coisas e coordenam — este é o caminho.

O lançamento estável 1.0 significa que você pode construir isso em produção. Se você estava esperando para mergulhar no desenvolvimento de agentes em .NET, o momento é agora.

SQL MCP Server no Azure App Service — Sem Contêineres

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Esta publicação foi traduzida automaticamente. Para a versão original, clique aqui.

Vou ser honesto contigo: toda vez que vejo “requer um contêiner” em um tutorial, uma pequena parte de mim suspira. Contêineres são ótimos — até que a sua equipe não tem uma estratégia de contêineres, e de repente uma funcionalidade que parecia simples fica bloqueada por sobrecarga de orquestração que ninguém planejou.

Por isso esse aqui chamou minha atenção. O SQL MCP Server agora pode rodar no Azure App Service — sem Docker, sem Kubernetes, apenas com a mesma configuração do Data API Builder (DAB) que expõe seu banco de dados SQL via MCP, REST e GraphQL.

O que é o SQL MCP Server?

Contexto rápido se você ainda não o conhece. O SQL MCP Server fica entre o seu agente de IA e o seu banco de dados SQL. Em vez de dar ao agente acesso direto ao banco (o que seria uma péssima ideia), ele expõe suas tabelas e views como uma camada de abstração — entidades com permissões definidas.

É construído sobre o Data API Builder, o que significa que um único arquivo de configuração gerencia MCP e REST e GraphQL simultaneamente. Seu agente fala com o endpoint MCP. Sua aplicação tradicional fala com REST ou GraphQL. Mesma config, mesmo runtime, superfícies diferentes.

Isso é genuinamente útil. Você não mantém duas camadas de API separadas.

O Problema do Contêiner (e a Solução)

O modelo de deployment original do SQL MCP Server usava contêineres. Funciona bem em muitas equipes — mas não em todas. Muitas equipes .NET padronizam no Azure App Service ou VMs. Exigir um runtime de contêiner apenas para expor um endpoint SQL adiciona fricção que ninguém pediu.

O novo tutorial mostra como pular o contêiner completamente. Tudo funciona com um comando dab start, hospedado no App Service como um processo web .NET 8 padrão.

# Instalar Data API Builder
dotnet tool install microsoft.dataapibuilder --prerelease -g

# Inicializar a configuração
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# Adicionar uma entidade
dab add products --source dbo.products --permissions "authenticated:*"

# Configurar o provedor de auth do App Service
dab configure --runtime.host.authentication.provider AppService

# Iniciar o servidor
dab start

Neste ponto você tem MCP em /mcp, REST e GraphQL do mesmo processo, e nada rodando em contêiner.

Autenticação Sem Chaves de API Compartilhadas

Essa é a parte que mais aprecio. Ao fazer o deploy no App Service, você configura o Microsoft Entra ID como provedor de autenticação. Sem segredos compartilhados em arquivos de configuração, sem chaves de API para rotacionar.

A string de conexão fica em uma variável de ambiente do App Service (não no dab-config.json), e o endpoint MCP é protegido pela autenticação da plataforma. Se você já está alinhado com o Entra ID em suas cargas de trabalho Azure, isso se encaixa naturalmente.

Para desenvolvimento local, você muda para o modo Simulator e transporte STDIO. Volta para o modo AppService antes do deploy. Limpo e explícito.

Deploy no App Service

az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

Depois você faz o deploy do seu projeto DAB usando o método de deployment de código que sua equipe já usa. O detalhe importante: é um deployment de código, não de contêiner.

Por que Isso Importa para Desenvolvedores .NET

Se você está construindo agentes de IA em .NET, eventualmente seu agente precisará falar com um banco de dados. O SQL MCP Server te dá uma maneira estruturada de fazer isso sem expor strings de conexão brutas.

Confira o tutorial completo no post original e o repositório de exemplo no GitHub.

Conclusão

O SQL MCP Server no App Service é uma opção pragmática sólida para equipes .NET que querem dar aos seus agentes acesso estruturado a dados SQL sem uma estratégia de contêineres. Experimente — seus agentes vão apreciar a superfície de API limpa.

Atualizacao de abril do Visual Studio: integracao do Cloud Agent para fluxos .NET

Emiliano Montesdeoca — Mon, 04 May 2026 00:00:00 +0000

Este post foi traduzido automaticamente. Para a versao original, clique aqui.

Atualizacao de abril do Visual Studio: integracao do Cloud Agent para fluxos .NET e relevante para equipes que constroem e operam sistemas .NET em producao.

Na minha leitura, o ponto principal nao e apenas a novidade, e sim a velocidade para transformar isso em um padrao de engenharia repetivel.

Por que isso importa para times .NET

Esse tipo de atualizacao ajuda a equilibrar velocidade de entrega, consistencia de plataforma e governanca.

Proximos passos praticos

Valide a funcionalidade em um piloto .NET pequeno com dados parecidos com producao.
Defina observabilidade e plano de rollback antes de escalar.
Documente o padrao para reutilizacao entre equipes.

Fonte

Artigo original: https://devblogs.microsoft.com/visualstudio/visual-studio-april-update-cloud-agent-integration/

Governanca de chamadas de ferramentas MCP em .NET com Agent Governance Toolkit