Azure | The .NET Blog

Microsoft Foundry Abril 2026: Foundry Local GA, GPT-5.5, CodeAct com Hyperlight

Emiliano Montesdeoca — Tue, 02 Jun 2026 00:00:00 +0000

Um mês movimentado para o Microsoft Foundry. Estes são os anúncios mais importantes.

Foundry Local está Geralmente Disponível

Foundry Local — o runtime de IA local multiplataforma da Microsoft — passa de preview para GA no Windows, macOS (Apple Silicon) e Linux x64. Inferência de modelos locais pronta para produção com um SDK amigável para desenvolvedores. A versão 1.1 adiciona suporte a transcrição, embeddings e API Responses.

GPT-5.5

O mais recente modelo da família GPT-5 está agora disponível no Foundry. Cota padrão para assinaturas Tier 5 e Tier 6. Se você trabalhou com variantes anteriores do GPT-5, vale a pena avaliar para seus casos de uso.

Rastreamento do Agent Framework no Foundry

Dois recursos de rastreamento são lançados em preview este mês:

Rastreamento do Microsoft Agent Framework — Os agentes MAF agora podem emitir rastreamentos OpenTelemetry no Foundry. Depure o comportamento dos agentes, rastreie a execução em múltiplas etapas, exponha latência e erros nas chamadas de ferramentas. Isso preenche uma lacuna real: saber o que seu agente realmente fez na produção, não apenas o que retornou.

Rastreamento de agentes hospedados — Sessões, chamadas de ferramentas e etapas de execução de agentes hospedados também aparecem nos rastreamentos do Foundry. A mesma história de observabilidade estendida ao nível hospedado.

CodeAct com Hyperlight (Alpha)

Esta é a adição tecnicamente mais interessante: Agent Framework agora pode executar código Python dentro de micro-máquinas virtuais Hyperlight.

CodeAct é o padrão onde um agente gera e executa código Python como ferramenta. A preocupação óbvia é a segurança — você está executando código gerado pelo modelo. As micro-VMs do Hyperlight fornecem isolamento em nível de processo com tempo de inicialização próximo ao nativo, tornando a execução de código em sandbox prática sem a sobrecarga de contêineres ou VMs completos.

Para fluxos de trabalho agênticos onde a execução de código é necessária, isso é uma melhoria significativa de segurança em relação à execução de código no processo host.

Painel de Monitoramento de Agentes (Preview)

Um painel de operações unificado combinando uso de tokens, latência, taxa de sucesso de execução e pontuações de avaliadores em uma única visualização. A distinção dos painéis de observabilidade regulares: inclui resultados de avaliação junto com métricas operacionais, para que você possa correlacionar “o agente está mais lento” com “as pontuações do avaliador caíram” — ou confirmar que não estão relacionados.

Avaliadores Personalizados de Avaliação Contínua (Preview)

Agora você pode trazer seus próprios avaliadores baseados em código ou prompt para pipelines de avaliação contínua. Anteriormente, a avaliação contínua estava limitada a avaliadores integrados. Os avaliadores personalizados permitem que você aplique critérios de qualidade específicos da equipe em seu loop de monitoramento de produção.

Inventário de Agentes no Plano de Controle

A visualização Operate do Plano de Controle do Foundry agora mostra todos os agentes suportados em uma assinatura: agentes Foundry, Azure SRE Agent, loops de agentes do Logic Apps e agentes personalizados registrados. Uma visualização para entender o que está implantado e onde.

Postagem original: What’s new in Microsoft Foundry | April 2026

Seu Agente MAF Local Acabou de Ganhar um Lar em Produção

Emiliano Montesdeoca — Sat, 30 May 2026 00:00:00 +0000

Fazer um agente funcionar localmente é a parte divertida. A parte complicada é tudo que vem depois: implantá-lo sem enlouquecer, gerenciar sessões, configurar identidade, conectar observabilidade. Normalmente isso significa muita infraestrutura personalizada.

O Foundry Hosted Agents acabou de remover a maior parte dessa infraestrutura para usuários do Microsoft Agent Framework (MAF).

O Que o Foundry Hosted Agents Realmente Faz

Quando você implanta um agente MAF no Foundry Hosted Agents, a plataforma lida com uma lista surpreendentemente longa de coisas que você teria que construir por conta própria:

Escalar para zero — seu agente não custa nada quando ocioso e volta automaticamente
Sandboxes isolados por VM por sessão — cada sessão de usuário tem seu próprio sandbox com persistência do sistema de arquivos que sobrevive a eventos de redução de escala
Entra ID integrado — cada agente tem sua própria identidade para chamar modelos Foundry, Toolbox e serviços Azure sem segredos na imagem
Implantações versionadas — cada implantação é um snapshot imutável, com suporte a blue/green e canary rollout
Observabilidade sem configuração — APPLICATIONINSIGHTS_CONNECTION_STRING é injetado em tempo de execução para que os traces OpenTelemetry do MAF fluam automaticamente para o App Insights

Esse último é genuinamente agradável. Sem fiação extra, sem configuração adicional. Os traces simplesmente aparecem.

A Diferença no Código É Mínima

Isso é o que mais aprecio nessa integração. Você não reescreve seu agente. Você simplesmente o envolve:

Em .NET:

using Microsoft.Agents.AI.Foundry.Hosting;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddFoundryResponses(agent);

var app = builder.Build();
app.MapFoundryResponses();

app.Run();

Em Python:

server = ResponsesHostServer(agent)
server.run()

É isso. A mesma lógica que você testou localmente é o que roda em produção. A plataforma a envolve na infraestrutura de gerenciamento de sessões, identidade e escalamento.

Dois Protocolos, Um Agente

Os Hosted Agents suportam dois estilos de endpoints:

Responses (/responses) — compatível com OpenAI, gerencia histórico de conversas e streaming. Bom padrão para agentes em forma de chat.
Invocations (/invocations) — você define o esquema de requisição/resposta. Bom para workflows não conversacionais.

Se você está construindo algo que parece uma conversa, comece com Responses. Se está construindo um agente em forma de API que recebe entrada estruturada e retorna saída estruturada, Invocations te dá a flexibilidade.

O Fluxo de Implantação com `azd`

Quando você executa azd up com um agente MAF:

Opcionalmente cria um projeto Foundry e implanta um modelo
Empacota seu código e envia uma imagem para o Azure Container Registry
Provisiona compute a partir da imagem ACR
Atribui um Entra ID dedicado ao agente
Expõe um endpoint estável (https://{project_endpoint}/agents/{agent_name})
Lida com tudo mais a partir desse ponto

As sessões persistem por até 30 dias. O compute ocioso é desprovisionado após 15 minutos e restaurado transparentemente na próxima requisição. Da perspectiva do agente, nada mudou.

Conclusão

A distância entre “funcionando localmente” e “rodando em produção” tem sido historicamente longa e dolorosa para agentes de IA. Foundry Hosted Agents + MAF fecha essa lacuna significativamente. Se você já tem um agente local construído com Agent Framework, vale a pena tentar hoje.

A equipe diz que o GA está chegando em breve — atualmente está em preview. Confira os docs de integração MAF Hosted Agent e os exemplos .NET para começar.

Artigo original: From Local to Production: Deploy Your Microsoft Agent Framework Agent with Foundry Hosted Agents

Foundry Local 1.1: Transcrição em Tempo Real, Embeddings e a API de Respostas

Emiliano Montesdeoca — Thu, 28 May 2026 00:00:00 +0000

Foundry Local 1.0 provou o conceito: executar modelos de IA localmente no Windows, macOS (Apple Silicon) e Linux x64 com um SDK amigável para desenvolvedores. A versão 1.1 adiciona três capacidades que cobrem muitos casos de uso reais em produção.

Transcrição de Áudio em Directo

A nova funcionalidade mais significativa: streaming de voz para texto em tempo real diretamente do microfone. Legendas, interfaces de voz, transcrição de reuniões, ferramentas de acessibilidade — tudo a correr localmente sem qualquer dependência da cloud.

A API é baseada em sessões e transmite resultados à medida que chegam, com marcadores is_final para distinguir texto intermédio do finalizado. Disponível para todos os bindings de linguagem: JavaScript, C#, Python e Rust.

Carrega um modelo de voz em streaming do catálogo, cria uma sessão com definições de áudio (frequência de amostragem, canais, idioma), inicia-a, envia blocos de áudio PCM em bruto e consome o stream assíncrono de resultados. O post tem exemplos completos em Python e C#.

Embeddings de Texto

Pesquisa semântica, pipelines RAG, clustering, correspondência de similaridade — tudo isto requer embeddings. Foundry Local 1.1 adiciona suporte para modelos de embedding para que possas gerar vetores localmente a partir do mesmo SDK, sem enviar dados para um endpoint na cloud.

Para aplicações onde a residência de dados é importante ou onde processas conteúdo sensível, a geração local de embeddings é uma capacidade significativa.

API de Respostas

O Foundry Local suporta agora a API de Respostas — a interface estruturada concebida para interações agênticas. Isto adiciona:

Chamada de ferramentas — permite que modelos a correr localmente invoquem ferramentas que defines
Entrada multimodal visão-linguagem — passa imagem + texto a modelos com capacidade de visão
Compatível com a forma padrão de API, pelo que agentes existentes que apontam para a API de Respostas da OpenAI funcionam contra modelos locais

Melhorias no Tamanho do Pacote

Duas alterações reduzem o tamanho do pacote JavaScript:

A camada FFI koffi foi substituída por um addon C Node-API personalizado
O fornecedor de execução WebGPU é distribuído como plugin separado, pelo que as aplicações que não precisam de aceleração GPU não pagam o custo de tamanho

O SDK C# agora aponta para versões de framework inferiores para compatibilidade .NET mais ampla.

Por Que Importa

As três capacidades juntas — transcrição, embeddings, chamada de ferramentas — cobrem os blocos de construção fundamentais de muitas aplicações de IA. Executá-los localmente significa:

Sem internet necessária
Sem custos por token
Sem dados a sair da máquina
Latência consistente independentemente das condições de rede

Foundry Local é a escolha certa para cenários de edge, cargas de trabalho sensíveis à privacidade, aplicações offline, ou qualquer coisa onde se queira evitar a dependência da cloud durante o desenvolvimento.

Post original: Foundry Local 1.1: Live Transcription, Embeddings, and Responses API

Cosmos DB Shell Está em Pré-visualização Pública — E Tem um Servidor MCP Integrado

Emiliano Montesdeoca — Sun, 24 May 2026 00:00:00 +0000

Se você já teve que alternar entre uma guia do portal, um exemplo de SDK e um script pela metade apenas para responder uma pergunta sobre Cosmos DB, já conhece a fricção que este projeto foi projetado para eliminar.

Azure Cosmos DB Shell acabou de entrar em pré-visualização pública. É uma CLI de código aberto com sintaxe semelhante ao bash e — a parte que o torna interessante — um servidor MCP integrado.

O Que o Torna Diferente de Outras CLIs de Banco de Dados

A CLI em si é útil: comandos familiares, suporte a scripts, integração CI/CD. Essa parte é o mínimo esperado para uma ferramenta de banco de dados voltada para desenvolvedores.

A parte interessante é a integração do servidor MCP. Cada comando que a CLI expõe fica disponível como uma ferramenta MCP que seus agentes de IA podem chamar. Não há camada de API personalizada, nenhum código de integração para escrever. Seu agente pode:

Navegar por hierarquias de banco de dados com cd, ls, pwd
Executar consultas SQL com query e obter resultados estruturados
Criar e modificar itens com create item, update, rm
Gerenciar bancos de dados e containers com mkdb, mkcon, rmdb, rmcon
Inspecionar o contexto atual com endpoint, pwd

A mudança chave: seu agente não está falando com uma API do Cosmos DB — está falando com a mesma interface de shell que você usa. Os comandos são determinísticos, auditáveis e de código aberto para que você possa inspecionar exatamente o que está acontecendo.

A Base de Código Aberto Importa

Isso não é um serviço gerenciado de caixa preta. O shell é de código aberto, o que significa:

Equipes de segurança podem auditar a implementação
Equipes de plataforma podem fazer fork e estendê-lo para seus padrões específicos
Desenvolvedores podem contribuir com melhorias que beneficiam todos

Para equipes empresariais adotando ferramentas de IA, “podemos ver exatamente como funciona” é cada vez menos um requisito opcional. O código aberto aqui é um diferencial significativo.

Três Cenários Que se Tornam Mais Fáceis

Análise inteligente de dados — conecte um agente ao shell, faça perguntas em linguagem natural, obtenha resultados de consultas estruturados. O agente cuida da construção da consulta; o shell cuida da execução.

Gerenciamento autônomo de dados — fluxos de trabalho que precisam criar, atualizar ou remover dados no Cosmos DB podem fazer isso através das ferramentas MCP sem precisar de uma integração personalizada.

Monitoramento e alertas em tempo real — um agente pode consultar containers periodicamente, comparar resultados e apresentar anomalias através do canal de notificação que fizer sentido.

A interface MCP torna esses cenários combináveis com qualquer plataforma de IA que fale MCP — não apenas as ferramentas da Microsoft.

Para Começar

O shell está em pré-visualização pública. Instale-o, configure sua conexão com o Cosmos DB e habilite o servidor MCP. A partir daí, qualquer host de agente compatível com MCP pode descobrir e usar as ferramentas.

Post original: Announcing the Public Preview of Azure Cosmos DB Shell: Open-Source Power Meets AI-Driven Database Automation

O Seu Agente de IA Tem um Problema de Identidade (E Aqui Está o Template que o Resolve)

Emiliano Montesdeoca — Wed, 20 May 2026 00:00:00 +0000

Há um momento em cada projeto de agente de IA que vai mais ou menos assim: a demo funciona perfeitamente, o agente interpreta a linguagem natural, chama as APIs certas, retorna os dados certos. Então você começa a pensar nos usuários reais.

O que impede a sessão do agente de um usuário de ver os dados de outro usuário? E se o agente for enganado por injeção de prompt? E se ele chamar uma ferramenta de uma forma inesperada?

Estes não são casos extremos. São decisões de design que você precisa tomar antes de lançar.

Um novo template azd da Curity e Microsoft fornece uma referência funcional para exatamente este problema.

O Problema Central: Autenticação ≠ Autorização

A maioria dos exemplos de agentes trata bem a autenticação de usuários. Trata mal a autorização. Saber quem é o usuário não te diz quais dados ele deveria ver.

Uma aplicação cliente tradicional faz chamadas de API previsíveis. Um agente de IA é não-determinístico — interpreta a linguagem natural e decide o que chamar. Pode ser criativo. Também pode estar errado. E se for manipulado por injeção de prompt, você precisa de regras que não dependam do bom comportamento da IA.

A solução que este template demonstra: tokens de curta duração que carregam exatamente as informações certas para cada salto.

Como Funciona a Cadeia de Tokens

O template usa tokens de acesso OAuth 2.0 com troca de tokens para restringir permissões a cada passo. Um token de usuário é trocado duas vezes antes de chegar ao servidor MCP:

Primeira troca — restringe o escopo e converte o token opaco em JWT
Segunda troca — adiciona a identidade do agente e um novo audience para o salto do servidor MCP

Como é o token do servidor MCP:

{
 "scope": "stocks/read",
 "sub": "62c839b8...",
 "aud": "https://mcp.demo.example",
 "customer_id": "178",
 "region": "USA"
}

O customer_id está incorporado no token pelo servidor de autorização, não passado como um parâmetro que o agente controla. A API verifica o token, não as instruções do agente.

Isso significa: mesmo que alguém engane o agente para tentar buscar os dados de outro cliente, o token não autorizará.

O que o Template Implanta

Com alguns comandos azd você obtém:

Um agente backend no Microsoft Foundry (C#, SDKs Microsoft A2A e MCP)
Um servidor MCP que expõe uma API de portfólio de exemplo
Curity Identity Server como servidor de autorização, junto com Entra ID para autenticação
Gateways de API externos e internos que gerenciam a troca de tokens e o registro de auditoria
Bicep para toda a infraestrutura Azure: Container Apps, VNet, ACR, Azure AI Foundry, Key Vault, Azure SQL Database, armazenamento

Todo o padrão é inspecionável e personalizável.

O Princípio de Design que Vale a Pena Adotar

Mesmo se você não usar Curity, o padrão é transferível: agentes nunca deveriam ter acesso permanente à API. Cada ação deveria usar um token de curta duração com o escopo mínimo necessário para aquela chamada específica, emitido para a identidade específica do agente, carregando as claims de que a API precisa para tomar decisões de autorização.

Isso resiste a agentes criativos, erros e injeção de prompt de maneiras que “apenas certifique-se de que o agente não faça coisas ruins” nunca resistirá.

Conclusão

Os padrões de segurança para agentes de IA ainda estão sendo desenvolvidos em toda a indústria. Este template é uma das implementações de referência mais completas que vi — cobre o fluxo de autorização real, não apenas a autenticação.

Post original: Least privilege AI agents: A new azd template from Curity and Microsoft

Endpoints Privados, VNets, NSGs — Aspire Gerencia a Rede Agora

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

Já vi esse cenário muitas vezes. A aplicação está pronta. A demonstração é ótima. Então aparece a lista de verificação de segurança: tire o armazenamento da internet pública, execute dentro de uma VNet, forneça IPs de saída para a lista de permissões do parceiro, prove que apenas as sub-redes corretas falam com os serviços corretos.

Nesse ponto o modelo de aplicação e o modelo de infraestrutura começam a divergir de maneiras que são dolorosas de manter.

O novo suporte de rede empresarial do Azure para Aspire aborda isso diretamente. Você descreve a forma da rede ao lado dos recursos que a usam, no seu AppHost.

Os Blocos de Construção

Aqui está para que serve cada conceito de rede do Azure, destilado:

Recurso	Use quando	Por que é importante
Rede virtual	Você precisa de um espaço de endereçamento privado	O limite de rede para sub-redes, endpoints privados e roteamento
Sub-rede	Você precisa separar cargas de trabalho dentro da VNet	Cada parte do sistema obtém seu próprio intervalo de endereços e superfície de política
Sub-rede delegada	Um serviço de plataforma (como ACA) precisa gerenciar uma sub-rede	Permite que o serviço coloque infraestrutura gerenciada em sua VNet com segurança
Gateway NAT	Você precisa de IPs públicos de saída previsíveis	Endereço estável para listas de permissões e auditoria
Endpoint privado	Você quer um recurso PaaS acessível privatamente	Coloca um IP privado para esse serviço dentro da sua VNet, remove a exposição pública
NSG	Você precisa de regras de tráfego no nível da sub-rede	Permitir/negar explícito para tráfego de entrada e saída por sub-rede

Descrevendo no seu AppHost

A mudança chave aqui é que você está modelando a rede junto com os recursos que a usam, não em um arquivo Bicep separado que se afasta do modelo de aplicação com o tempo.

Do AppHost, você pode:

Criar VNets e sub-redes com AddVirtualNetwork() e AddSubnet()
Anexar um gateway NAT às sub-redes para IPs de saída estáveis
Criar endpoints privados para armazenamento, Key Vault, SQL e outros serviços PaaS
Definir NSGs com regras de segurança de entrada e saída
Configurar Perímetros de Segurança de Rede para políticas entre recursos

O resultado é que quando você executa azd up, a infraestrutura corresponde ao que o modelo de aplicação diz que precisa. Não o que diz um template mantido manualmente.

Por Que Isso Importa para Aplicações Reais

Algumas coisas que se tornam significativamente mais fáceis quando a rede é modelada no Aspire:

Endpoints privados para Key Vault e armazenamento — você descreve WithPrivateEndpoint() nesses recursos, e o Aspire lida com a configuração da zona DNS e o anexo de endpoints. A aplicação nunca muda.

IPs de saída consistentes — adicione um gateway NAT à sub-rede relevante e cada solicitação de saída da sua aplicação passa por um IP conhecido e estável. Os parceiros podem incluí-lo na lista de permissões. Os auditores podem rastreá-lo.

Regras NSG do código — em vez de clicar no portal ou manter um trecho Bicep, suas regras de segurança vivem no AppHost ao lado dos recursos que protegem.

Este é o tipo de integração que não torna as demonstrações emocionantes, mas torna os sistemas de produção manuteníveis.

Conclusão

A segurança de rede aparecendo tarde no ciclo de vida do projeto é um problema resolvido se você a modelar junto com a aplicação desde o início. O suporte de rede empresarial do Aspire torna isso possível sem exigir um rastreamento de infraestrutura separado.

Detalhes completos na publicação original: Securing Azure apps with Aspire enterprise networking

Aspire 13.3: Suporte ao Kubernetes, Logs do Navegador e a Skill Aspireify

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

Cinco semanas não é muito tempo para um lançamento, mas o Aspire 13.3 não parece assim. Os itens principais são significativos: implantação de Kubernetes e AKS de primeira classe com Helm, uma skill de integração assistida por agente chamada Aspireify, captura de logs do navegador diretamente no dashboard e resultados de comandos estruturados. Além disso, 45 novos recursos, 134 melhorias e 93 correções de bugs.

Vamos aos destaques.

Aspireify: Integração Assistida por Agente

Adicionar o Aspire a um projeto existente parece simples — coloque um AppHost, pronto. Na prática, envolve muita arqueologia: quais portas importam, quais variáveis de ambiente são dependências reais, quais serviços do Docker Compose devem ser mapeados para integrações do Aspire.

A nova skill Aspireify fornece ao seu agente de código um fluxo de trabalho guiado exatamente para isso. Quando aspire init cria um AppHost esqueleto, a skill Aspireify ajuda o agente a inspecionar o repositório, entender como já funciona e conectar o AppHost para se adaptar ao aplicativo — não o contrário.

A postura padrão é “minimizar alterações no seu código.” Se o seu aplicativo já lê DATABASE_URL, o agente mapeia isso com WithEnvironment() em vez de pedir que você reescreva sua configuração. Se uma porta está codificada de forma fixa, a skill indica ao agente quando preservá-la.

Este é o tipo de tooling de IA que realmente economiza tempo em vez de gerar mais trabalho para revisar.

Implantação de Kubernetes e AKS de Primeira Classe

Esta estava na lista de desejos há algum tempo. O Aspire 13.3 inclui suporte de implantação de Kubernetes e AKS de primeira classe com Helm. Agora você pode direcionar o AKS como destino de implantação diretamente das ferramentas do Aspire.

Para equipes que já executam cargas de trabalho de produção no AKS, isso fecha uma lacuna significativa. Seu modelo de aplicativo Aspire agora tem um caminho limpo do desenvolvimento local ao Kubernetes sem a necessidade de escrever manualmente charts Helm.

Logs do Navegador no Dashboard

Esta é uma daquelas funcionalidades que parecem pequenas até você estar depurando um problema de frontend.

A nova API WithBrowserLogs() anexa um recurso de navegador rastreado a qualquer recurso capaz de endpoints. O Aspire lança o Chromium usando um pipe CDP privado e transmite logs do console, solicitações de rede e erros diretamente no fluxo de logs do recurso:

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

O AppHost TypeScript suporta o mesmo:

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

Erros de console, solicitações de rede com falha, exceções do lado do cliente — tudo visível no mesmo dashboard onde você já está observando traces e métricas. Sem necessidade de trocar de aba para o DevTools do navegador para as coisas básicas.

Resultados de Comandos Estruturados

Os comandos de recursos receberam uma atualização significativa. Até agora, os comandos retornavam sucesso/falha. Agora eles retornam resultados estruturados: texto, JSON ou markdown que flui pelo modelo, pela interface do dashboard, pela CLI e pelas ferramentas MCP.

O dashboard une tudo isso com um novo centro de notificações no cabeçalho. Os resultados dos comandos aparecem como notificações com carimbo de data/hora com renderização de markdown e uma ação “Ver resposta”.

Isso torna os comandos de recursos verdadeiramente combináveis. Uma integração agora pode expor um comando que retorna uma saída significativa — como uma URL de túnel — em vez de simplesmente alterar o estado em algum lugar.

Conclusão

O Aspire 13.3 vale a atualização mesmo que seja apenas pelo suporte ao Kubernetes. Os logs do navegador e os resultados de comandos estruturados parecem o tipo de melhorias de qualidade de vida que se acumulam rapidamente em um fluxo de trabalho de desenvolvimento diário.

Notas de versão completas: What’s New in Aspire 13.3

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 acontece de 11 a 15 de maio de 2026 no Barbican Centre em Londres. A conferência principal de 3 dias vai de terça a quinta, com workshops opcionais de dia inteiro na segunda e na sexta.

Com 78 sessões e 14 workshops, é uma das conferências mais completas para desenvolvedores na Europa.

Tópicos

Pensamento Arquitetural
Código Funcional em C# 13
Design Serverless
IA Semântica
Azure Kubernetes Services
Estratégias Lean DevOps
The Model Context Protocol (MCP)
IA Agêntica em .NET
Refatorando o Monolito
Programar Mais Rápido com LLMs
Criptografia em um Mundo Pós-Quântico
Desenvolvimento Local First

Palestrantes

Elenco de classe mundial incluindo Kevlin Henney, Neal Ford, Sander Hoogendoorn, Andrew Clymer, Jacqui Read, Christian Weyer, Jeff Prosise, Jules May, Oliver Sturm e Raju Gandhi.

Ingressos e informações

98% dos participantes do SDD 2025 avaliaram a experiência geral como boa, muito boa ou excelente.

Removendo o Trabalho Repetitivo de Migração com Agentic Platform Engineering

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

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

Removing the Monkey Work of Migration with Agentic Platform Engineering — um passo a passo do Git-Ape (ferramenta git de engenharia de plataformas agêntica) migrando um repositório Terraform real da AWS para o Azure, com foco na extração de intenção em vez de conversão linha por linha.

A entrada: contoso-migration

A fonte é um projeto Terraform real (contoso-migration) que implanta um aplicativo Next.js na AWS — EC2 para computação, ALB para balanceamento de carga, S3 para artefatos e chaves IAM para identidade. Custo: ~$34/mês. O objetivo não é reproduzir a mesma infraestrutura no Azure; é descobrir o que o deployment está realmente tentando fazer e reconstruí-lo com serviços nativos do Azure.

Passo 1: Validação e autenticação

O Git-Ape começa validando todas as ferramentas CLI necessárias — az, aws, gh, jq, git — e confirmando as sessões de autenticação ativas antes de tocar em qualquer coisa. Sem execuções parciais.

Passo 2: Extração de intenção

O agente lê todo o repositório fonte pela API do GitHub e extrai a intenção do deployment: runtime (Node.js), tipo de computação, padrão de ingress, tratamento de artefatos, modelo de identidade, rede e monitoramento. Este é o passo-chave — está construindo um modelo semântico do que o deployment faz, não quais palavras-chave do Terraform ele usa.

Passo 3: Mapeamento de serviços

Os serviços AWS são mapeados para equivalentes do Azure:

EC2 → App Service (Linux, Node 20 LTS)
ALB → Balanceamento de carga integrado do App Service
Funções/chaves IAM → Managed Identity
Terraform → Bicep + GitHub Actions

Passo 4: Agente crítico

Antes de gerar a saída, um agente crítico é executado e detecta dois problemas bloqueantes:

Anti-padrão de build no startup — o Terraform original estava executando npm install && npm run build no EC2 na inicialização. Solução: construir no CI, implantar um artefato pronto.
Blob Storage desnecessário — o S3 era usado para staging de artefatos que poderia ser eliminado com CI/CD adequado. O agente crítico o removeu completamente.

Passo 5: Saída gerada

O resultado são ~80 linhas de Bicep em vez das 200+ linhas originais de Terraform. O agente criou um novo repositório GitHub com infra/main.bicep e .github/workflows/deploy.yml e removeu todos os arquivos específicos da AWS.

Comparação de postura de segurança

A migração também produziu uma melhoria significativa de segurança:

AWS original	Saída Azure
Somente HTTP	Somente HTTPS, TLS 1.2
SSH aberto para 0.0.0.0/0	Sem exposição SSH
Chaves de acesso IAM	OIDC + Managed Identity
Sem monitoramento	Application Insights

Custo: ~$13/mês vs os $34/mês originais.

O que o diferencia de um conversor de sintaxe

O passo do agente crítico é o que separa isso de uma tradução mecânica. Ele detectou padrões que teriam funcionado na AWS mas seriam incorretos no Azure — e os corrigiu em vez de replicá-los. A saída não é “AWS em sintaxe Azure”; é um deployment nativo do Azure que atinge o mesmo objetivo de forma mais limpa.

Veja o guia completo para o rastreamento completo do agente e arquivos gerados.

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.

SQL Server 2025 como Banco de Dados Pronto para Agentes: Segurança, Backup e MCP em Um Motor

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

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

Acompanhei a série Polyglot Tax de Aditya Badramraju com muito interesse. A parte 4 fecha a série com as partes que realmente determinam se você confiaria nessa arquitetura em produção.

Um Modelo de Segurança para Todos os Modelos de Dados

Uma única política de Row-Level Security que cobre todos os modelos de dados. Uma política, uma prova para o auditor.

Backup Unificado = Recuperação Atômica

Em um stack poliglota, recuperação point-in-time em cinco bancos de dados é um pesadelo de consistência. Com um banco, é atômica por definição.

Integração MCP: Agentes Sem Middleware

SQL Server 2025 suporta o SQL MCP Server diretamente. Agentes chamam ferramentas, o motor impõe isolamento de tenant e mascaramento de colunas automaticamente.

Post original de Aditya Badramraju: The Polyglot Tax – Part 4.

Azure SDK Abril 2026: AI Foundry 2.0 e o Que Desenvolvedores .NET Devem Saber

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

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

Lançamentos mensais do SDK são fáceis de ignorar. Este tem algumas coisas que merecem atenção — especialmente se você constrói com AI Foundry, Cosmos DB em Java, ou faz provisionamento de infraestrutura a partir de código .NET.

Azure.AI.Projects 2.0.0 — Breaking Changes que Fazem Sentido

Splits de namespace, tipos renomeados, e convenção Is* consistente para booleanos.

Cosmos DB Java: Correção Crítica de Segurança (RCE)

Versão 4.79.0 corrige vulnerabilidade de Execução Remota de Código (CWE-502). Atualize imediatamente.

Novas Bibliotecas de Provisioning para .NET

Post original: Azure SDK Release (April 2026).

GPT-5.5 Chegou ao Azure Foundry — O que Desenvolvedores .NET Precisam Saber

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Este post foi traduzido automaticamente. Para a versão original, clique aqui.

A Microsoft acaba de anunciar que GPT-5.5 está geralmente disponível no Microsoft Foundry. Se você tem construído agentes no Azure, esta é a atualização que você estava esperando.

A progressão do GPT-5

GPT-5: unificou raciocínio e velocidade em um único sistema
GPT-5.4: raciocínio multi-etapas mais sólido, capacidades agênticas para empresas
GPT-5.5: raciocínio de contexto longo mais profundo, execução agêntica mais confiável, maior eficiência de tokens

O que realmente mudou

Codificação agêntica aprimorada: GPT-5.5 mantém contexto em grandes bases de código, diagnostica falhas arquiteturais e antecipa requisitos de testes. O modelo raciocina sobre o que mais uma correção afeta antes de agir.

Eficiência de tokens: Saídas de maior qualidade com menos tokens e menos tentativas. Custo e latência diretamente menores em produção.

Análise de contexto longo: Lida com documentos extensos e históricos multi-sessão sem perder o fio.

Preços

Modelo	Entrada ($/M tokens)	Entrada em cache	Saída ($/M tokens)
GPT-5.5	$5,00	$0,50	$30,00
GPT-5.5 Pro	$30,00	$3,00	$180,00

Por que o Foundry importa

O Foundry Agent Service permite definir agentes em YAML ou conectá-los com Microsoft Agent Framework, GitHub Copilot SDK, LangGraph ou OpenAI Agents SDK — e executá-los como agentes hospedados isolados com sistema de arquivos persistente, identidade Microsoft Entra e preços de escala a zero.

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "Você é um assistente útil.", name: "MeuAgente");

Veja o anúncio completo para todos os detalhes.

O Azure MCP Server Agora é um .mcpb — Instale-o sem Nenhum Runtime

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Este post foi traduzido automaticamente. Para a versão original, clique aqui.

Sabe o que era chato na configuração de servidores MCP? Você precisava de um runtime. Node.js para a versão npm, Python para pip/uvx, .NET SDK para a variante dotnet.

O Azure MCP Server acabou de mudar isso. Agora está disponível como .mcpb — um MCP Bundle — e a configuração é arrastar e soltar.

O que é um MCP Bundle?

Pense como uma extensão do VS Code (.vsix) ou extensão de navegador (.crx), mas para servidores MCP. Um arquivo .mcpb é um arquivo ZIP independente que inclui o binário do servidor e todas as suas dependências.

Como instalar

1. Baixe o bundle para sua plataforma

Vá para a página de GitHub Releases e baixe o arquivo .mcpb para seu OS e arquitetura.

2. Instale no Claude Desktop

O mais fácil: arraste e solte o arquivo .mcpb na janela do Claude Desktop na página de configurações de Extensões (☰ → Arquivo → Configurações → Extensões). Revise os detalhes, clique em Instalar, confirme.

3. Autentique no Azure

az login

Só isso. O Azure MCP Server usa suas credenciais Azure existentes.

O que você pode fazer

Mais de 100 ferramentas de serviços Azure diretamente do seu cliente IA:

Consultar e gerenciar Cosmos DB, Storage, Key Vault, App Service, Foundry
Gerar comandos az CLI para qualquer tarefa
Criar templates Bicep e Terraform

Para começar

Download: GitHub Releases
Repositório: aka.ms/azmcp
Docs: aka.ms/azmcp/docs

Veja o post completo.

Foundry Toolboxes: Um único endpoint para todas as ferramentas dos seus agentes

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

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

Aqui está um problema que parece chato até você vivenciá-lo: sua organização está construindo múltiplos agentes IA, cada um precisa de ferramentas, e cada time as configura do zero. A mesma integração de busca web, a mesma config do Azure AI Search, a mesma conexão com o servidor MCP do GitHub — mas em outro repositório, por outro time, com outras credenciais e sem governança compartilhada.

A Microsoft Foundry acabou de lançar Toolboxes em preview pública, e é uma resposta direta a esse problema.

O que é um Toolbox?

Um Toolbox é um bundle de ferramentas nomeado e reutilizável, definido uma vez no Foundry e exposto por meio de um único endpoint compatível com MCP. Qualquer runtime de agente que fale MCP pode consumi-lo — sem lock-in no Foundry Agents.

A proposta é simples: build once, consume anywhere. Defina as ferramentas, configure a autenticação de forma centralizada (OAuth passthrough, identidade gerenciada do Entra), publique o endpoint. Cada agente que precisar dessas ferramentas se conecta ao endpoint e as obtém todas.

Os quatro pilares (dois disponíveis hoje)

Pilar	Status	O que faz
Discover	Em breve	Encontra ferramentas aprovadas sem busca manual
Build	Disponível	Agrupa ferramentas em um bundle reutilizável
Consume	Disponível	Um endpoint MCP único expõe todas as ferramentas
Govern	Em breve	Auth centralizada + observabilidade em todas as chamadas

Exemplo prático

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Buscar documentação e responder a issues do GitHub.",
 tools=[
 {"type": "web_search", "description": "Buscar documentação pública"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Após a publicação, o Foundry fornece um endpoint unificado. Uma conexão, todas as ferramentas.

Sem lock-in no Foundry Agents

Os Toolboxes são criados e gerenciados no Foundry, mas a superfície de consumo é o protocolo MCP aberto. Você pode usá-los de agentes personalizados com Microsoft Agent Framework ou LangGraph, GitHub Copilot e outros IDEs compatíveis com MCP.

Por que importa agora

A onda multi-agentes está chegando à produção. Cada novo agente é uma nova superfície para configuração duplicada, credenciais desatualizadas e comportamento inconsistente. A base Build + Consume é suficiente para começar a centralizar. Quando o pilar Govern chegar, você terá uma camada de ferramentas observável e controlada centralmente para toda a sua frota de agentes.

Conclusão

Ainda é cedo — preview pública, SDK Python primeiro, com Discover e Govern ainda por vir. Mas o modelo é sólido e o design nativo de MCP significa que funciona com as ferramentas que você já está construindo. Confira o anúncio oficial para começar.

azd + GitHub Copilot: Configuração de projeto com IA e resolução inteligente de erros

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

Você conhece aquele momento em que quer fazer o deploy de uma app existente no Azure e se vê olhando para um azure.yaml em branco, tentando lembrar se sua API Express deveria usar Container Apps ou App Service? Esse momento acabou de ficar muito mais curto.

O Azure Developer CLI (azd) agora se integra com o GitHub Copilot de duas formas concretas: scaffolding assistido por IA durante o azd init, e resolução inteligente de erros quando os deploys falham. Ambas as funcionalidades ficam completamente no terminal — exatamente onde eu quero que estejam.

Configuração com Copilot durante azd init

Quando você executa azd init, agora aparece a opção “Set up with GitHub Copilot (Preview)”. Selecione-a e o Copilot analisa sua base de código para gerar o azure.yaml, os templates de infraestrutura e os módulos Bicep — com base no seu código real.

azd init
# Selecione: "Set up with GitHub Copilot (Preview)"

Pré-requisitos:

azd 1.23.11 ou superior — verifique com azd version ou atualize com azd update
Assinatura ativa do GitHub Copilot (Individual, Business ou Enterprise)
GitHub CLI (gh) — o azd pedirá login se necessário

O que acho genuinamente útil: funciona nos dois sentidos. Construindo do zero? O Copilot ajuda a configurar os serviços Azure certos desde o início. Tem uma app existente que você queria fazer deploy faz tempo? Aponte o Copilot para ela e ele gera a configuração sem você precisar reestruturar nada.

O que ele faz de verdade

Digamos que você tem uma API Express em Node.js com dependência do PostgreSQL. Em vez de decidir manualmente entre Container Apps e App Service, e depois escrever Bicep do zero, o Copilot detecta sua stack e gera:

Um azure.yaml com as configurações corretas de language, host e build
Um módulo Bicep para Azure Container Apps
Um módulo Bicep para Azure Database for PostgreSQL

E ele faz verificações prévias antes de tocar em qualquer coisa — verifica se seu diretório git está limpo, pede consentimento para as ferramentas do servidor MCP. Nada acontece sem que você saiba exatamente o que vai mudar.

Resolução de erros com Copilot

Erros de deploy são inevitáveis. Parâmetros faltando, problemas de permissão, disponibilidade de SKUs — e a mensagem de erro raramente diz a única coisa que você realmente precisa saber: como resolver.

Sem Copilot, o ciclo é: copiar o erro → pesquisar na documentação → ler três respostas irrelevantes do Stack Overflow → executar alguns comandos az CLI → tentar de novo e torcer. Com o Copilot integrado ao azd, esse ciclo colapsa. Quando qualquer comando azd falha, ele imediatamente oferece quatro opções:

Explain — descrição em linguagem natural do que deu errado
Guidance — instruções passo a passo para corrigir
Diagnose and Guide — análise completa + Copilot aplica a correção (com sua aprovação) + nova tentativa opcional
Skip — resolver você mesmo

O ponto crucial: o Copilot já tem contexto sobre seu projeto, o comando que falhou e a saída do erro. Suas sugestões são específicas para sua situação, não documentação genérica.

Configurar comportamento padrão

Se você sempre escolhe a mesma opção, pule o prompt interativo:

azd config set copilot.errorHandling.category troubleshoot

Valores: explain, guidance, troubleshoot, fix, skip. Você também pode habilitar auto-fix e retry:

azd config set copilot.errorHandling.fix allow

Voltar ao modo interativo a qualquer momento:

azd config unset copilot.errorHandling.category

Conclusão

Esta é exatamente o tipo de integração do Copilot que agrega valor real. Experimente executando azd update para obter a versão mais recente e use azd init no seu próximo projeto.

Leia o anúncio original aqui.

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 acontece em 18 de abril de 2026 no Kinépolis Diversia em Alcobendas, Madri. É o maior evento comunitário Azure da Espanha, reunindo 38 palestrantes em 3 trilhas paralelas cobrindo agentes de IA, redes Azure, Cosmos DB, Fabric, IoT, segurança e muito mais.

O evento vai das 08:30 às 18:30 e inclui keynote, intervalos para café, almoço e uma sessão de encerramento com perguntas.

Destaques da agenda

Domando Agentes de IA: governança, ferramentas e APIs com Azure AI Foundry e Azure API Management
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!: sistemas multi-agente em ação
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

Ingressos

A inscrição é uma doação simbólica — o valor total do ingresso vai diretamente para a Plan International, apoiando os direitos das crianças e a igualdade no mundo. Capacidade limitada, então garanta seu lugar cedo.

Azure Tour 2026

Além de Madri, o Global Azure Tour 2026 também inclui paradas em Zaragoza, Tenerife e Sevilha.

O RFT do Foundry ficou mais barato e inteligente — Veja o que mudou

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

Se você está desenvolvendo aplicações .NET que dependem de modelos fine-tunados, as atualizações do Foundry deste mês merecem sua atenção. O Reinforcement Fine-Tuning ficou mais acessível e significativamente mais barato.

Os detalhes completos estão no anúncio oficial, mas aqui vai o resumo prático.

Treinamento Global para o4-mini

o4-mini é o modelo preferido para cargas de trabalho pesadas em raciocínio e agentes. A grande novidade: agora você pode iniciar jobs de fine-tuning a partir de mais de 13 regiões Azure com taxas de treinamento por token mais baixas em comparação com o treinamento Standard. Mesma infraestrutura, mesma qualidade, maior alcance.

Se sua equipe está distribuída geograficamente, isso importa. Você não está mais preso a um punhado de regiões para treinar.

Aqui está a chamada da API REST para iniciar um job de treinamento global:

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
 -H "Content-Type: application/json" \
 -H "api-key: $AZURE_OPENAI_API_KEY" \
 -d '{
 "model": "o4-mini",
 "training_file": "<your-training-file-id>",
 "method": {
 "type": "reinforcement",
 "reinforcement": {
 "grader": {
 "type": "string_check",
 "name": "answer-check",
 "input": "{{sample.output_text}}",
 "reference": "{{item.reference_answer}}",
 "operation": "eq"
 }
 }
 },
 "hyperparameters": {
 "n_epochs": 2,
 "compute_multiplier": 1.0
 },
 "trainingType": "globalstandard"
 }'

Essa flag trainingType: globalstandard é a diferença chave.

Novos Avaliadores de Modelo: Família GPT-4.1

Avaliadores definem o sinal de recompensa contra o qual seu modelo otimiza. Até agora, avaliadores baseados em modelo eram limitados a um conjunto menor de modelos. Agora você tem três novas opções: GPT-4.1, GPT-4.1-mini e GPT-4.1-nano.

Quando você deve usar avaliadores de modelo em vez de determinísticos? Quando a saída da sua tarefa é aberta, quando você precisa de pontuação parcial em múltiplas dimensões, ou quando está construindo workflows com agentes onde a correção das chamadas de ferramentas depende do contexto semântico.

A questão é que a estratégia de níveis é prática:

GPT-4.1-nano para iterações iniciais. Baixo custo, ciclos de feedback rápidos.
GPT-4.1-mini quando sua rubrica de avaliação estiver estável e você precisar de maior fidelidade.
GPT-4.1 para avaliação em produção ou rubricas complexas onde cada decisão de pontuação conta.

Você pode até misturar tipos de avaliadores em um único job de RFT. Use string-match para a dimensão de “resposta correta” e um avaliador de modelo para avaliar a qualidade do raciocínio. Essa flexibilidade é honestamente o que torna isso útil para cargas de trabalho reais.

A Pegadinha do Formato de Dados do RFT

Isso confunde muita gente. O formato de dados do RFT é diferente do SFT. A última mensagem em cada linha deve ter o papel User ou Developer — não Assistant. A resposta esperada vai em uma chave de nível superior como reference_answer que o avaliador referencia diretamente.

Se você estava fazendo supervised fine-tuning e quer mudar para RFT, precisa reestruturar seus dados de treinamento. Não pule essa etapa ou seus jobs vão falhar silenciosamente.

Por Que Isso Importa para Desenvolvedores .NET

Se você está chamando modelos fine-tunados nas suas aplicações .NET através do SDK Azure OpenAI, treinamento mais barato significa que você pode iterar de forma mais agressiva. As opções de avaliadores de modelo significam que você pode fazer fine-tuning para tarefas com nuances — não apenas cenários de correspondência exata. E o guia de boas práticas no GitHub vai te poupar tempo real de debugging.

Comece pequeno. Dez a cem amostras. Avaliador simples. Valide o ciclo. Depois escale.

Seus experimentos de IA no Azure estão queimando dinheiro — Veja como resolver isso

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

Se você está construindo apps com IA no Azure agora, provavelmente já notou algo: sua fatura da nuvem está diferente do que costumava ser. Não apenas mais alta — mais estranha. Com picos. Difícil de prever.

A Microsoft acabou de publicar um ótimo artigo sobre princípios de otimização de custos na nuvem que ainda importam, e honestamente, o timing não poderia ser melhor. Porque as cargas de trabalho de IA mudaram o jogo quando se trata de custos.

Por que cargas de trabalho de IA são diferentes

A questão é a seguinte. Cargas de trabalho tradicionais de .NET são relativamente previsíveis. Você conhece seu tier de App Service, conhece seus DTUs de SQL, consegue estimar o gasto mensal com bastante precisão. Cargas de trabalho de IA? Nem tanto.

Você está testando múltiplos modelos para ver qual se encaixa. Está subindo infraestrutura com GPU para fine-tuning. Está fazendo chamadas de API para o Azure OpenAI onde o consumo de tokens varia enormemente dependendo do tamanho do prompt e do comportamento do usuário. Cada experimento custa dinheiro real, e você pode executar dezenas antes de encontrar a abordagem certa.

Essa imprevisibilidade é o que torna a otimização de custos crítica — não como algo secundário, mas desde o primeiro dia.

Gerenciamento vs. otimização — saiba a diferença

Uma distinção do artigo que acho que os desenvolvedores ignoram: há uma diferença entre gerenciamento de custos e otimização de custos.

Gerenciamento é rastreamento e relatórios. Você configura orçamentos no Azure Cost Management, recebe alertas, vê dashboards. Isso é o básico.

Otimização é onde você realmente toma decisões. Você realmente precisa daquele tier S3, ou o S1 daria conta da sua carga? Aquela instância de compute sempre ligada está ociosa nos finais de semana? Você poderia usar instâncias spot para seus jobs de treinamento?

Como desenvolvedores .NET, tendemos a focar no código e deixar as decisões de infraestrutura para “o time de operações”. Mas se você está fazendo deploy no Azure, essas decisões também são suas.

O que realmente funciona

Com base no artigo e na minha própria experiência, é isso que faz a diferença:

Saiba o que está gastando e onde. Tagueie seus recursos. Sério. Se você não consegue identificar qual projeto ou experimento está consumindo seu orçamento, não consegue otimizar nada. Azure Cost Management com tagging adequado é seu melhor amigo.

Estabeleça limites antes de experimentar. Use Azure Policy para restringir SKUs caros em ambientes de dev/test. Defina limites de gasto nos seus deployments do Azure OpenAI. Não espere a fatura chegar para perceber que alguém deixou um cluster de GPU rodando no final de semana.

Redimensione continuamente. Aquela VM que você escolheu durante a prototipação? Provavelmente está errada para produção. O Azure Advisor dá recomendações — realmente olhe para elas. Revise mensalmente, não anualmente.

Pense no ciclo de vida. Recursos de desenvolvimento devem ser desligados. Ambientes de teste não precisam rodar 24/7. Use políticas de desligamento automático. Para cargas de trabalho de IA especificamente, considere opções serverless onde você paga por execução em vez de manter o compute ligado.

Meça o valor, não apenas o custo. Essa é fácil de esquecer. Um modelo que custa mais mas entrega resultados significativamente melhores pode ser a decisão certa. O objetivo não é gastar o mínimo — é gastar de forma inteligente.

A conclusão

Otimização de custos na nuvem não é uma limpeza pontual. É um hábito. E com cargas de trabalho de IA tornando os gastos menos previsíveis do que nunca, construir esse hábito cedo te poupa de surpresas dolorosas depois.

Se você é um desenvolvedor .NET construindo no Azure, comece a tratar sua fatura da nuvem como trata seu código — revise regularmente, refatore quando ficar bagunçado, e nunca faça deploy sem entender quanto vai custar.

As ferramentas Azure MCP agora vêm integradas no Visual Studio 2022 — Sem extensão necessária

Emiliano Montesdeoca — Thu, 16 Apr 2026 00:00:00 +0000

Se você tem usado as ferramentas Azure MCP no Visual Studio através da extensão separada, já conhece o processo — instalar o VSIX, reiniciar, torcer para não quebrar, gerenciar incompatibilidades de versão. Essa fricção acabou.

Yun Jung Choi anunciou que as ferramentas Azure MCP agora são distribuídas diretamente como parte da carga de trabalho de desenvolvimento Azure no Visual Studio 2022. Sem extensão. Sem VSIX. Sem a dança do reiniciar.

O que isso realmente significa

A partir do Visual Studio 2022 versão 17.14.30, o Azure MCP Server vem incluído na carga de trabalho de desenvolvimento Azure. Se você já tem essa carga de trabalho instalada, basta ativá-lo no GitHub Copilot Chat e pronto.

Mais de 230 ferramentas em 45 serviços Azure — acessíveis diretamente pela janela de chat. Liste suas contas de armazenamento, faça deploy de uma app ASP.NET Core, diagnostique problemas no App Service, consulte o Log Analytics — tudo sem abrir uma aba do navegador.

Por que isso importa mais do que parece

A questão com ferramentas de desenvolvimento é a seguinte: cada passo extra é fricção, e fricção mata a adoção. Ter o MCP como extensão separada significava incompatibilidades de versão, falhas na instalação e mais uma coisa para manter atualizada. Integrá-lo na carga de trabalho significa:

Um único caminho de atualização pelo Visual Studio Installer
Sem divergência de versões entre a extensão e a IDE
Sempre atualizado — o MCP Server é atualizado com os releases regulares do VS

Para equipes que padronizam no Azure, isso é muito relevante. Você instala a carga de trabalho uma vez, ativa as ferramentas, e elas estão lá para cada sessão.

O que você pode fazer com isso

As ferramentas cobrem todo o ciclo de vida do desenvolvimento através do Copilot Chat:

Aprender — pergunte sobre serviços Azure, boas práticas, padrões de arquitetura
Projetar e desenvolver — obtenha recomendações de serviços, configure o código da sua aplicação
Fazer deploy — provisione recursos e faça deploy diretamente pela IDE
Solucionar problemas — consulte logs, verifique a saúde dos recursos, diagnostique problemas em produção

Um exemplo rápido — digite isso no Copilot Chat:

List my storage accounts in my current subscription.

O Copilot chama as ferramentas Azure MCP por trás dos panos, consulta suas assinaturas e retorna uma lista formatada com nomes, localizações e SKUs. Sem precisar do portal.

Como ativar

Atualize para o Visual Studio 2022 17.14.30 ou superior
Certifique-se de que a carga de trabalho Azure development está instalada
Abra o GitHub Copilot Chat
Clique no botão Select tools (o ícone das duas chaves)
Ative o Azure MCP Server

É isso. Fica ativado entre sessões.

Um detalhe

As ferramentas vêm desativadas por padrão — você precisa ativá-las manualmente. E as ferramentas específicas do VS 2026 não estão disponíveis no VS 2022. A disponibilidade das ferramentas também depende das permissões da sua assinatura Azure, assim como no portal.

O cenário geral

Isso faz parte de uma tendência clara: o MCP está se tornando o padrão para expor ferramentas de nuvem nas IDEs de desenvolvimento. Já vimos o lançamento estável do Azure MCP Server 2.0 e integrações MCP no VS Code e em outros editores. Tê-lo integrado no sistema de cargas de trabalho do Visual Studio é a evolução natural.

Para nós desenvolvedores .NET que vivemos no Visual Studio, isso elimina mais um motivo para trocar de contexto para o portal Azure. E sinceramente, quanto menos troca de abas, melhor.

Aspire 13.2 ganha MongoDB EF Core e Azure Data Lake — Duas integrações que vale a pena experimentar

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Aspire 13.2 acabou de chegar com duas novas integrações de banco de dados que merecem sua atenção: MongoDB Entity Framework Core e Azure Data Lake Storage. Se você queria usar EF Core com MongoDB em uma app Aspire, ou precisava conectar workloads de data lake com service discovery, esta versão entrega as duas coisas.

MongoDB encontra EF Core no Aspire

Essa é a que mais me empolga. O Aspire já suportava MongoDB há um tempo, mas sempre foi com o driver direto — sem EF Core, sem DbContext, sem consultas LINQ nos seus documentos. Agora você tem a experiência completa do EF Core com MongoDB, mais os health checks automáticos e o service discovery do Aspire.

A configuração segue o padrão típico do Aspire. No seu AppHost:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

Depois no seu projeto consumidor, adicione a integração EF Core:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

E registre seu DbContext:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

A partir daí, é EF Core padrão. Defina suas entidades, use seu DbContext como faria com qualquer outro provider. A integração cuida do connection pooling, traces OpenTelemetry e health checks nos bastidores.

Para desenvolvedores .NET que estavam usando MongoDB com o driver direto e configurando connection strings manualmente, essa é uma ótima melhoria. Você ganha a abstração completa do EF Core sem perder o service discovery do Aspire.

Azure Data Lake Storage entra na jogada

A segunda grande adição é uma integração Azure Data Lake Storage (ADLS). Se você está construindo pipelines de dados, processos ETL ou plataformas de analytics, agora pode conectar recursos de Data Lake da mesma forma que conectaria qualquer outra dependência do Aspire.

No AppHost:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

No projeto consumidor:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

Sem gerenciamento manual de connection strings, sem caçar credenciais. O Aspire provisiona os recursos e os injeta. Para quem constrói apps .NET cloud-native que lidam tanto com dados operacionais quanto com workloads analíticos, isso faz o data lake parecer um cidadão de primeira classe no modelo do Aspire.

As pequenas correções que importam

Além das funcionalidades principais, há algumas melhorias que valem a menção:

Correção do connection string do MongoDB — a barra antes do nome do banco de dados agora é tratada corretamente. Se você tinha um workaround, pode removê-lo
Exports do SQL Server — Aspire.Hosting.SqlServer agora exporta opções adicionais de configuração do servidor para um controle mais granular
Atualizações de emuladores — emulador do ServiceBus 2.0.0, emulador do App Configuration 1.0.2, e o emulador preview do CosmosDB agora inclui uma verificação de disponibilidade
Azure Managed Redis — agora usa rediss:// (Redis Secure) por padrão, então as conexões são criptografadas desde o início

Essa última é sutil mas importante — Redis criptografado por padrão significa uma coisa a menos para configurar em produção.

Concluindo

Aspire 13.2 é uma versão incremental, mas as integrações de MongoDB EF Core e Data Lake preenchem lacunas reais. Se você estava esperando suporte adequado de EF Core com MongoDB no Aspire, ou precisava do Data Lake como dependência de primeira classe, atualize para a 13.2 e teste. O comando aspire add gera tudo o que você precisa.

Leia as notas de versão completas para mais detalhes, e confira a galeria de integrações para a lista completa.

azd update — Um único comando para todos os seus gerenciadores de pacotes

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Sabe aquela mensagem “Uma nova versão do azd está disponível” que aparece a cada poucas semanas? Aquela que você ignora porque não lembra se instalou o azd via winget, Homebrew ou aquele script curl que rodou há seis meses? Pois é, isso finalmente foi resolvido.

A Microsoft acabou de lançar o azd update — um único comando que atualiza o Azure Developer CLI para a versão mais recente, independentemente de como você o instalou originalmente. Windows, macOS, Linux — não importa. Um comando só.

Como funciona

azd update

É isso. Se você quer acesso antecipado a novas funcionalidades, pode mudar para o build diário de insiders:

azd update --channel daily
azd update --channel stable

O comando detecta seu método de instalação atual e usa o mecanismo de atualização apropriado por baixo dos panos. Chega de “espera, eu usei winget ou choco nessa máquina?”

O pequeno detalhe

azd update está disponível a partir da versão 1.23.x. Se você está em uma versão anterior, vai precisar fazer uma última atualização manual usando seu método de instalação original. Depois disso, o azd update cuida de tudo dali em diante.

Verifique sua versão atual com azd version. Se precisar de uma instalação do zero, a documentação de instalação te ajuda.

Por que isso importa

É uma pequena melhoria de qualidade de vida, mas para quem usa azd diariamente para fazer deploy de agentes de IA e apps Aspire no Azure, estar atualizado significa menos momentos de “esse bug já tinha sido corrigido na última versão”. Uma coisa a menos para se preocupar.

Leia o anúncio completo e a análise mais detalhada do Jon Gallant para mais contexto.

Azure Smart Tier em GA — Otimização automática de custos no Blob Storage sem regras de ciclo de vida

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Se você já passou tempo ajustando as políticas de ciclo de vida do Azure Blob Storage e depois viu tudo desmoronar quando os padrões de acesso mudaram, isso aqui é para você. A Microsoft acabou de anunciar a disponibilidade geral do smart tier para Azure Blob e Data Lake Storage — uma capacidade de tiering totalmente gerenciada que move objetos automaticamente entre os níveis hot, cool e cold com base no uso real.

O que o smart tier realmente faz

O conceito é direto: o smart tier avalia continuamente o último horário de acesso de cada objeto na sua conta de armazenamento. Dados acessados frequentemente ficam em hot, dados inativos passam para cool após 30 dias, e depois para cold após mais 60 dias. Quando os dados são acessados novamente, são promovidos de volta para hot imediatamente. O ciclo recomeça.

Sem regras de ciclo de vida para configurar. Sem previsões de padrões de acesso. Sem ajustes manuais.

Durante a preview, a Microsoft reportou que mais de 50% da capacidade gerenciada pelo smart tier foi automaticamente movida para níveis mais frios com base nos padrões reais de acesso. É uma redução de custos significativa para contas de armazenamento grandes.

Por que isso importa para desenvolvedores .NET

Se você está construindo aplicações que geram logs, telemetria, dados analíticos, ou qualquer tipo de patrimônio de dados em crescimento — e sejamos honestos, quem não está? — os custos de armazenamento se acumulam rápido. A abordagem tradicional era escrever políticas de gerenciamento de ciclo de vida, testá-las e depois reajustá-las quando os padrões de acesso da sua aplicação mudavam. O smart tier elimina todo esse fluxo de trabalho.

Alguns cenários práticos onde isso ajuda:

Telemetria e logs de aplicações — hot durante a depuração, raramente acessados depois de algumas semanas
Pipelines de dados e saídas de ETL — acessados intensamente durante o processamento, depois majoritariamente cold
Conteúdo gerado por usuários — uploads recentes ficam em hot, conteúdo mais antigo esfria gradualmente
Dados de backup e arquivamento — acessados ocasionalmente para conformidade, na maioria das vezes inativos

Como configurar

Habilitar o smart tier é uma configuração única:

Contas novas: Selecione smart tier como o nível de acesso padrão durante a criação da conta de armazenamento (redundância zonal necessária)
Contas existentes: Mude o nível de acesso de blob da sua configuração padrão atual para smart tier

Objetos menores que 128 KiB ficam em hot e não geram a taxa de monitoramento. Para todo o resto, você paga as taxas padrão de capacidade hot/cool/cold sem cobranças de transição de nível, sem penalidades de exclusão antecipada e sem custos de recuperação de dados. Uma taxa mensal de monitoramento por objeto cobre a orquestração.

O trade-off que você precisa conhecer

As regras de tiering do smart tier são estáticas (30 dias → cool, 90 dias → cold). Se você precisa de limites personalizados — digamos, mover para cool após 7 dias para uma carga de trabalho específica — as regras de ciclo de vida continuam sendo o caminho. E não misture os dois: evite usar regras de ciclo de vida em objetos gerenciados pelo smart tier, pois eles podem entrar em conflito.

Conclusão

Isso não é revolucionário, mas resolve uma dor de cabeça operacional real. Se você gerencia contas de blob storage em crescimento e está cansado de manter políticas de ciclo de vida, habilite o smart tier e deixe o Azure cuidar disso. Está disponível hoje em quase todas as regiões zonais da nuvem pública.

Onde hospedar seus agentes de IA no Azure? Um guia prático de decisão

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Se você está construindo agentes de IA com .NET agora, provavelmente notou algo: existem muitas formas de hospedá-los no Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — e todos parecem razoáveis até você precisar escolher um. A Microsoft acabou de publicar um guia completo sobre hospedagem de agentes IA no Azure que esclarece isso, e eu quero detalhar tudo pela perspectiva prática de um desenvolvedor .NET.

As seis opções de relance

Aqui está como eu resumiria o cenário:

Opção	Melhor para	Você gerencia
Container Apps	Controle total de containers sem complexidade K8s	Observabilidade, estado, ciclo de vida
AKS	Compliance empresarial, multi-cluster, rede customizada	Tudo (esse é o ponto)
Azure Functions	Tarefas de agentes curtas e orientadas a eventos	Quase nada — serverless real
App Service	Agentes HTTP simples, tráfego previsível	Deploy, config de scaling
Foundry Agents	Agentes sem código via portal/SDK	Quase nada
Foundry Hosted Agents	Agentes com framework customizado e infra gerenciada	Apenas seu código de agente

As quatro primeiras são computação de propósito geral — você pode rodar agentes nelas, mas não foram projetadas para isso. As duas últimas são nativas de agentes: entendem conversas, chamadas de ferramentas e ciclos de vida de agentes como conceitos de primeira classe.

Foundry Hosted Agents — o ponto ideal para desenvolvedores .NET de agentes

Isso foi o que chamou minha atenção. Foundry Hosted Agents ficam bem no meio: você tem a flexibilidade de rodar seu próprio código (Semantic Kernel, Agent Framework, LangGraph — o que for) mas a plataforma cuida da infraestrutura, observabilidade e gerenciamento de conversas.

A peça-chave é o Hosting Adapter — uma camada de abstração fina que conecta seu framework de agentes à plataforma Foundry. Para o Microsoft Agent Framework, fica assim:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

Essa é toda a sua história de hosting. O adapter cuida da tradução de protocolos, streaming via server-sent events, histórico de conversa e rastreamento OpenTelemetry — tudo automaticamente. Sem middleware customizado, sem encanamento manual.

Deploy é genuinamente simples

Já fiz deploy de agentes no Container Apps antes e funciona, mas você acaba escrevendo muito código de cola para gerenciamento de estado e observabilidade. Com Hosted Agents e azd, o deploy é:

# Instalar a extensão de agente IA
azd ext install azure.ai.agents

# Inicializar a partir de um template
azd ai agent init

# Construir, enviar, fazer deploy — pronto
azd up

Esse único azd up constrói seu container, envia para o ACR, provisiona o projeto Foundry, faz deploy dos endpoints de modelo e inicia seu agente. Cinco etapas condensadas em um único comando.

Gerenciamento de conversas integrado

Essa é a parte que economiza mais tempo em produção. Em vez de construir seu próprio store de estado de conversa, Hosted Agents lidam com isso nativamente:

# Criar uma conversa persistente
conversation = openai_client.conversations.create()

# Primeira rodada
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# Segunda rodada — contexto é preservado
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Sem Redis. Sem store de sessões Cosmos DB. Sem middleware customizado para serialização de mensagens. A plataforma simplesmente cuida disso.

Meu framework de decisão

Depois de passar pelas seis opções, aqui está meu modelo mental rápido:

Precisa de zero infraestrutura? → Foundry Agents (portal/SDK, sem containers)
Tem código de agente customizado mas quer hosting gerenciado? → Foundry Hosted Agents
Precisa de tarefas de agentes curtas orientadas a eventos? → Azure Functions
Precisa de máximo controle de containers sem K8s? → Container Apps
Precisa de compliance rigorosa e multi-cluster? → AKS
Tem um agente HTTP simples com tráfego previsível? → App Service

Para a maioria dos desenvolvedores .NET construindo com Semantic Kernel ou Microsoft Agent Framework, Hosted Agents é provavelmente o ponto de partida certo. Você obtém scale-to-zero, OpenTelemetry integrado, gerenciamento de conversas e flexibilidade de framework — sem gerenciar Kubernetes ou montar sua própria stack de observabilidade.

Para finalizar

O cenário de hospedagem de agentes no Azure está amadurecendo rápido. Se você está começando um novo projeto de agente IA hoje, eu consideraria seriamente Foundry Hosted Agents antes de recorrer a Container Apps ou AKS por hábito. A infraestrutura gerenciada economiza tempo real, e o padrão hosting adapter permite manter sua escolha de framework.

Confira o guia completo da Microsoft e o repo Foundry Samples para exemplos funcionais.

As Agent Skills no .NET ficaram realmente flexíveis

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

Se você tem construído agentes com o Microsoft Agent Framework, já conhece o processo: define skills, conecta a um provider e deixa o agente decidir qual invocar. O que há de novo é como você cria essas skills — e o salto em flexibilidade é significativo.

A última atualização introduz três padrões de autoria para agent skills: baseadas em arquivos, baseadas em classes e definidas em código inline. As três se conectam a um único AgentSkillsProviderBuilder, o que significa que você pode misturar e combinar sem lógica de roteamento nem código especial. Vou te mostrar cada uma e quando usar.

Skills baseadas em arquivos: o ponto de partida

Skills baseadas em arquivos são exatamente o que parecem — um diretório no disco com um arquivo SKILL.md, scripts opcionais e documentos de referência. A forma mais direta de dar novas capacidades ao seu agente:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

O frontmatter do SKILL.md declara o nome e descrição, e a seção de instruções diz ao agente como usar os scripts e referências:

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

Depois você conecta com SubprocessScriptRunner.RunAsync para execução de scripts:

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

O agente descobre a skill automaticamente e invoca o script de provisioning quando precisa verificar o status das contas. Limpo e simples.

Skills baseadas em classes: distribuir via NuGet

Aqui é onde fica interessante para times. Skills baseadas em classes derivam de AgentClassSkill<T> e usam atributos como [AgentSkillResource] e [AgentSkillScript] para que o framework descubra tudo por reflexão:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

O legal é que um time pode empacotar isso como pacote NuGet. Você adiciona ao projeto, coloca no builder e funciona junto com suas skills de arquivo sem coordenação:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Ambas as skills aparecem no system prompt do agente. O agente decide qual usar baseado na conversa — sem código de roteamento.

Skills inline: a ponte rápida

Sabe aquele momento quando outro time está construindo exatamente a skill que você precisa, mas só vai ficar pronta no próximo sprint? AgentInlineSkill é sua ponte:

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

Adicione ao builder assim como as outras:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Quando o pacote NuGet finalmente sair, você troca a skill inline pela versão baseada em classe. O agente não percebe a diferença.

Mas skills inline não são só para pontes. Também são a escolha certa quando você precisa gerar skills dinamicamente em runtime — pense em uma skill por unidade de negócio carregada de configuração — ou quando um script precisa capturar estado local que não pertence a um contêiner DI.

Aprovação de scripts: humano no loop

Para nós desenvolvedores .NET construindo agentes de produção, essa é a parte que realmente desbloqueia conversas de deploy. Alguns scripts têm consequências reais — inscrever alguém em benefícios, consultar infraestrutura de produção. Ative UseScriptApproval e o agente pausa antes de executar qualquer script:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

Quando o agente quer executar um script, retorna um pedido de aprovação. Seu app coleta a decisão — aprovar ou rejeitar — e o agente continua. Em ambientes regulados, essa é a diferença entre “podemos fazer deploy disso” e “o jurídico disse não.”

Por que essa combinação importa

O verdadeiro poder não está em nenhum padrão individual — está na composição. Você pode:

Começar pequeno com uma skill de arquivo, iterar nas instruções e publicar sem escrever C#
Distribuir skills reutilizáveis como pacotes NuGet que outros times adicionam com uma linha
Cobrir lacunas com skills inline quando precisa de algo agora
Filtrar diretórios compartilhados com predicados para que seu agente só carregue o que deve
Adicionar supervisão humana para scripts que tocam sistemas de produção

Tudo isso se compõe via AgentSkillsProviderBuilder. Sem roteamento especial, sem lógica condicional, sem verificações de tipo de skill.

Para encerrar

As agent skills no .NET agora têm um modelo de autoria genuinamente flexível. Seja você um desenvolvedor solo prototipando com skills de arquivo ou um time enterprise distribuindo capacidades empacotadas via NuGet, os padrões se encaixam. E o mecanismo de aprovação de scripts o torna pronto para produção em ambientes onde você precisa daquele checkpoint humano.

Confira o anúncio original, a documentação de Agent Skills no Microsoft Learn e os exemplos .NET no GitHub para começar.

Azure MCP Server 2.0 Chegou — Automação Agnóstica em Nuvem Self-Hosted Está Aqui

Emiliano Montesdeoca — Sat, 11 Apr 2026 00:00:00 +0000

Este artigo foi traduzido automaticamente. Para a versão original, clique aqui.

Se você vem construindo algo com MCP e Azure ultimamente, provavelmente já sabe que a experiência local funciona bem. Coloque um servidor MCP, deixe seu agente IA falar com recursos do Azure, siga em frente. Mas no momento em que você precisa compartilhar essa configuração com um time? É aí que as coisas ficavam complicadas.

Não mais. Azure MCP Server acabou de atingir a versão 2.0 estável, e a feature principal é exatamente o que times empresariais estão pedindo: suporte para servidor MCP remoto self-hosted.

O que é Azure MCP Server?

Um rápido refresco. Azure MCP Server implementa a especificação do Model Context Protocol e expõe capacidades do Azure como ferramentas estruturadas e descobríveis que agentes IA podem invocar. Pense nisto como uma ponte padronizada entre seu agente e o Azure — provisionamento, implantação, monitoramento, diagnósticos, tudo através de uma interface consistente.

Os números falam por si: 276 ferramentas MCP em 57 serviços do Azure. Isso é cobertura séria.

O grande destaque: implantações remotas self-hosted

Aqui está a questão. Executar MCP localmente na sua máquina é bom para dev e experimentos. Mas em um cenário real de time, você precisa de:

Acesso compartilhado para desenvolvedores e sistemas de agentes internos
Configuração centralizada (contexto de tenant, padrões de assinatura, telemetria)
Limites de rede e política empresariais
Integração em pipelines CI/CD

Azure MCP Server 2.0 aborda tudo isso. Você pode implantá-lo como um serviço interno gerenciado centralmente com transporte baseado em HTTP, autenticação apropriada e governança consistente.

Para autenticação, você tem duas opções sólidas:

Managed Identity — quando em execução junto com Microsoft Foundry
Fluxo On-Behalf-Of (OBO) — delegação OpenID Connect que chama APIs do Azure usando o contexto do usuário autenticado

Esse fluxo OBO é particularmente interessante para nós desenvolvedores .NET. Significa que seus fluxos de trabalho agnósticos podem operar com as permissões reais do usuário, não alguma conta de serviço com privilégios excessivos. Princípio do menor privilégio, embutido certo.

Endurecimento de segurança

Isso não é apenas um lançamento de feature — é um de segurança também. O lançamento 2.0 adiciona:

Validação de endpoint mais forte
Proteções contra padrões de injeção em ferramentas orientadas a query
Controles de isolamento mais rigorosos para ambientes de dev

Se você vai expor MCP como um serviço compartilhado, essas salvaguardas importam. Muito.

Onde você pode usá-lo?

A história de compatibilidade do cliente é ampla. Azure MCP Server 2.0 funciona com:

IDEs: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
Agentes CLI: GitHub Copilot CLI, Claude Code
Standalone: servidor local para configurações simples
Self-hosted remoto: a nova estrela do 2.0

Além disso há suporte a nuvem soberana para Azure US Government e Azure operado pela 21Vianet, que é crítico para implantações reguladas.

Por que isso importa para desenvolvedores .NET

Se você está construindo aplicações agnósticas com .NET — seja com Semantic Kernel, Microsoft Agent Framework, ou sua própria orquestração — Azure MCP Server 2.0 lhe dá uma maneira pronta para produção de deixar seus agentes interagirem com infraestrutura do Azure. Sem wrappers REST customizados. Sem padrões de integração específicos do serviço. Apenas MCP.

Combinado com a API fluente para MCP Apps que saiu alguns dias atrás, o ecossistema MCP .NET está amadurecendo rapidamente.

Começando

Escolha seu caminho:

Repositório GitHub — código fonte, documentação, tudo
Imagem Docker — implantação containerizada
Extensão VS Code — integração de IDE
Guia de self-hosting — a feature principal do 2.0

Resumindo

Azure MCP Server 2.0 é exatamente o tipo de upgrade de infraestrutura que não parece vistoso em uma demo mas muda tudo na prática. MCP remoto self-hosted com autenticação apropriada, endurecimento de segurança e suporte a nuvem soberana significa que MCP está pronto para times reais construindo fluxos de trabalho agnósticos reais no Azure. Se você estava esperando o sinal “pronto para empresas” — esse é ele.

A avaliação de modernização do GitHub Copilot é a melhor ferramenta de migração que você ainda não está usando

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Migrar uma aplicação legada do .NET Framework para .NET moderno é uma daquelas tarefas que todo mundo sabe que deveria fazer, mas ninguém quer começar. Nunca é apenas “mudar o target framework.” São APIs que desapareceram, pacotes que não existem mais, modelos de hosting que funcionam de forma completamente diferente, e um milhão de pequenas decisões sobre o que containerizar, o que reescrever e o que deixar como está.

Jeffrey Fritz acabou de publicar um mergulho profundo na avaliação de modernização do GitHub Copilot, e honestamente? Este é o melhor tooling de migração que eu vi para .NET. Não pela geração de código — isso já é padrão agora. Pelo documento de avaliação que ele produz.

Não é apenas um motor de sugestões de código

A extensão do VS Code segue um modelo de Avaliar → Planejar → Executar. A fase de avaliação analisa todo o seu codebase e produz um documento estruturado que captura tudo: o que precisa mudar, quais recursos Azure provisionar, qual modelo de deploy usar. Tudo que vem depois — infraestrutura como código, containerização, manifestos de deploy — flui do que a avaliação encontra.

A avaliação é armazenada em .github/modernize/assessment/ no seu projeto. Cada execução produz um relatório independente, então você vai construindo um histórico e pode acompanhar como sua postura de migração evolui conforme corrige issues.

Duas formas de começar

Avaliação Recomendada — o caminho rápido. Escolha entre domínios curados (Upgrade Java/.NET, Cloud Readiness, Segurança) e obtenha resultados significativos sem mexer em configuração. Ótimo para um primeiro olhar de onde sua aplicação está.

Avaliação Personalizada — o caminho direcionado. Configure exatamente o que analisar: compute alvo (App Service, AKS, Container Apps), SO alvo, análise de containerização. Escolha múltiplos alvos Azure para comparar abordagens de migração lado a lado.

Essa visão de comparação é genuinamente útil. Uma app com 3 issues obrigatórios para App Service pode ter 7 para AKS. Ver ambos ajuda a tomar a decisão de hosting antes de se comprometer com um caminho de migração.

O detalhamento de issues é acionável

Cada issue vem com um nível de criticidade:

Obrigatório — deve ser corrigido ou a migração falha
Potencial — pode impactar a migração, precisa de julgamento humano
Opcional — melhorias recomendadas, não bloqueiam a migração

E cada issue linka para arquivos afetados e números de linha, fornece uma descrição detalhada do que está errado e por que importa para sua plataforma alvo, dá passos concretos de remediação (não apenas “corrija isso”), e inclui links para documentação oficial.

Você pode atribuir issues individuais a desenvolvedores e eles têm tudo que precisam para agir. Essa é a diferença entre uma ferramenta que diz “tem um problema” e uma que diz como resolver.

Os caminhos de upgrade cobertos

Para .NET especificamente:

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

Cada caminho de upgrade tem regras de detecção que sabem quais APIs foram removidas, quais padrões não têm equivalente direto, e quais issues de segurança precisam de atenção.

Para times que gerenciam múltiplas aplicações, também há um CLI que suporta avaliações batch multi-repo — clone todos os repos, avalie todos, obtenha relatórios por app mais uma visão agregada do portfólio.

Minha opinião

Se você está sentado em cima de aplicações legadas em .NET Framework (e vamos ser honestos, a maioria dos times enterprise está), esta é a ferramenta para começar. Só o documento de avaliação já vale o tempo — transforma um vago “deveríamos modernizar” em uma lista concreta e priorizada de itens de trabalho com caminhos claros adiante.

O fluxo de trabalho colaborativo também é inteligente: exporte avaliações, compartilhe com seu time, importe-as sem re-executar. Revisões de arquitetura onde quem toma decisões não é quem roda as ferramentas? Coberto.

Finalizando

A avaliação de modernização do GitHub Copilot transforma a migração .NET de um projeto assustador e indefinido em um processo estruturado e rastreável. Comece com uma avaliação recomendada para ver onde você está, depois use avaliações personalizadas para comparar alvos Azure e construir seu plano de migração.

Leia o walkthrough completo e baixe a extensão do VS Code para testar no seu próprio codebase.

A Engenharia de Plataformas Agêntica Está se Tornando Real — Git-APE Mostra Como

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Engenharia de plataformas tem sido um daqueles termos que soam ótimos em conferências, mas que normalmente significam “construímos um portal interno e um wrapper de Terraform.” A verdadeira promessa — infraestrutura self-service que seja realmente segura, governada e rápida — sempre esteve a alguns passos de distância.

O time Azure acaba de publicar a Parte 2 da série sobre engenharia de plataformas agêntica, e esta é toda sobre a implementação prática. Eles chamam de Git-APE (sim, a sigla é intencional), e é um projeto open source que usa agentes do GitHub Copilot mais servidores Azure MCP para transformar solicitações em linguagem natural em infraestrutura validada e implantada.

O que o Git-APE realmente faz

A ideia central: em vez de desenvolvedores aprenderem módulos Terraform, navegarem por UIs de portais ou abrirem tickets para o time de plataforma, eles conversam com um agente Copilot. O agente interpreta a intenção, gera Infrastructure-as-Code, valida contra políticas e implanta — tudo dentro do VS Code.

Aqui está a configuração:

git clone https://github.com/Azure/git-ape
cd git-ape

Abra o workspace no VS Code, e os arquivos de configuração do agente são descobertos automaticamente pelo GitHub Copilot. Você interage diretamente com o agente:

@git-ape deploy a function app with storage in West Europe

O agente usa o Azure MCP Server por baixo dos panos para interagir com os serviços Azure. A configuração MCP nas opções do VS Code habilita capacidades específicas:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Por que isso importa

Para nós que construímos no Azure, isso muda a conversa de engenharia de plataformas de “como construímos um portal” para “como descrevemos nossas guardrails como APIs.” Quando a interface da sua plataforma é um agente de IA, a qualidade das suas restrições e políticas se torna o produto.

O blog da Parte 1 apresentou a teoria: APIs bem descritas, schemas de controle e guardrails explícitas tornam as plataformas agent-ready. A Parte 2 prova que funciona entregando ferramentas reais. O agente não gera recursos cegamente — valida contra melhores práticas, respeita convenções de nomenclatura e aplica as políticas da sua organização.

A limpeza é igualmente simples:

@git-ape destroy my-resource-group

Minha opinião

Vou ser honesto — aqui é mais sobre o padrão do que sobre a ferramenta específica. O Git-APE em si é uma demo/arquitetura de referência. Mas a ideia subjacente — agentes como a interface da sua plataforma, MCP como protocolo, GitHub Copilot como host — é para onde a experiência do desenvolvedor enterprise está caminhando.

Se você é um time de plataforma procurando como tornar seu ferramental interno amigável para agentes, não há melhor ponto de partida. E se você é um desenvolvedor .NET se perguntando como isso se conecta ao seu mundo: o Azure MCP Server e os agentes do GitHub Copilot funcionam com qualquer workload Azure. Sua API ASP.NET Core, seu stack .NET Aspire, seus microsserviços em containers — tudo pode ser alvo de um fluxo de deploy agêntico.

Concluindo

Git-APE é um olhar inicial mas concreto sobre engenharia de plataformas agêntica na prática. Clone o repo, experimente a demo e comece a pensar em como as APIs e políticas da sua plataforma precisariam ser para que um agente as use com segurança.

Leia o post completo para o walkthrough e vídeos de demonstração.

Conecte seus servidores MCP no Azure Functions aos Foundry Agents — Veja como

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Isso é algo que eu amo no ecossistema MCP: você constrói seu servidor uma vez e ele funciona em qualquer lugar. VS Code, Visual Studio, Cursor, ChatGPT — cada cliente MCP pode descobrir e usar suas ferramentas. Agora, a Microsoft está adicionando mais um consumidor a essa lista: os agentes Foundry.

Lily Ma da equipe do Azure SDK publicou um guia prático sobre como conectar servidores MCP implantados no Azure Functions com agentes Microsoft Foundry. Se você já tem um servidor MCP, isso é puro valor agregado — sem necessidade de reconstruir nada.

Por que essa combinação faz sentido

Azure Functions te dá infraestrutura escalável, autenticação integrada e cobrança serverless para hospedar servidores MCP. Microsoft Foundry te dá agentes de IA que podem raciocinar, planejar e agir. Conectar os dois significa que suas ferramentas personalizadas — consultar um banco de dados, chamar uma API de negócio, executar lógica de validação — se tornam capacidades que agentes de IA empresariais podem descobrir e usar autonomamente.

O ponto-chave: seu servidor MCP continua o mesmo. Você está apenas adicionando o Foundry como mais um consumidor. As mesmas ferramentas que funcionam no seu setup do VS Code agora alimentam um agente de IA com o qual sua equipe ou clientes interagem.

Opções de autenticação

É aqui que o post realmente agrega valor. Quatro métodos de autenticação dependendo do seu cenário:

Método	Caso de uso
Baseado em chave (padrão)	Desenvolvimento ou servidores sem autenticação Entra
Microsoft Entra	Produção com identidades gerenciadas
Passthrough de identidade OAuth	Produção onde cada usuário se autentica individualmente
Sem autenticação	Dev/testes ou apenas dados públicos

Para produção, Microsoft Entra com identidade do agente é o caminho recomendado. O passthrough de identidade OAuth é para quando o contexto do usuário importa — o agente solicita que os usuários façam login, e cada requisição carrega o token próprio do usuário.

Configurando

O fluxo geral:

Faça deploy do seu servidor MCP no Azure Functions — exemplos disponíveis para .NET, Python, TypeScript e Java
Habilite a autenticação MCP integrada na sua function app
Obtenha sua URL de endpoint — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
Adicione o servidor MCP como ferramenta no Foundry — navegue até seu agente no portal, adicione uma nova ferramenta MCP, forneça o endpoint e as credenciais

Depois teste no playground do Agent Builder enviando um prompt que acionaria uma das suas ferramentas.

Minha opinião

A história de composabilidade aqui está ficando realmente forte. Construa seu servidor MCP uma vez em .NET (ou Python, TypeScript, Java), faça deploy no Azure Functions, e cada cliente compatível com MCP pode usá-lo — ferramentas de programação, apps de chat, e agora agentes de IA empresariais. É um padrão “escreva uma vez, use em qualquer lugar” que realmente funciona.

Para desenvolvedores .NET especificamente, a extensão MCP do Azure Functions torna isso simples. Você define suas ferramentas como Azure Functions, faz deploy, e tem um servidor MCP de nível de produção com toda a segurança e escalabilidade que o Azure Functions proporciona.

Finalizando

Se você tem ferramentas MCP rodando no Azure Functions, conectá-las aos agentes Foundry é uma vitória rápida — suas ferramentas personalizadas se tornam capacidades de IA empresarial com autenticação adequada e sem alterações de código no servidor.

Leia o guia completo para instruções passo a passo sobre cada método de autenticação, e confira a documentação detalhada para configurações de produção.

Construindo UIs Multi-Agente em Tempo Real Que Não Parecem uma Caixa Preta

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

A questão com sistemas multi-agente é a seguinte: eles ficam incríveis nas demos. Três agentes passando trabalho entre si, resolvendo problemas, tomando decisões. Aí você tenta colocar na frente de usuários reais e… silêncio. Um indicador girando. Nenhuma ideia de qual agente está fazendo o quê ou por que o sistema pausou. Isso não é um produto — é um problema de confiança.

O time do Microsoft Agent Framework acabou de publicar um tutorial fantástico sobre como combinar fluxos MAF com AG-UI, um protocolo aberto para transmitir eventos de execução de agentes para um frontend via Server-Sent Events. E sinceramente? Essa é a ponte que estava faltando.

Por que isso importa para desenvolvedores .NET

Se você está construindo apps com IA, provavelmente já bateu nesse muro. Sua orquestração backend funciona perfeitamente — agentes passam tarefas entre si, ferramentas disparam, decisões são tomadas. Mas o frontend não faz ideia do que está acontecendo nos bastidores. AG-UI resolve isso definindo um protocolo padrão para transmitir eventos de agentes (pense em RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_*) diretamente para sua camada de UI via SSE.

A demo que construíram é um fluxo de suporte ao cliente com três agentes: um agente de triagem que roteia solicitações, um agente de reembolso que cuida de questões financeiras, e um agente de pedidos que gerencia substituições. Cada agente tem suas próprias ferramentas, e a topologia de handoff é definida explicitamente — nada de “descubra a partir do prompt”.

A topologia de handoff é a verdadeira estrela

O que me chamou a atenção é como o HandoffBuilder permite declarar um grafo dirigido de roteamento entre agentes:

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

Cada add_handoff cria uma aresta dirigida com uma descrição em linguagem natural. O framework gera ferramentas de handoff para cada agente baseado nessa topologia. Então as decisões de roteamento são fundamentadas na sua estrutura de orquestração, não apenas no que o LLM resolve fazer. Isso é enorme para confiabilidade em produção.

Human-in-the-loop que realmente funciona

A demo mostra dois padrões de interrupção que qualquer app de agentes do mundo real precisa:

Interrupções de aprovação de ferramentas — quando um agente chama uma ferramenta marcada com approval_mode="always_require", o fluxo pausa e emite um evento. O frontend renderiza um modal de aprovação com o nome da ferramenta e seus argumentos. Sem loops de retry queimando tokens — apenas um fluxo limpo de pausa-aprovação-retomada.

Interrupções de solicitação de informação — quando um agente precisa de mais contexto do usuário (como um ID de pedido), ele pausa e pergunta. O frontend mostra a pergunta, o usuário responde, e a execução retoma exatamente de onde parou.

Ambos os padrões são transmitidos como eventos AG-UI padrão, então seu frontend não precisa de lógica personalizada por agente — simplesmente renderiza qualquer evento que chegue pela conexão SSE.

Conectar tudo é surpreendentemente simples

A integração entre MAF e AG-UI é uma única chamada de função:

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

O workflow_factory cria um fluxo novo por thread, então cada conversa tem estado isolado. O endpoint cuida de toda a tubulação SSE automaticamente. Se você já usa FastAPI (ou pode adicioná-lo como uma camada leve), isso tem praticamente zero fricção.

Minha opinião

Para nós desenvolvedores .NET, a pergunta imediata é: “Posso fazer isso em C#?” O Agent Framework está disponível para .NET e Python, e o protocolo AG-UI é agnóstico de linguagem (é apenas SSE). Então embora essa demo específica use Python e FastAPI, o padrão se traduz diretamente. Você poderia montar uma API mínima ASP.NET Core com endpoints SSE seguindo o mesmo schema de eventos AG-UI.

A conclusão mais importante é que UIs multi-agente estão se tornando uma preocupação de primeira classe, não algo deixado para depois. Se você está construindo qualquer coisa onde agentes interagem com humanos — suporte ao cliente, fluxos de aprovação, processamento de documentos — essa combinação de orquestração MAF e transparência AG-UI é o padrão a seguir.

Concluindo

AG-UI + Microsoft Agent Framework te dá o melhor dos dois mundos: orquestração multi-agente robusta no backend e visibilidade em tempo real no frontend. Sem mais interações de agentes como caixas pretas.

Confira o tutorial completo e o repositório do protocolo AG-UI para se aprofundar.

Microsoft Foundry Março 2026 — GPT-5.4, Agent Service GA e a Atualização do SDK Que Muda Tudo

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Os posts mensais de “Novidades no Microsoft Foundry” costumam ser uma mistura de melhorias incrementais e alguma funcionalidade destaque ocasional. A edição de março de 2026? É basicamente tudo destaque. Foundry Agent Service chega ao GA, GPT-5.4 é lançado para produção, o SDK recebe uma grande versão estável, e Fireworks AI traz inferência de modelos abertos para o Azure. Vamos detalhar o que importa para desenvolvedores .NET.

Foundry Agent Service está pronto para produção

Essa é a grande novidade. O runtime de agentes de nova geração está em disponibilidade geral — construído sobre a API Responses da OpenAI, compatível em protocolo com agentes OpenAI, e aberto a modelos de múltiplos provedores. Se você está construindo com a API Responses hoje, migrar para o Foundry adiciona segurança empresarial, rede privada, RBAC do Entra, rastreamento completo e avaliação sobre sua lógica de agentes existente.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
)

Adições principais: rede privada de ponta a ponta, expansão de autenticação MCP (incluindo passthrough OAuth), preview do Voice Live para agentes de voz para voz, e agentes hospedados em 6 novas regiões.

GPT-5.4 — confiabilidade acima de inteligência pura

GPT-5.4 não é sobre ser mais inteligente. É sobre ser mais confiável. Raciocínio mais forte em interações longas, melhor aderência a instruções, menos falhas no meio de workflows, e capacidades integradas de uso de computador. Para agentes em produção, essa confiabilidade importa muito mais do que pontuações em benchmarks.

Modelo	Preço (por M tokens)	Ideal Para
GPT-5.4 (≤272K)	$2.50 / $15 saída	Agentes em produção, código, fluxos de documentos
GPT-5.4 Pro	$30 / $180 saída	Análise profunda, raciocínio científico
GPT-5.4 Mini	Econômico	Classificação, extração, chamadas leves de ferramentas

A jogada inteligente é uma estratégia de roteamento: GPT-5.4 Mini lida com o trabalho de alto volume e baixa latência enquanto GPT-5.4 cuida das solicitações com raciocínio pesado.

O SDK finalmente está estável

O SDK azure-ai-projects lançou versões estáveis em todas as linguagens — Python 2.0.0, JS/TS 2.0.0, Java 2.0.0, e .NET 2.0.0 (1º de abril). A dependência do azure-ai-agents sumiu — tudo vive sob AIProjectClient. Instale com pip install azure-ai-projects e o pacote inclui openai e azure-identity como dependências diretas.

Para desenvolvedores .NET, isso significa um único pacote NuGet para toda a superfície do Foundry. Chega de malabarismo com SDKs de agentes separados.

Fireworks AI traz modelos abertos para o Azure

Talvez a adição mais interessante arquitetonicamente: Fireworks AI processando mais de 13 trilhões de tokens por dia a ~180K requisições/segundo, agora disponível através do Foundry. DeepSeek V3.2, gpt-oss-120b, Kimi K2.5, e MiniMax M2.5 no lançamento.

A verdadeira história é o bring-your-own-weights — faça upload de pesos quantizados ou fine-tunados de qualquer lugar sem mudar a stack de serving. Deploy via serverless pay-per-token ou throughput provisionado.

Outros destaques

Phi-4 Reasoning Vision 15B — raciocínio multimodal para gráficos, diagramas e layouts de documentos
Evaluations GA — avaliadores prontos para uso com monitoramento contínuo de produção integrado ao Azure Monitor
Priority Processing (Preview) — faixa de computação dedicada para cargas de trabalho sensíveis à latência
Voice Live — runtime de voz para voz que se conecta diretamente aos agentes do Foundry
Tracing GA — inspeção de rastreamento de agentes de ponta a ponta com ordenação e filtragem
Depreciação do PromptFlow — migração para Microsoft Framework Workflows até janeiro de 2027

Conclusão

Março de 2026 é um ponto de virada para o Foundry. Agent Service GA, SDKs estáveis em todas as linguagens, GPT-5.4 para agentes de produção confiáveis, e inferência de modelos abertos via Fireworks AI — a plataforma está pronta para cargas de trabalho sérias.

Leia o resumo completo e crie seu primeiro agente para começar.

SQL MCP Server — A forma certa de dar acesso a bancos de dados para agentes de IA

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Vamos ser honestos: a maioria dos servidores MCP de banco de dados disponíveis hoje são assustadores. Eles pegam uma consulta em linguagem natural, geram SQL na hora e executam contra seus dados de produção. O que poderia dar errado? (Tudo. Tudo poderia dar errado.)

O time do Azure SQL acabou de apresentar o SQL MCP Server, e ele adota uma abordagem fundamentalmente diferente. Construído como uma funcionalidade do Data API builder (DAB) 2.0, dá aos agentes de IA acesso estruturado e determinístico a operações de banco de dados — sem NL2SQL, sem expor seu esquema, e com RBAC completo em cada etapa.

Por que não NL2SQL?

Essa é a decisão de design mais interessante. Modelos não são determinísticos, e consultas complexas são as mais propensas a produzir erros sutis. As consultas exatas que os usuários esperam que a IA gere são também as que precisam de mais escrutínio quando produzidas de forma não determinística.

Em vez disso, o SQL MCP Server usa uma abordagem NL2DAB. O agente trabalha com a camada de abstração de entidades do Data API builder e seu construtor de consultas integrado para produzir T-SQL preciso e bem formado de maneira determinística. Mesmo resultado para o usuário, mas sem o risco de JOINs alucinados ou exposição acidental de dados.

Sete ferramentas, não setecentas

O SQL MCP Server expõe exatamente sete ferramentas DML, independentemente do tamanho do banco de dados:

describe_entities — descobrir entidades e operações disponíveis
create_record — inserir linhas
read_records — consultar tabelas e views
update_record — modificar linhas
delete_record — remover linhas
execute_entity — executar stored procedures
aggregate_records — consultas de agregação

Isso é inteligente porque janelas de contexto são o espaço de pensamento do agente. Inundá-las com centenas de definições de ferramentas deixa menos espaço para raciocínio. Sete ferramentas fixas mantêm o agente focado em pensar em vez de navegar.

Cada ferramenta pode ser habilitada ou desabilitada individualmente:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

Começando em três comandos

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

Isso é um SQL MCP Server rodando e expondo sua tabela Customers. A camada de abstração de entidades significa que você pode criar aliases para nomes e colunas, limitar campos por papel, e controlar exatamente o que os agentes veem — sem expor detalhes internos do esquema.

A história de segurança é sólida

É aqui que a maturidade do Data API builder compensa:

RBAC em cada camada — cada entidade define quais papéis podem ler, criar, atualizar ou deletar, e quais campos são visíveis
Integração com Azure Key Vault — strings de conexão e segredos gerenciados com segurança
Microsoft Entra + OAuth personalizado — autenticação de nível de produção
Content Security Policy — agentes interagem através de um contrato controlado, não SQL cru

A abstração de esquema é particularmente importante. Seus nomes internos de tabelas e colunas nunca são expostos ao agente. Você define entidades, aliases e descrições que fazem sentido para a interação com IA — não seu diagrama ERD do banco de dados.

Multi-banco e multi-protocolo

O SQL MCP Server suporta Microsoft SQL, PostgreSQL, Azure Cosmos DB e MySQL. E como é uma funcionalidade do DAB, você obtém endpoints REST, GraphQL e MCP simultaneamente da mesma configuração. Mesmas definições de entidades, mesmas regras RBAC, mesma segurança — nos três protocolos.

A auto-configuração no DAB 2.0 pode até inspecionar seu banco de dados e construir a configuração dinamicamente, se você estiver confortável com menos abstração para prototipagem rápida.

Minha opinião

É assim que o acesso empresarial a bancos de dados para agentes de IA deveria funcionar. Não “ei LLM, escreve SQL pra mim e YOLO contra produção.” Em vez disso: uma camada de entidades bem definida, geração determinística de consultas, RBAC em cada etapa, cache, monitoramento e telemetria. É chato da melhor maneira possível.

Para desenvolvedores .NET, a história de integração é limpa — DAB é uma ferramenta .NET, o MCP Server roda como contêiner, e funciona com Azure SQL, que a maioria de nós já está usando. Se você está construindo agentes de IA que precisam de acesso a dados, comece aqui.

Finalizando

SQL MCP Server é gratuito, open-source e roda em qualquer lugar. É a abordagem prescritiva da Microsoft para dar aos agentes de IA acesso seguro a bancos de dados. Confira o post completo e a documentação para começar.

azd agora permite executar e depurar agentes IA localmente — O que mudou em março 2026

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Sete versões em um mês. Foi isso que o time do Azure Developer CLI (azd) publicou em março 2026, e a funcionalidade principal é a que eu estava esperando: um loop local de execução e depuração para agentes IA.

PC Chan publicou o resumo completo, e embora haja muito conteúdo, deixe-me filtrar o que realmente importa para desenvolvedores .NET construindo apps com IA.

Executar e depurar agentes IA sem fazer deploy

Esta é a grande novidade. A nova extensão azure.ai.agents adiciona comandos que te dão uma experiência de loop interno adequada para agentes IA:

azd ai agent run — inicia seu agente localmente
azd ai agent invoke — envia mensagens (local ou em produção)
azd ai agent show — mostra status e saúde do container
azd ai agent monitor — transmite logs do container em tempo real

Antes, testar um agente IA significava fazer deploy no Microsoft Foundry toda vez que você fazia uma mudança. Agora você pode iterar localmente, testar o comportamento do seu agente, e só fazer deploy quando estiver pronto.

GitHub Copilot configura seu projeto azd

azd init agora oferece uma opção “Set up with GitHub Copilot (Preview)”. Em vez de responder prompts manualmente, um agente Copilot gera a configuração para você. Quando um comando falha, azd oferece troubleshooting assistido por IA — tudo sem sair do terminal.

Container App Jobs e melhorias de deploy

Container App Jobs: azd agora faz deploy de Microsoft.App/jobs pela config existente host: containerapp.
Timeouts configuráveis: Nova flag --timeout no azd deploy e campo deployTimeout no azure.yaml.
Fallback de build remoto: Quando o build ACR falha, azd faz fallback automático para Docker/Podman local.
Validação preflight local: Parâmetros Bicep são validados localmente antes do deploy.

Melhorias de DX

Detecção automática de pnpm/yarn para projetos JS/TS
Suporte a pyproject.toml para Python
Diretórios de templates locais — azd init --template aceita caminhos do sistema de arquivos
Melhores mensagens de erro no modo --no-prompt
Variáveis de ambiente de build injetadas em todos os subprocessos de build (.NET, Node.js, Java, Python)

Conclusão

O loop de depuração local de agentes IA é a estrela desta versão, mas o acúmulo de melhorias de deploy e refinamento de DX faz o azd parecer mais maduro do que nunca. Se você está fazendo deploy de apps .NET no Azure — especialmente agentes IA — esta atualização vale a pena.

Confira as notas completas da versão para todos os detalhes.

KubeCon Europe 2026: O que os desenvolvedores .NET realmente precisam saber

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

Este post foi traduzido automaticamente. Para a versão original, clique aqui.

Sabe aquela sensação quando cai um post gigante de anúncios e você fica scrollando pensando “legal, mas o que isso muda pra mim na prática”? É assim que me sinto toda temporada de KubeCon.

A Microsoft acabou de publicar o resumo completo da KubeCon Europe 2026 — escrito pelo próprio Brendan Burns — e sinceramente? Tem conteúdo real aqui. Não são apenas checklists de features, mas melhorias operacionais que mudam como você gerencia as coisas em produção.

Deixa eu explicar o que realmente importa para nós desenvolvedores .NET.

mTLS sem o imposto do service mesh

A coisa com service meshes é: todo mundo quer as garantias de segurança, ninguém quer a carga operacional. O AKS finalmente está fechando essa lacuna.

Azure Kubernetes Application Network te dá TLS mútuo, autorização com reconhecimento de aplicação e telemetria de tráfego — sem implantar um mesh pesado com sidecars. Combinado com Cilium mTLS no Advanced Container Networking Services, você tem comunicação criptografada pod-a-pod usando certificados X.509 e SPIRE para gerenciamento de identidade.

Na prática: suas APIs ASP.NET Core conversando com workers em background, seus serviços gRPC chamando uns aos outros — tudo criptografado e verificado por identidade no nível de rede, sem nenhuma alteração no código. Isso é enorme.

Para times migrando do ingress-nginx, também tem Application Routing com Meshless Istio com suporte completo à Kubernetes Gateway API. Sem sidecars. Baseado em padrões. E lançaram ferramentas ingress2gateway para migração incremental.

Observabilidade de GPU que não é secundária

Se você está rodando inferência de IA junto com seus serviços .NET (e sejamos honestos, quem não está começando?), provavelmente já se deparou com o ponto cego do monitoramento de GPU. Tinha dashboards ótimos de CPU/memória e depois… nada para GPUs sem configuração manual de exportadores.

AKS agora expõe métricas de GPU nativamente no Prometheus e Grafana gerenciados. Mesmo stack, mesmos dashboards, mesmo pipeline de alertas. Sem exportadores custom, sem agentes de terceiros.

No lado de rede, adicionaram visibilidade por fluxo para tráfego HTTP, gRPC e Kafka com uma experiência one-click no Azure Monitor. IPs, portas, workloads, direção do fluxo, decisões de policy — tudo em dashboards integrados.

E aqui vem a que me fez olhar duas vezes: agentic container networking adiciona uma UI web onde você pode fazer perguntas em linguagem natural sobre o estado de rede do seu cluster. “Por que o pod X não alcança o serviço Y?” → diagnósticos read-only a partir de telemetria ao vivo. Genuinamente útil às 2 da manhã.

Networking cross-cluster que não exige doutorado

Multi-cluster em Kubernetes historicamente foi uma experiência de “traga sua própria cola de rede”. Azure Kubernetes Fleet Manager agora entrega networking cross-cluster através de Cilium cluster mesh gerenciado:

Conectividade unificada entre clusters AKS
Registro global de serviços para descoberta cross-cluster
Configuração gerenciada centralmente, não repetida por cluster

Se você roda microsserviços .NET em várias regiões para resiliência ou compliance, isso substitui muita cola custom frágil. O Serviço A no West Europe pode descobrir e chamar o Serviço B no East US através do mesh, com políticas de roteamento e segurança consistentes.

Upgrades que não exigem coragem

Sejamos honestos — upgrades de Kubernetes em produção são estressantes. “Atualizar e torcer” tem sido a estratégia de facto para muitos times, e é a razão principal pela qual clusters ficam defasados nas versões.

Duas novas capacidades mudam isso:

Blue-green agent pool upgrades criam um pool de nós paralelo com a nova configuração. Valide o comportamento, mova tráfego gradualmente e mantenha um caminho limpo de rollback. Nada mais de mutações in-place em nós de produção.

Agent pool rollback permite reverter um pool de nós para a versão anterior do Kubernetes e imagem de nó quando um upgrade dá errado — sem reconstruir o cluster.

Juntos, finalmente dão aos operadores controle real sobre o ciclo de vida de upgrades. Para times .NET, isso importa porque a velocidade da plataforma controla diretamente quão rápido você pode adotar novos runtimes, patches de segurança e capacidades de rede.

Workloads de IA se tornam cidadãos de primeira classe no Kubernetes

O trabalho upstream em open-source é igualmente importante. Dynamic Resource Allocation (DRA) acabou de chegar em GA no Kubernetes 1.36, tornando o scheduling de GPU uma feature de primeira classe ao invés de um workaround.

Alguns projetos que vale a pena acompanhar:

Projeto	O que faz
AI Runway	API Kubernetes comum para inferência — deploy de modelos sem saber K8s, com descoberta HuggingFace e estimativas de custo
HolmesGPT	Troubleshooting agêntico para cloud-native — agora projeto CNCF Sandbox
Dalec	Builds declarativos de imagens de container com geração de SBOM — menos CVEs na fase de build

A direção é clara: sua API .NET, sua camada de orquestração com Semantic Kernel e seus workloads de inferência deveriam todos rodar em um modelo de plataforma consistente. Estamos chegando lá.

Por onde eu começaria esta semana

Se você está avaliando essas mudanças para seu time, aqui vai minha lista honesta de prioridades:

Observabilidade primeiro — habilite métricas de GPU e logs de fluxo de rede em um cluster não-prod. Veja o que você andou perdendo.
Teste blue-green upgrades — experimente o workflow de rollback antes do seu próximo upgrade de cluster em produção. Construa confiança no processo.
Pilote networking com identidade — escolha um caminho de serviço interno e habilite mTLS com Cilium. Meça o overhead (spoiler: é mínimo).
Avalie Fleet Manager — se você roda mais de dois clusters, networking cross-cluster se paga sozinho em redução de cola custom.

Experimentos pequenos, feedback rápido. Essa é sempre a jogada.

Finalizando

Anúncios de KubeCon podem ser avassaladores, mas essa leva realmente move a agulha para times .NET no AKS. Melhor segurança de rede sem overhead de mesh, observabilidade real de GPU, upgrades mais seguros e fundações mais fortes para infraestrutura de IA.

Se você já está no AKS, é um ótimo momento para reforçar sua baseline operacional. E se está planejando mover workloads .NET para Kubernetes — a plataforma ficou significativamente mais pronta para produção.

SQL MCP Server, Copilot no SSMS e um Database Hub com Agentes de IA: O que realmente importa da SQLCon 2026

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

A Microsoft acabou de abrir a SQLCon 2026 junto com a FabCon em Atlanta, e tem muita coisa para desempacotar. O anúncio original cobre tudo, desde planos de economia até funcionalidades de conformidade enterprise. Eu vou pular os slides de preços enterprise e focar nas partes que importam se você é um desenvolvedor construindo coisas com Azure SQL e IA.

SQL MCP Server está em public preview

Essa é a manchete principal pra mim. O Azure SQL Database Hyperscale agora tem um SQL MCP Server em public preview que permite conectar seus dados SQL de forma segura a agentes de IA e Copilots usando o Model Context Protocol.

Se você tem acompanhado a onda do MCP — e honestamente, é difícil não perceber agora — isso é uma grande novidade. Em vez de construir pipelines de dados customizados para alimentar seus agentes de IA com contexto do seu banco de dados, você ganha um protocolo padronizado para expor dados SQL diretamente. Seus agentes podem consultar, raciocinar e agir sobre informações do banco de dados em tempo real.

Para quem está construindo agentes de IA com Semantic Kernel ou o Microsoft Agent Framework, isso abre um caminho de integração limpo. Seu agente precisa verificar o estoque? Buscar um registro de cliente? Validar um pedido? O MCP dá a ele uma forma estruturada de fazer isso sem você escrever código de busca de dados sob medida para cada cenário.

GitHub Copilot no SSMS 22 agora é GA

Se você passa algum tempo no SQL Server Management Studio — e sejamos honestos, a maioria de nós ainda passa — o GitHub Copilot agora está disponível de forma geral no SSMS 22. A mesma experiência Copilot que você já usa no VS Code e Visual Studio, mas para T-SQL.

O valor prático aqui é direto: assistência por chat para escrever queries, refatorar stored procedures, resolver problemas de performance e lidar com tarefas administrativas. Nada revolucionário no conceito, mas ter isso dentro do SSMS significa que você não precisa trocar de contexto para outro editor só para ter ajuda de IA no seu trabalho com banco de dados.

Índices vetoriais receberam um upgrade sério

O Azure SQL Database agora tem índices vetoriais mais rápidos e mais robustos com suporte completo para insert, update e delete. Isso significa que seus dados vetoriais ficam atualizados em tempo real — sem necessidade de reindexação em lote.

Aqui está o que há de novo:

Quantização para tamanhos de índice menores sem perder muita precisão
Filtragem iterativa para resultados mais precisos
Integração mais próxima com o otimizador de queries para performance previsível

Se você está fazendo Retrieval-Augmented Generation (RAG) com Azure SQL como vector store, essas melhorias são diretamente úteis. Você pode manter seus vetores junto com seus dados relacionais no mesmo banco de dados, o que simplifica significativamente sua arquitetura comparado a rodar um banco de dados vetorial separado.

As mesmas melhorias vetoriais também estão disponíveis no SQL Database no Fabric, já que ambos rodam no mesmo motor SQL por baixo dos panos.

Database Hub no Fabric: gestão agêntica

Esse ponto é mais voltado para o futuro, mas é interessante. A Microsoft anunciou o Database Hub no Microsoft Fabric (acesso antecipado), que te dá uma visão unificada sobre Azure SQL, Cosmos DB, PostgreSQL, MySQL e SQL Server via Arc.

O ângulo interessante não é só a visão unificada — é a abordagem agêntica de gestão. Agentes de IA monitoram continuamente seu parque de bancos de dados, mostram o que mudou, explicam por que isso importa e sugerem o que fazer em seguida. É um modelo human-in-the-loop onde o agente faz o trabalho pesado e você toma as decisões.

Para equipes gerenciando mais do que um punhado de bancos de dados, isso poderia realmente reduzir o ruído operacional. Em vez de pular entre portais e verificar métricas manualmente, o agente traz o sinal até você.

O que isso significa para desenvolvedores .NET

O fio que conecta todos esses anúncios é claro: a Microsoft está incorporando agentes de IA em cada camada da stack de banco de dados. Não como um truque, mas como uma camada prática de ferramentas.

Se você está construindo apps .NET com Azure SQL, aqui está o que eu faria de fato:

Experimente o SQL MCP Server se você está construindo agentes de IA. É a forma mais limpa de dar aos seus agentes acesso ao banco de dados sem encanamento customizado.
Ative o Copilot no SSMS se você ainda não fez — ganho de produtividade gratuito para o trabalho diário com SQL.
Dê uma olhada nos índices vetoriais se você está fazendo RAG e atualmente rodando um vector store separado. Consolidar no Azure SQL significa um serviço a menos para gerenciar.

Concluindo

O anúncio completo tem mais — planos de economia, assistentes de migração, funcionalidades de conformidade — mas a história para desenvolvedores está no MCP Server, nas melhorias vetoriais e na camada de gestão agêntica. São essas as peças que mudam como você constrói, não apenas como você faz orçamento.

Confira o anúncio completo do Shireesh Thota para o panorama completo, e inscreva-se para o acesso antecipado ao Database Hub se quiser experimentar a nova experiência de gestão.

Azure DevOps MCP Server chega ao Microsoft Foundry: O que isso significa para seus agentes de IA

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

MCP (Model Context Protocol) está tendo seu momento. Se você tem acompanhado o ecossistema de agentes de IA, provavelmente notou servidores MCP surgindo por todo lado — dando aos agentes a capacidade de interagir com ferramentas e serviços externos através de um protocolo padronizado.

Agora o Azure DevOps MCP Server está disponível no Microsoft Foundry, e essa é uma daquelas integrações que faz você pensar nas possibilidades práticas.

O que está realmente acontecendo aqui

A Microsoft já lançou o Azure DevOps MCP Server como public preview — esse é o servidor MCP em si. A novidade é a integração com o Foundry. Agora você pode adicionar o Azure DevOps MCP Server aos seus agentes Foundry diretamente do catálogo de ferramentas.

Para quem ainda não conhece o Foundry: é a plataforma unificada da Microsoft para construir e gerenciar aplicações e agentes alimentados por IA em escala. Acesso a modelos, orquestração, avaliação, deploy — tudo em um só lugar.

Configurando

A configuração é surpreendentemente simples:

No seu agente Foundry, vá para Add Tools > Catalog
Busque “Azure DevOps”
Selecione o Azure DevOps MCP Server (preview) e clique em Create
Insira o nome da sua organização e conecte

Isso é tudo. Seu agente agora tem acesso às ferramentas do Azure DevOps.

Controlando o que seu agente pode acessar

Essa é a parte que eu aprecio: você não está preso a uma abordagem de tudo-ou-nada. Você pode especificar quais ferramentas estão disponíveis para seu agente. Então se você quer que ele apenas leia work items mas não toque em pipelines, pode configurar isso. Princípio do menor privilégio, aplicado aos seus agentes de IA.

Isso importa para cenários enterprise onde você não quer que um agente acidentalmente dispare um pipeline de deploy porque alguém pediu para ele “ajudar com o release.”

Por que isso é interessante para equipes .NET

Pense no que isso possibilita na prática:

Assistentes de planejamento de sprint — agentes que podem buscar work items, analisar dados de velocidade e sugerir capacidade de sprint
Bots de code review — agentes que entendem o contexto do seu PR porque podem realmente ler seus repos e work items vinculados
Resposta a incidentes — agentes que podem criar work items, consultar deploys recentes e correlacionar bugs com mudanças recentes
Onboarding de desenvolvedores — “No que devo trabalhar?” recebe uma resposta real baseada em dados reais do projeto

Para equipes .NET que já usam Azure DevOps para seus pipelines de CI/CD e gerenciamento de projetos, ter um agente de IA que pode interagir diretamente com esses sistemas é um passo significativo em direção à automação útil.

O panorama maior do MCP

Isso faz parte de uma tendência mais ampla: servidores MCP estão se tornando a forma padrão como agentes de IA interagem com o mundo exterior. Estamos vendo para GitHub, Azure DevOps, bancos de dados, APIs SaaS — e o Foundry está se tornando o hub onde todas essas conexões se encontram.

Se você está construindo agentes no ecossistema .NET, vale a pena prestar atenção ao MCP. O protocolo é padronizado, as ferramentas estão amadurecendo, e a integração com Foundry torna acessível sem precisar configurar manualmente conexões de servidor.

Para finalizar

O Azure DevOps MCP Server no Foundry está em preview, então espere que ele evolua. Mas o workflow principal é sólido: conectar, configurar acesso às ferramentas e deixar seus agentes trabalharem com seus dados de DevOps. Se você já está no ecossistema Foundry, está a poucos cliques. Experimente e veja quais workflows você consegue construir.

Confira o anúncio completo para a configuração passo a passo e mais detalhes.

Do laptop à produção: implantando agentes de IA no Microsoft Foundry com dois comandos

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Você conhece aquela lacuna entre “funciona na minha máquina” e “está implantado e servindo tráfego”? Para agentes de IA, essa lacuna tem sido dolorosamente ampla. Você precisa provisionar recursos, implantar modelos, configurar identidade, montar monitoramento — e isso é antes de qualquer pessoa poder realmente chamar seu agente.

O Azure Developer CLI acabou de transformar isso em uma questão de dois comandos.

O novo fluxo de trabalho `azd ai agent`

Deixe-me mostrar como isso realmente se parece. Você tem um projeto de agente de IA — digamos um agente concierge de hotel. Funciona localmente. Você quer ele rodando no Microsoft Foundry.

azd ai agent init
azd up

Isso é tudo. Dois comandos. azd ai agent init gera a infraestrutura como código no seu repositório, e azd up provisiona tudo no Azure e publica seu agente. Você recebe um link direto para seu agente no portal Foundry.

O que acontece por baixo dos panos

O comando init gera templates Bicep reais e inspecionáveis no seu repositório:

Um Foundry Resource (contêiner de nível superior)
Um Foundry Project (onde seu agente vive)
Configuração de implantação de modelo (GPT-4o, etc.)
Identidade gerenciada com atribuições de papéis RBAC apropriadas
azure.yaml para o mapa de serviços
agent.yaml com metadados do agente e variáveis de ambiente

O ponto chave: tudo isso é seu. É Bicep versionado no seu repositório. Você pode inspecioná-lo, customizá-lo e fazer commit junto com o código do seu agente. Sem caixas pretas mágicas.

O ciclo interno de desenvolvimento

O que eu realmente gosto é a história de desenvolvimento local. Quando você está iterando na lógica do agente, não quer reimplantar toda vez que muda um prompt:

azd ai agent run

Isso inicia seu agente localmente. Combine com azd ai agent invoke para enviar prompts de teste, e você tem um ciclo de feedback apertado. Editar código, reiniciar, invocar, repetir.

O comando invoke também é inteligente no roteamento — quando um agente local está rodando, ele aponta automaticamente para ele. Quando não está, vai para o endpoint remoto.

Monitoramento em tempo real

Esta é a funcionalidade que me convenceu. Uma vez que seu agente está implantado:

azd ai agent monitor --follow

Cada requisição e resposta fluindo pelo seu agente é transmitida para seu terminal em tempo real. Para depurar problemas em produção, isso é inestimável. Sem vasculhar log analytics, sem esperar métricas agregarem — você vê o que está acontecendo agora.

O conjunto completo de comandos

Aqui a referência rápida:

Comando	O que faz
`azd ai agent init`	Gera um projeto de agente Foundry com IaC
`azd up`	Provisiona recursos Azure e implanta o agente
`azd ai agent invoke`	Envia prompts ao agente remoto ou local
`azd ai agent run`	Executa o agente localmente para desenvolvimento
`azd ai agent monitor`	Transmite logs em tempo real do agente publicado
`azd ai agent show`	Verifica saúde e status do agente
`azd down`	Limpa todos os recursos Azure

Por que isso importa para desenvolvedores .NET

Embora o exemplo do anúncio seja baseado em Python, a história de infraestrutura é agnóstica a linguagem. Seu agente .NET recebe o mesmo scaffolding Bicep, a mesma configuração de identidade gerenciada, o mesmo pipeline de monitoramento. E se você já usa azd para suas apps .NET Aspire ou implantações Azure, isso se encaixa direto no seu fluxo de trabalho existente.

A lacuna de implantação para agentes de IA tem sido um dos maiores pontos de fricção no ecossistema. Ir de um protótipo funcional a um endpoint de produção com identidade, rede e monitoramento adequados não deveria exigir uma semana de trabalho DevOps. Agora requer dois comandos e alguns minutos.

Para finalizar

azd ai agent está disponível agora. Se você tem adiado a implantação dos seus agentes de IA porque a configuração de infraestrutura parecia trabalho demais, experimente. Confira o tutorial completo para o passo a passo completo incluindo integração de app de chat frontend.

Foundry Agent Service está GA: O que realmente importa para construtores de agentes .NET

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Vamos ser honestos — construir um protótipo de agente IA é a parte fácil. A parte difícil é tudo o que vem depois: colocá-lo em produção com isolamento de rede adequado, executar avaliações que realmente signifiquem algo, lidar com requisitos de conformidade e não quebrar nada às 2 da manhã.

O Foundry Agent Service acabou de chegar ao GA, e esta versão está focada como um laser nessa lacuna do “tudo que vem depois”.

Construído sobre a Responses API

A manchete: o Foundry Agent Service de próxima geração é construído sobre a OpenAI Responses API. Se você já está construindo com esse protocolo, migrar para o Foundry requer mudanças mínimas de código. O que você ganha: segurança empresarial, rede privada, RBAC Entra, rastreamento completo e avaliação — sobre sua lógica de agente existente.

A arquitetura é intencionalmente aberta. Você não está preso a um provedor de modelo ou um framework de orquestração. Use DeepSeek para planejamento, OpenAI para geração, LangGraph para orquestração — o runtime cuida da camada de consistência.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

Rede privada: o bloqueador empresarial removido

Esta é a funcionalidade que desbloqueia a adoção empresarial. Foundry agora suporta rede privada completa de ponta a ponta com BYO VNet:

Sem egress público — o tráfego do agente nunca toca a internet pública
Injeção de contêiners/sub-redes na sua rede para comunicação local
Conectividade de ferramentas incluída — servidores MCP, Azure AI Search, agentes de dados Fabric, todos operam sobre caminhos privados

Esse último ponto é crítico. Não são apenas as chamadas de inferência que ficam privadas — cada invocação de ferramenta e chamada de recuperação também fica dentro do perímetro da sua rede. Para equipes operando sob políticas de classificação de dados que proíbem roteamento externo, isso era o que faltava.

Autenticação MCP feita direito

Conexões de servidores MCP agora suportam o espectro completo de padrões de autenticação:

Método de auth	Quando usar
Baseado em chave	Acesso compartilhado simples para ferramentas internas da organização
Entra Agent Identity	Serviço a serviço; o agente se autentica como ele mesmo
Entra Managed Identity	Isolamento por projeto; sem gerenciamento de credenciais
OAuth Identity Passthrough	Acesso delegado por usuário; agente age em nome dos usuários

OAuth Identity Passthrough é o interessante. Quando usuários precisam dar a um agente acesso aos seus dados pessoais — seu OneDrive, sua organização Salesforce, uma API SaaS com escopo por usuário — o agente age em seu nome com fluxos OAuth padrão. Sem identidade de sistema compartilhada fingindo ser todos.

Voice Live: voz a voz sem a encanação

Adicionar voz a um agente costumava significar juntar STT, LLM e TTS — três serviços, três saltos de latência, três superfícies de faturamento, tudo sincronizado à mão. Voice Live colapsa isso em uma única API gerenciada com:

Detecção semântica de atividade de voz e fim de turno (entende significado, não apenas silêncio)
Supressão de ruído e cancelamento de eco do lado do servidor
Suporte a barge-in (usuários podem interromper no meio da resposta)

Interações de voz passam pelo mesmo runtime de agente que o texto. Mesmos avaliadores, mesmos traces, mesma visibilidade de custos. Para suporte ao cliente, serviço de campo ou cenários de acessibilidade, isso substitui o que antes requeria um pipeline de áudio personalizado.

Avaliações: de checkbox para monitoramento contínuo

Aqui é onde o Foundry fica sério sobre qualidade em produção. O sistema de avaliação agora tem três camadas:

Avaliadores prontos para uso — coerência, relevância, fundamentação, qualidade de recuperação, segurança. Conecte a um dataset ou tráfego ao vivo e obtenha pontuações.
Avaliadores personalizados — codifique sua própria lógica de negócio, padrões de tom e regras de conformidade específicas do domínio.
Avaliação contínua — Foundry amostra tráfego de produção ao vivo, executa sua suíte de avaliadores e exibe resultados em dashboards. Configure alertas do Azure Monitor para quando a fundamentação cai ou limites de segurança são violados.

Tudo é publicado no Azure Monitor Application Insights. Qualidade do agente, saúde da infraestrutura, custo e telemetria da aplicação — tudo em um só lugar.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Seis novas regiões para agentes hospedados

Agentes hospedados agora estão disponíveis em East US, North Central US, Sweden Central, Southeast Asia, Japan East e mais. Isso importa para requisitos de residência de dados e para comprimir latência quando seu agente roda perto de suas fontes de dados.

Por que isso importa para desenvolvedores .NET

Embora os exemplos de código no anúncio de GA sejam Python-first, a infraestrutura subjacente é agnóstica a linguagem — e o SDK .NET para azure-ai-projects segue os mesmos padrões. A Responses API, o framework de avaliação, a rede privada, a autenticação MCP — tudo isso está disponível a partir do .NET.

Se você tem esperado os agentes IA passarem de “demo legal” para “consigo realmente entregar isso no trabalho”, esta versão GA é o sinal. Rede privada, autenticação adequada, avaliação contínua e monitoramento de produção são as peças que faltavam.

Para finalizar

Foundry Agent Service está disponível agora. Instale o SDK, abra o portal e comece a construir. O guia de início rápido leva você de zero a um agente rodando em minutos.

Para o mergulho técnico completo com todos os exemplos de código, confira o anúncio de GA.

Respostas em segundo plano no Microsoft Agent Framework: chega de ansiedade com timeouts

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Se você já construiu algo com modelos de raciocínio como o3 ou GPT-5.2, conhece a dor. Seu agente começa a pensar numa tarefa complexa, o cliente fica esperando, e em algum ponto entre “tá tudo bem” e “será que travou?” sua conexão expira por timeout. Todo aquele trabalho? Perdido.

O Microsoft Agent Framework acabou de lançar respostas em segundo plano — e honestamente, essa é uma daquelas funcionalidades que deveria ter existido desde o primeiro dia.

O problema com chamadas bloqueantes

Num padrão tradicional de requisição-resposta, seu cliente bloqueia até o agente terminar. Funciona bem para tarefas rápidas. Mas quando você pede a um modelo de raciocínio que faça pesquisa profunda, análise em múltiplas etapas, ou gere um relatório de 20 páginas? São minutos de tempo real. Durante essa janela:

Conexões HTTP podem expirar
Quedas de rede matam toda a operação
Seu usuário fica olhando um spinner se perguntando se algo está acontecendo

Respostas em segundo plano invertem isso completamente.

Como os tokens de continuação funcionam

Em vez de bloquear, você dispara a tarefa do agente e recebe um token de continuação. Pense nisso como um ticket de retirada numa oficina — você não fica parado no balcão esperando, volta quando está pronto.

O fluxo é direto:

Envie sua requisição com AllowBackgroundResponses = true
Se o agente suporta processamento em segundo plano, você recebe um token de continuação
Consulte no seu ritmo até o token retornar null — isso significa que o resultado está pronto

Aqui está a versão .NET:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Consultar até completar
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

Se o agente completa imediatamente (tarefas simples, modelos que não precisam de processamento em segundo plano), nenhum token de continuação é retornado. Seu código simplesmente funciona — sem tratamento especial necessário.

Streaming com retomada: a verdadeira mágica

Polling é bom para cenários de disparar e esquecer, mas e quando você quer progresso em tempo real? Respostas em segundo plano também suportam streaming com retomada embutida.

Cada atualização do stream carrega seu próprio token de continuação. Se sua conexão cair no meio do stream, você retoma exatamente de onde parou:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Simular uma interrupção de rede
}

// Retomar exatamente de onde paramos
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

O agente continua processando no servidor independentemente do que aconteça com seu cliente. Isso é tolerância a falhas embutida sem que você escreva lógica de retry ou circuit breakers.

Quando realmente usar isso

Nem toda chamada ao agente precisa de respostas em segundo plano. Para completações rápidas, você está adicionando complexidade sem razão. Mas aqui é onde elas brilham:

Tarefas de raciocínio complexo — análise em múltiplas etapas, pesquisa profunda, qualquer coisa que faça um modelo de raciocínio realmente pensar
Geração de conteúdo longo — relatórios detalhados, documentos de múltiplas partes, análises extensas
Redes pouco confiáveis — clientes móveis, deployments no edge, VPNs corporativas instáveis
Padrões UX assíncronos — envie uma tarefa, vá fazer outra coisa, volte para os resultados

Para nós desenvolvedores .NET construindo apps empresariais, esse último é particularmente interessante. Pense numa app Blazor onde um usuário solicita um relatório complexo — você dispara a tarefa do agente, mostra um indicador de progresso, e os deixa continuar trabalhando. Sem ginástica de WebSocket, sem infraestrutura de filas personalizada, apenas um token e um loop de polling.

Para finalizar

Respostas em segundo plano estão disponíveis agora tanto em .NET quanto em Python através do Microsoft Agent Framework. Se você está construindo agentes que fazem algo mais complexo que simples Q&A, vale a pena adicionar isso ao seu toolkit. O padrão de token de continuação mantém as coisas simples enquanto resolve um problema de produção muito real.

Confira a documentação completa para a referência completa da API e mais exemplos.

Azure | The .NET Blog

Microsoft Foundry Abril 2026: Foundry Local GA, GPT-5.5, CodeAct com Hyperlight

Foundry Local está Geralmente Disponível

GPT-5.5

Rastreamento do Agent Framework no Foundry

CodeAct com Hyperlight (Alpha)

Painel de Monitoramento de Agentes (Preview)

Avaliadores Personalizados de Avaliação Contínua (Preview)

Inventário de Agentes no Plano de Controle

Seu Agente MAF Local Acabou de Ganhar um Lar em Produção

O Que o Foundry Hosted Agents Realmente Faz

A Diferença no Código É Mínima

Dois Protocolos, Um Agente

O Fluxo de Implantação com azd

Conclusão

Foundry Local 1.1: Transcrição em Tempo Real, Embeddings e a API de Respostas

Transcrição de Áudio em Directo

Embeddings de Texto

API de Respostas

Melhorias no Tamanho do Pacote

Por Que Importa

Cosmos DB Shell Está em Pré-visualização Pública — E Tem um Servidor MCP Integrado

O Que o Torna Diferente de Outras CLIs de Banco de Dados

A Base de Código Aberto Importa

Três Cenários Que se Tornam Mais Fáceis

Para Começar

O Seu Agente de IA Tem um Problema de Identidade (E Aqui Está o Template que o Resolve)

O Problema Central: Autenticação ≠ Autorização

Como Funciona a Cadeia de Tokens

O que o Template Implanta

O Princípio de Design que Vale a Pena Adotar

Conclusão

Endpoints Privados, VNets, NSGs — Aspire Gerencia a Rede Agora

Os Blocos de Construção

Descrevendo no seu AppHost

Por Que Isso Importa para Aplicações Reais

Conclusão

Aspire 13.3: Suporte ao Kubernetes, Logs do Navegador e a Skill Aspireify

Aspireify: Integração Assistida por Agente

Implantação de Kubernetes e AKS de Primeira Classe

Logs do Navegador no Dashboard

Resultados de Comandos Estruturados

Conclusão

SDD Conference 2026

Tópicos

Palestrantes

Ingressos e informações

Removendo o Trabalho Repetitivo de Migração com Agentic Platform Engineering

A entrada: contoso-migration

Passo 1: Validação e autenticação

Passo 2: Extração de intenção

Passo 3: Mapeamento de serviços

Passo 4: Agente crítico

Passo 5: Saída gerada

Comparação de postura de segurança

O que o diferencia de um conversor de sintaxe

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

O que é o SQL MCP Server?

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

Autenticação Sem Chaves de API Compartilhadas

Deploy no App Service

Por que Isso Importa para Desenvolvedores .NET

Conclusão

SQL Server 2025 como Banco de Dados Pronto para Agentes: Segurança, Backup e MCP em Um Motor

Um Modelo de Segurança para Todos os Modelos de Dados

Backup Unificado = Recuperação Atômica

Integração MCP: Agentes Sem Middleware

Azure SDK Abril 2026: AI Foundry 2.0 e o Que Desenvolvedores .NET Devem Saber

Azure.AI.Projects 2.0.0 — Breaking Changes que Fazem Sentido

Cosmos DB Java: Correção Crítica de Segurança (RCE)

Novas Bibliotecas de Provisioning para .NET

GPT-5.5 Chegou ao Azure Foundry — O que Desenvolvedores .NET Precisam Saber

A progressão do GPT-5

O que realmente mudou

Preços

Por que o Foundry importa

O Azure MCP Server Agora é um .mcpb — Instale-o sem Nenhum Runtime

O que é um MCP Bundle?

Como instalar

O que você pode fazer

O Fluxo de Implantação com `azd`