Ai | The .NET Blog

NL2SQL é a Injeção SQL da Era Agêntica

Emiliano Montesdeoca — Wed, 03 Jun 2026 00:00:00 +0000

Há uma versão do argumento NL2SQL que soa perfeita: os usuários fazem perguntas em linguagem natural, os agentes geram SQL, os dados voltam. Menos telas, menos consultas, menos código. Simples.

Então você pensa por mais cinco minutos.

Os Problemas sobre os quais Ninguém Fala na Demo

Os esquemas não foram projetados para explicar as coisas. Nomes de tabelas crípticos, nomes de colunas inconsistentes, relacionamentos tecnicamente válidos que são semanticamente inválidos sem predicados adicionais — isso é normal para bancos de dados empresariais. Não são bugs, são simplesmente a história acumulada das mudanças de negócio. Mas quando você pede a um modelo que infira intenção de um esquema que não foi projetado para comunicar intenção, o modelo tentará de qualquer forma. Não desistirá. Gerará sua melhor consulta possível e retornará resultados com confiança.

Os modelos não são determinísticos. Faça a mesma pergunta sobre o mesmo banco de dados duas vezes e você pode obter SQL diferente. O modelo está calculando probabilidades, e ligeiras variações no contexto geram saídas diferentes. Você não pode testar seu caminho para uma garantia de que o agente sempre gera a consulta correta.

A revisão do usuário não escala. “Apenas revise cada consulta antes da execução” soa seguro. Mas assume que os usuários são especialistas tanto no modelo de dados quanto em SQL — exatamente as pessoas que não precisavam da interface de linguagem natural. Também introduz sobrecarga cognitiva e uma nova classe de viés de confirmação, onde usuários sobrecarregados pela complexidade da consulta aprovam consultas inválidas em vez de investigá-las.

E então há injeção. No desenvolvimento SQL tradicional, a parametrização resolveu a injeção porque a entrada do usuário preenchia parâmetros, não a estrutura SQL. Com NL2SQL, o modelo gera o SQL em si. O prompt, o contexto do esquema, o histórico de conversação e os dados recuperados influenciam o que é executado. Se alguém elabora um prompt que muda o que o modelo gera, isso é injeção — não no nível do parâmetro, mas no nível de geração de consultas. E ao contrário de eliminar uma tabela (óbvio, recuperável), a injeção NL2SQL produz consultas que retornam resultados incorretos sem nenhum erro visível. Decisões de negócio são tomadas com dados errados.

O que o SQL MCP Server Realmente Resolve

É aqui que o artigo faz seu ponto prático mais útil. Em vez de dar a um agente acesso arbitrário ao esquema e esperar o melhor, o SQL MCP Server expõe uma superfície de API curada construída sobre o Data API builder.

A diferença importa: o agente não gera SQL. Ele chama endpoints nomeados que retornam formas de resultado predefinidas. O SQL é escrito uma vez, por um desenvolvedor, e é determinístico. O não-determinismo do agente é limitado a escolher qual endpoint chamar, não a construir consultas arbitrárias.

Isso é análogo ao que a parametrização fez para a injeção SQL no modelo de aplicativo tradicional — você remove a capacidade de construir consultas arbitrárias a partir de entrada não confiável.

A Pergunta Certa

O artigo não diz “nunca use NL2SQL.” Ele diz: seja deliberado sobre onde você o aplica e o que você expõe. Para análise exploratória em um ambiente controlado, com um esquema limitado e acesso somente leitura, NL2SQL pode estar bem. Para sistemas de produção onde decisões de negócio dependem dos resultados, uma camada de API curada é significativamente mais segura.

Honestidade: alguns problemas são genuinamente melhor resolvidos com consultas estruturadas atrás de endpoints nomeados do que com linguagem natural para SQL. O SQL MCP Server te dá essa opção sem abandonar completamente a interface agêntica.

Post original: Considering NL2SQL? Should your database really be the prompt? How can SQL MCP Server help?

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

O Padrão Handoff: Quando Um Agente Não É Suficiente

Emiliano Montesdeoca — Mon, 01 Jun 2026 00:00:00 +0000

Em algum momento, todo sistema multi-agente supera um roteador simples. O primeiro sinal é geralmente quando um agente especialista precisa fazer uma pergunta de acompanhamento, ou percebe no meio do turno que outro agente deveria continuar. Um pipeline fixo falha aí. Um roteador de passagem única falha aí.

Exatamente para isso é que o padrão de orquestração Handoff no Microsoft Agent Framework foi projetado.

Como Handoff Funciona

O desenvolvedor declara um grafo: aqui estão os agentes, aqui estão as arestas entre eles. O framework faz o resto — sintetiza uma ferramenta handoff por aresta de saída e a injeta em cada agente. Quando um agente decide passar o controle, ele chama a ferramenta. O framework aplica a topologia.

Três coisas tornam isso diferente de simplesmente fazer com que os agentes se chamem:

Uma transcrição compartilhada — o agente receptor vê o histórico completo da conversa. Sem começar do zero.
Aplicação de topologia — um agente só pode fazer handoff para destinos declarados. Bugs de roteamento são detectados no momento de criação, não em produção.
Terminação natural — quando o agente ativo termina seu turno sem chamar uma ferramenta de handoff, o fluxo de trabalho cede ao usuário. Sem polling, sem condições de saída explícitas.

Um Exemplo Mínimo

Em .NET, construir um fluxo de trabalho handoff fica assim:

using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Workflows;

AIAgent triage = chatClient.AsAIAgent(
 instructions: "Route to the right specialist.",
 name: "Triage");

AIAgent billing = chatClient.AsAIAgent(
 instructions: "Handle billing questions.",
 name: "Billing");

AIAgent tech = chatClient.AsAIAgent(
 instructions: "Handle technical support.",
 name: "Tech");

var workflow = HandoffWorkflow.Create()
 .Add(triage, targets: [billing, tech])
 .Add(billing, targets: [triage])
 .Add(tech, targets: [triage, billing]);

Triagem pode enviar para qualquer especialista. Ambos os especialistas podem enviar de volta para triagem. O grafo é compatível com acíclico, mas suporta arestas de retorno quando você as precisa (“preciso de mais informações” → de volta à pesquisa).

Quando Usar Handoff (e Quando Não)

Handoff é uma boa escolha quando:

A propriedade pode mudar no meio da conversa — um agente pode perceber que é o especialista errado
Arestas de retorno importam — você pode precisar revisitar um passo anterior sem reiniciar
As decisões de roteamento são difusas — a decisão de fazer handoff é contextual e melhor tomada pelo modelo do que por predicados tipados

Não é a escolha certa quando:

Seu pipeline é fixo e sequencial — use o fluxo de trabalho Sequential para isso
Cada passo é independente — agentes compartilhando uma transcrição onde apenas um deles precisava dela é apenas ruído
Você precisa de garantias rígidas de processamento — o não-determinismo do roteamento orientado por modelo não é o que você quer

Arestas de Retorno e Human-in-the-Loop

Uma das formas mais interessantes que o Handoff permite são as arestas de retorno genuínas. Um agente pode decidir “não tenho informações suficientes” e rotear de volta para um passo de pesquisa, não com um loop codificado, mas porque o modelo decide que é a decisão certa.

As interações human-in-the-loop também se compõem naturalmente. Quando um especialista precisa de entrada do usuário, o fluxo de trabalho cede de volta ao usuário via o loop de turno padrão, coleta a resposta e retoma com contexto completo. O agente nunca perdeu a conversa.

Conclusão

Handoff é um desses padrões que parece simples, mas permite muito uma vez que você o internaliza: roteamento descentralizado, contexto compartilhado, topologia aplicada, terminação natural. É o próximo passo certo quando seus agentes começam a dizer “na verdade, alguém mais deveria lidar com isso.”

Leia o passo a passo completo no post original: A Tour of the Handoff Orchestration Pattern

Workflows Duráveis no Microsoft Agent Framework: De In-Memory ao Azure Functions

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

Um dos pontos problemáticos com os primeiros workflows de agentes de IA: eles são frágeis. Um workflow multi-etapas de longa duração vinculado a um único processo significa que reinicialização do processo = estado perdido. Para demos simples está bem. Para cargas de trabalho em produção não está.

O modelo de programação de workflows do Microsoft Agent Framework agora suporta execução durável, apoiada pelo framework Durable Task, com hospedagem no Azure Functions. Aqui está como o modelo de programação funciona e por que a história de durabilidade importa.

Os Blocos de Construção Fundamentais

Executors são a unidade fundamental de trabalho. Cada um é tipado — pega uma entrada específica e produz uma saída específica:

using Microsoft.Agents.AI.Workflows;

internal sealed class OrderLookup()
 : Executor<OrderCancelRequest, Order>("OrderLookup")
{
 public override async ValueTask<Order> HandleAsync(
 OrderCancelRequest message,
 IWorkflowContext context,
 CancellationToken cancellationToken = default)
 {
 // buscar o pedido, retorná-lo
 return new Order(Id: message.OrderId, ...);
 }
}

Workflows conectam executors em grafos direcionados usando um builder fluente. O framework cuida da execução, do fluxo de dados entre os passos e da propagação de erros.

Você pode modelar:

Cadeias sequenciais (passo A → passo B → passo C)
Fan-out/fan-in paralelo (executar agentes A, B, C em paralelo, agregar resultados)
Ramificação condicional
Aprovações de humano no ciclo (pausar workflow, esperar sinal externo)

O Runner In-Memory para Desenvolvimento Local

Começar é rápido:

dotnet add package Microsoft.Agents.AI
dotnet add package Microsoft.Agents.AI.Workflows

O pacote principal inclui um runner leve em processo. Sem dependências externas, sem banco de dados, sem recursos Azure. Funciona muito bem para desenvolvimento local e testes unitários.

Adicionando Durabilidade com Durable Task

Quando um workflow precisa sobreviver a reinicializações de processo — porque é de longa duração, porque tem passos de humano no ciclo, porque se distribui em muitas chamadas de agentes em paralelo — o runner in-memory não é suficiente.

A integração Durable Task do MAF armazena o estado do workflow no Azure Storage. Se o processo for reiniciado, o workflow retoma de onde parou. O modelo de programação permanece o mesmo; você apenas troca o runner.

dotnet add package Microsoft.Agents.AI.Workflows.DurableTask

Os mesmos executors, o mesmo grafo de workflow — apoiado por estado durável.

Hospedagem no Azure Functions

A terceira camada é a hospedagem no Azure Functions. Seu workflow se torna um aplicativo Function: acione o workflow via um endpoint HTTP, e o runtime durável cuida do escalonamento, estado e confiabilidade.

Isso significa que um workflow multi-agente com chamadas paralelas, ramos condicionais e aprovações humanas pode escalar em um ambiente Functions serverless sem gerenciamento de estado personalizado.

Por Que Isso Importa

A combinação é significativa para sistemas de IA reais:

Chamadas de agentes em paralelo — distribuir para múltiplos agentes especializados simultaneamente sem bloqueio, agregar resultados quando todos concluírem
Processos de longa duração — workflows que envolvem aprovação humana ou eventos externos podem pausar e retomar ao longo de horas ou dias
Escalonamento — Azure Functions escala a execução horizontalmente; o framework Durable Task gerencia a coordenação do estado paralelo

Se você está construindo workflows MAF além de demos locais simples, este é o caminho para execução de qualidade produção.

Post original: Durable Workflows in the Microsoft Agent Framework

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

Construir Agentes É a Parte Fácil — Executá-los com Segurança É a Parte Difícil

Emiliano Montesdeoca — Fri, 29 May 2026 00:00:00 +0000

Existe um padrão no desenvolvimento de agentes de IA que comecei a chamar de “arrependimento de demo”. O agente funciona muito bem nas demos. Então alguém pergunta: o que acontece se ele chamar a ferramenta errada? E se acessar dados que não deveria? Quem auditou isso?

Microsoft Agent Framework te apoia na construção e orquestração. Agent Governance Toolkit (AGT) cobre a parte posterior — governança, aplicação de políticas e auditabilidade em tempo de execução.

O Que Cada Projeto Realmente Faz

Microsoft Agent Framework (MAF) fornece o modelo de programação: workflows multi-agente, interoperabilidade do protocolo A2A, hooks de middleware, memória e hospedagem gerenciada via Foundry Agent Service. Lida com segurança de conteúdo no nível de entrada/saída do modelo.

Agent Governance Toolkit (AGT) se conecta a esse mesmo pipeline de middleware para governar ações. Cada chamada de ferramenta, acesso a recursos e mensagem inter-agentes é avaliada contra a política antes da execução. Overhead submilissegundo. Sem sidecars, sem proxies, sem prompts modificados.

Ação do Agente --> Verificação de Política --> Permitir / Negar --> Log de Auditoria (< 0.1 ms)

Camadas diferentes, cobertura completa, um pipeline.

Conectar-se É Apenas Adicionar Middleware

Em Python, o AGT adiciona ao mesmo parâmetro middleware que você usaria para registro ou filtros de conteúdo:

agent = Agent(
 client=OpenAIChatClient(model="gpt-5.3"),
 name="Contoso Loan Officer",
 instructions="You are a governed loan assistant.",
 tools=[check_credit_score, get_loan_rates, approve_small_loan],
 middleware=[
 AuditTrailMiddleware(audit_log=audit_log, agent_did="loan-agent"),
 GovernancePolicyMiddleware(evaluator=evaluator, audit_log=audit_log),
 CapabilityGuardMiddleware(allowed_tools=["check_credit_score", "get_loan_rates"]),
 RogueDetectionMiddleware(detector=detector, agent_id="loan-agent"),
 ],
)

Em .NET, mesmo padrão via .Use():

var agent = builder.BuildAIAgent(model: "gpt-5.3")
 .Use(new GovernancePolicyMiddleware(evaluator))
 .Use(new CapabilityGuardMiddleware(allowedTools))
 .Use(new AuditTrailMiddleware(auditLog));

Mesmo agente, mesma orquestração, mesmas ferramentas. O AGT adiciona capacidades de governança sem tocar na lógica do agente.

O Que Você Obtém

GovernancePolicyMiddleware — avalia cada ação contra regras de política declarativas
CapabilityGuardMiddleware — lista de permissão das ferramentas que um agente pode chamar (a ferramenta approve_small_loan não está na lista permitida acima — deliberadamente)
RogueDetectionMiddleware — detecta padrões de comportamento anômalo em tempo de execução
AuditTrailMiddleware — log de auditoria encadeado com Merkle para que cada ação seja criptograficamente resistente a adulterações

Este último importa para conformidade. Uma cadeia Merkle significa que se alguém modificar o log, a cadeia quebra. A auditoria é a evidência.

Cinco Cenários da Indústria

O repositório AGT inclui cinco cenários completos de ponta a ponta: serviços financeiros (agente de empréstimos), saúde (dados de pacientes), jurídico (revisão de contratos), governo (serviços ao cidadão) e manufatura (controle de qualidade). Cada um combina agentes MAF reais com middleware de governança AGT real.

Não são demos de brinquedo. São o tipo de cenários em que você realmente precisaria de governança em produção.

Conclusão

Se você está construindo agentes que tocam dados reais, tomam decisões com consequências, ou executam sem supervisão em produção — a governança não é opcional. A combinação MAF + AGT fornece o stack completo: construa com Agent Framework, governe com AGT.

Ambos os projetos são open source. O artigo original tem links para os exemplos de código completos.

Post original: Governance at the Speed of Agents: Microsoft Agent Framework and Agent Governance Toolkit, Better Together

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

Azure SQL Agora Pode Gerar Embeddings — Em T-SQL Puro, Sem Camada de Aplicação

Emiliano Montesdeoca — Fri, 22 May 2026 00:00:00 +0000

Se você já construiu uma pipeline RAG, conhece o imposto da pipeline: seus dados vivem no SQL, mas para gerar embeddings você precisa extraí-los, chamar uma API de embeddings, lidar com batching e limites de taxa, e armazenar os resultados em algum lugar com busca vetorial. Muitas vezes em um banco de dados completamente diferente.

O Azure SQL acabou de eliminar a maior parte disso com duas funcionalidades que agora estão geralmente disponíveis: CREATE EXTERNAL MODEL e AI_GENERATE_EMBEDDINGS.

O Que Elas Fazem

Essas duas funcionalidades T-SQL funcionam como uma pipeline integrada:

CREATE EXTERNAL MODEL — registra um endpoint de modelo de IA externo como um objeto de banco de dados nomeado. Você define a localização, o formato da API, o tipo de modelo e as credenciais uma vez. Reutilize em qualquer lugar.

AI_GENERATE_EMBEDDINGS — uma função T-SQL escalar que chama o modelo registrado e retorna um array JSON de valores vetoriais. Funciona em instruções SELECT, INSERT, UPDATE e MERGE.

Juntos formam uma pipeline de embeddings de ponta a ponta sem sair do motor SQL.

O Fluxo de Trabalho Completo

-- Passo 1: Registre seu provedor de embeddings uma vez
CREATE EXTERNAL MODEL MyEmbeddingModel
WITH (
 LOCATION = 'https://your-aoai-resource.openai.azure.com/',
 API_FORMAT = 'Azure OpenAI',
 MODEL_TYPE = EMBEDDINGS,
 MODEL = 'text-embedding-ada-002'
);

-- Passo 2: Gere embeddings inline em T-SQL
UPDATE docs
SET embedding = AI_GENERATE_EMBEDDINGS(content USE MODEL MyEmbeddingModel)
FROM documents AS docs;

-- Passo 3: Pesquise com distância vetorial
SELECT TOP 10 id, content
FROM documents
ORDER BY VECTOR_DISTANCE('cosine', embedding,
 AI_GENERATE_EMBEDDINGS(@query USE MODEL MyEmbeddingModel));

Esse é o pipeline inteiro: dados no SQL, embeddings gerados no SQL, busca por similaridade no SQL. Sem camada de orquestração, sem ETL, sem banco de dados vetorial separado.

Formatos de API e Opções Suportadas

Em GA, API_FORMAT suporta Azure OpenAI e OpenAI. MODEL_TYPE está bloqueado em EMBEDDINGS por enquanto. O JSON PARAMETERS permite definir padrões a nível de modelo incluindo o número de tentativas:

PARAMETERS = '{"sql_rest_options":{"retry_count":3}}'

A autenticação usa credenciais do banco de dados, portanto os segredos ficam fora do código da aplicação.

O Que Isso Habilita para Aplicações .NET

Para desenvolvedores .NET construindo funcionalidades de IA em dados SQL existentes, isso é significativo. Você não precisa:

Extrair dados para um armazenamento intermediário para embeddings
Gerenciar uma pipeline de embeddings externa
Configurar um banco de dados vetorial separado (embora você possa usar Azure AI Search se quiser um armazenamento vetorial completo)
Alterar a camada de acesso a dados da sua aplicação

Você pode adicionar busca semântica a aplicações SQL existentes de forma incremental, usando as mesmas ferramentas T-SQL que você já tem.

Conclusão

Os padrões RAG em dados SQL ficaram dramaticamente mais simples. AI_GENERATE_EMBEDDINGS + CREATE EXTERNAL MODEL significa que sua aplicação SQL existente pode ganhar capacidades de busca vetorial sem adicionar nova infraestrutura.

Ambas as funcionalidades estão em GA no Azure SQL Database e Azure SQL Managed Instance hoje.

Post original: Generate Embeddings Function and External Model Object Support Are Now Generally Available in Azure SQL

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

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.

Construindo um app de conferência com IA com a stack componível do .NET

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

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

Construindo um app de conferência com IA com a stack componível do .NET — A Microsoft criou o ConferencePulse, um app Blazor Server para sessões de conferência ao vivo, combinando cinco bibliotecas de extensão do .NET. Foi utilizado no MVP Summit.

O que o ConferencePulse faz

O ConferencePulse é executado durante as sessões ao vivo e fornece: enquetes geradas por IA a partir do conteúdo da sessão, perguntas e respostas do público com um pipeline RAG que extrai de uma base de conhecimento ao vivo, insights gerados automaticamente e resumos de sessões produzidos por múltiplos agentes de IA concorrentes. A stack é .NET 10, Blazor Server, Aspire, dividida em cinco projetos: Web, Core, Ingestion, Agents, Mcp e AppHost.

Microsoft.Extensions.AI: uma abstração para tudo

IChatClient é a abstração unificada — configura-se uma vez e a mesma interface funciona para Azure OpenAI, OpenAI, Anthropic ou qualquer outro provedor. Seis linhas para obter um cliente totalmente configurado com invocação de funções, rastreamento OpenTelemetry e middleware de logging:

services.AddChatClient(new AzureOpenAIClient(...).GetChatClient("gpt-4o"))
 .UseFunctionInvocation()
 .UseOpenTelemetry()
 .UseLogging();

O mesmo IChatClient é reutilizado posteriormente para o passo de enriquecimento da ingestão de dados — sem necessidade de um cliente separado para isso.

Pipeline de DataIngestion

O conteúdo da sessão flui por um pipeline: MarkdownReader → HeaderChunker (500 tokens, 50 tokens de sobreposição) → SummaryEnricher + KeywordEnricher → VectorStoreWriter (Qdrant). Os enriquecedores usam o mesmo IChatClient para gerar resumos e extrair palavras-chave antes da indexação. Perguntas do público, pares de perguntas e respostas e resultados de enquetes são ingeridos em tempo real à medida que a sessão avança — a base de conhecimento cresce durante a apresentação.

VectorData: busca independente do provedor

VectorStoreCollection.SearchAsync() funciona da mesma forma independentemente de o backing store ser Qdrant ou Azure AI Search. A busca híbrida (vetor + texto completo) é suportada. O pipeline RAG para perguntas e respostas do público consulta esta coleção e obtém chunks relevantes para passar como contexto ao cliente de chat.

MCP: conteúdo da sessão como ferramentas

O conteúdo da sessão é exposto via MCP para que qualquer cliente compatível com MCP possa acessá-lo. Tanto o servidor quanto o cliente estão implementados — o servidor expõe o conhecimento da sessão como ferramentas MCP, e o cliente permite chamar essas ferramentas de dentro do pipeline do agente.

Agent Framework: resumo multi-agente em paralelo

O resumo da sessão é gerado por três agentes executados de forma concorrente — PollSummaryAgent, QuestionSummaryAgent e InsightSummaryAgent — e então mesclados. Isso utiliza o padrão de chat em grupo ou execução paralela do Microsoft Agent Framework. Cada agente lida com uma preocupação; o orquestrador mescla as saídas.

O princípio de design

O post faz um ponto que vale a pena guardar: use a ferramenta mais simples que se encaixe. Chamadas diretas ao IChatClient para tarefas simples de geração. Chamada de ferramenta/função para extração de dados estruturados. Agentes completos apenas quando você precisa de raciocínio autônomo de múltiplos passos. A camada de bibliotecas impõe isso — você pode usar o Microsoft.Extensions.AI sem incluir o Agent Framework completo.

Consulte o post completo para a estrutura completa do projeto e links de código-fonte.

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

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

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

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

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

O que é um Agente (vs. um Chatbot)

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

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

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

Seu Primeiro Agente em 10 Linhas

dotnet add package Microsoft.Agents.AI

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

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

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

Streaming também funciona:

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

Dando Ferramentas ao Agente

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

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

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

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

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

Sessões: Conversas com Memória Real

AgentSession session = await agent.CreateSessionAsync();

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

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

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

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

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

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

AIContextProvider: Memória Persistente Entre Sessões

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

Tem dois hooks:

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

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

Workflows Multiagente

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

Alguns padrões suportados nativamente:

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

Um exemplo de escritor-crítico:

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

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

Human-in-the-Loop

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

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

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

O Quadro Completo

Se você der um passo atrás:

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

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

Conclusão

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

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

CodeAct no Agent Framework: Como Reduzir a Latência do seu Agente pela Metade

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

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

Existe aquele momento em todo projeto de agentes em que você olha para o trace e pensa: “por que isso está demorando tanto?” O modelo está ótimo. As ferramentas funcionam. Mas há sete round trips para obter um resultado que poderia ser calculado de uma só vez.

Esse é exatamente o problema que o CodeAct resolve — e a equipe do Agent Framework acabou de lançar suporte alpha via o novo pacote agent-framework-hyperlight.

O que é CodeAct?

O padrão CodeAct é elegantemente simples: em vez de dar ao modelo uma lista de ferramentas para chamar uma por uma, você dá a ele uma única ferramenta execute_code e deixa-o expressar o plano completo como um curto programa Python. O agente escreve o código uma vez, o sandbox o executa, e você recebe de volta um único resultado consolidado.

Fiação	Tempo	Tokens
Tradicional	27,81s	6.890
CodeAct	13,23s	2.489
Melhoria	52,4%	63,9%

A peça de segurança: Micro-VMs do Hyperlight

O pacote agent-framework-hyperlight usa micro-VMs do Hyperlight. Cada chamada execute_code obtém sua própria micro-VM recém-criada. A inicialização é medida em milissegundos. O isolamento é essencialmente gratuito.

Suas ferramentas continuam sendo executadas no host. O código de cola gerado pelo modelo é executado no sandbox. Essa é a divisão correta.

Configuração mínima

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

Quando usar o CodeAct (e quando não usar)

Use o CodeAct quando:

A tarefa encadeia muitas chamadas pequenas de ferramentas (lookups, joins, cálculos)
A latência e o custo de tokens importam
Você quer isolamento forte por chamada no código gerado pelo modelo

Fique com o tool-calling tradicional quando:

O agente só faz uma ou duas chamadas de ferramentas por turno
Cada chamada tem efeitos colaterais a serem aprovados individualmente
As descrições de ferramentas são esparsas ou ambíguas

Experimente agora

pip install agent-framework-hyperlight --pre

Confira o post completo no blog do Agent Framework para uma cobertura mais profunda.

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.

Onde seu Agente se Lembra das Coisas? Guia Prático de Armazenamento do Histórico de Chat

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

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

Ao criar um agente IA, você gasta a maior parte da energia no modelo, nas ferramentas e nos prompts. A pergunta de onde vive o histórico de conversa parece um detalhe de implementação — mas é uma das decisões arquiteturais mais importantes que você tomará.

Ela determina se usuários podem bifurcar conversas, desfazer respostas, retomar sessões após uma reinicialização e se seus dados saem da sua infraestrutura. A equipe do Agent Framework publicou uma análise aprofundada.

Dois padrões fundamentais

Gerenciado pelo serviço: o serviço IA armazena o estado da conversa. Seu app mantém uma referência e o serviço inclui automaticamente o histórico relevante em cada requisição.

Gerenciado pelo cliente: seu app mantém o histórico completo e envia mensagens relevantes com cada requisição. O serviço é stateless. Você controla tudo.

Como o Agent Framework abstrai isso

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Meu nome é Alice.", session);
var second = await agent.RunAsync("Qual é o meu nome?", session);

session = agent.create_session()
first = await agent.run("Meu nome é Alice.", session=session)
second = await agent.run("Qual é o meu nome?", session=session)

Referência rápida de provedores

Provedor	Armazenamento	Modelo	Compactação
OpenAI/Azure Chat Completions	Cliente	N/A	Você
Foundry Agent Service	Serviço	Linear	Serviço
Responses API (padrão)	Serviço	Ramificável	Serviço
Anthropic Claude, Ollama	Cliente	N/A	Você

Como escolher

Precisa de ramificação ou “desfazer”? → Responses API gerenciado pelo serviço
Precisa de soberania de dados? → Gerenciado pelo cliente com provedor de banco de dados
É um chatbot simples? → Gerenciado pelo serviço linear está ótimo

Leia o post completo para a árvore de decisão completa.

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.

Windows App Dev CLI v0.3: F5 a partir do terminal e automação de UI para agentes

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

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

A experiência F5 do Visual Studio é fantástica. Mas ter que abrir o VS só para lançar e depurar uma app Windows empacotada é demais — seja num pipeline de CI, num workflow automatizado, ou quando um agente de IA está fazendo os testes.

Windows App Development CLI v0.3 acabou de ser lançada e aborda isso diretamente com dois recursos principais: winapp run e winapp ui.

winapp run: F5 a partir de qualquer lugar

winapp run recebe uma pasta de app não empacotada e um manifesto, e faz tudo que o VS faz num debug launch: registra um pacote loose, lança a app e preserva o LocalState entre re-deploys.

# Compilar a app e então executá-la como app empacotada
winapp run ./bin/Debug

Funciona para WinUI, WPF, WinForms, Console, Avalonia e mais. Os modos são pensados para desenvolvedores e workflows automatizados:

--detach: Lança e devolve o controle ao terminal imediatamente. Perfeito para CI.
--unregister-on-exit: Limpa o pacote registrado ao fechar a app.
--debug-output: Captura mensagens OutputDebugString e exceções em tempo real.

Novo pacote NuGet: dotnet run para apps empacotadas

Para desenvolvedores .NET há um novo pacote NuGet: Microsoft.Windows.SDK.BuildTools.WinApp. Após a instalação, dotnet run cuida de todo o inner loop: build, preparar um pacote loose-layout, registrar no Windows e lançar — tudo em uma etapa.

winapp init
# ou
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui: UI Automation a partir da linha de comando

Este é o recurso que abre os cenários agênticos. winapp ui fornece acesso completo de UI Automation a qualquer app Windows em execução — WPF, WinForms, Win32, Electron, WinUI3 — diretamente do terminal.

O que é possível fazer:

Listar todas as janelas de nível superior
Navegar pela árvore completa de UI Automation de uma janela
Procurar elementos por nome, tipo ou ID de automação
Clicar, invocar e definir valores
Tirar screenshots
Aguardar o aparecimento de elementos — ideal para sincronização de testes

Combinar winapp ui com winapp run cria um workflow completo build → lançar → verificar a partir do terminal. Um agente pode executar a app, inspecionar o estado da UI e validar o resultado.

Outras novidades

winapp unregister: Remove um pacote sideloaded quando terminar.
winapp manifest add-alias: Adiciona um alias para lançar a app por nome a partir do terminal.
Tab completion: Configure o completamento PowerShell com um único comando.

Como obter

winget install Microsoft.WinAppCli
# ou
npm install -g @microsoft/winappcli

A CLI está em preview pública. O repositório no GitHub tem a documentação completa e o anúncio original tem todos os detalhes.

VS Code 1.117: Os Agentes Estão Ganhando Suas Próprias Branches Git e Eu Tô Adorando

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

A linha entre “assistente de IA” e “colega de equipe de IA” continua ficando mais fina. O VS Code 1.117 acabou de sair e as notas de versão completas estão recheadas, mas a história é clara: os agentes estão se tornando cidadãos de primeira classe no seu fluxo de trabalho de desenvolvimento.

Aqui está o que realmente importa.

O modo Autopilot finalmente lembra sua preferência

Antes, você tinha que reativar o Autopilot toda vez que iniciava uma nova sessão. Irritante. Agora seu modo de permissão persiste entre sessões, e você pode configurar o padrão.

O Agent Host suporta três configurações de sessão:

Default — as ferramentas pedem confirmação antes de executar
Bypass — aprova tudo automaticamente
Autopilot — totalmente autônomo, responde suas próprias perguntas e segue em frente

Se você está montando um novo projeto .NET com migrations, Docker e CI — configure para Autopilot uma vez e esqueça. Essa preferência fica salva.

Worktree e isolamento git para sessões de agentes

Essa é a grande novidade. Sessões de agentes agora suportam isolamento completo com worktree e git. Isso significa que quando um agente trabalha em uma tarefa, ele ganha sua própria branch e diretório de trabalho. Sua branch principal fica intocada.

Melhor ainda — o Copilot CLI gera nomes de branch significativos para essas sessões de worktree. Chega de agent-session-abc123. Você recebe algo que realmente descreve o que o agente está fazendo.

Para desenvolvedores .NET que gerenciam múltiplas branches de features ou corrigem bugs enquanto uma tarefa longa de scaffolding roda, isso é um divisor de águas. Você pode ter um agente construindo seus controllers de API em um worktree enquanto você depura um problema na camada de serviços em outro. Sem conflitos. Sem stashing. Sem bagunça.

Subagentes e equipes de agentes

O Agent Host Protocol agora suporta subagentes. Um agente pode criar outros agentes para lidar com partes de uma tarefa. Pense nisso como delegar — seu agente principal coordena, e agentes especializados cuidam das partes.

Isso é cedo, mas o potencial para fluxos de trabalho .NET é óbvio. Imagine um agente cuidando das suas migrations do EF Core enquanto outro configura seus testes de integração. Ainda não chegamos totalmente lá, mas o suporte ao protocolo chegando agora significa que as ferramentas virão rápido.

Saída do terminal incluída automaticamente quando agentes enviam input

Pequeno mas significativo. Quando um agente envia input para o terminal, a saída do terminal agora é automaticamente incluída no contexto. Antes, o agente precisava de um turno extra só para ler o que aconteceu.

Se você já viu um agente executar dotnet build, falhar, e depois precisar de mais uma ida e volta só para ver o erro — essa fricção acabou. Ele vê a saída imediatamente e reage.

O app Agents no macOS se atualiza sozinho

O app independente Agents no macOS agora se atualiza sozinho. Chega de baixar novas versões manualmente. Ele simplesmente se mantém atualizado.

As coisas menores que vale a pena saber

Os hovers do package.json agora mostram tanto a versão instalada quanto a última disponível. Útil se você gerencia ferramentas npm junto com seus projetos .NET.
Imagens em comentários JSDoc são renderizadas corretamente em hovers e completions.
Sessões do Copilot CLI agora indicam se foram criadas pelo VS Code ou externamente — prático quando você está pulando entre terminais.
Copilot CLI, Claude Code e Gemini CLI são reconhecidos como tipos de shell. O editor sabe o que você está executando.

A conclusão

VS Code 1.117 não é um despejo de features chamativas. É infraestrutura. Isolamento com worktree, permissões persistentes, protocolos de subagentes — esses são os blocos de construção para um fluxo de trabalho onde agentes lidam com tarefas reais e paralelas sem pisar no seu código.

Se você está construindo com .NET e ainda não mergulhou no fluxo de trabalho com agentes, honestamente, agora é a hora de começar.

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.

Docker Sandbox permite que agentes do Copilot refatorem seu código sem colocar sua máquina em risco

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

Se você já usou o modo agente do Copilot para algo além de edições pequenas, conhece a dor. Cada escrita de arquivo, cada comando no terminal — mais um prompt de permissão. Agora imagina isso em 50 projetos. Nada divertido.

O time do Azure acabou de publicar um post sobre Docker Sandbox para agentes do GitHub Copilot, e honestamente, essa é uma das melhorias mais práticas que eu já vi em ferramentas agênticas. Usa microVMs para dar ao Copilot um ambiente completamente isolado onde ele pode fazer de tudo — instalar pacotes, rodar builds, executar testes — sem tocar no seu sistema host.

O que o Docker Sandbox realmente te oferece

A ideia central é simples: subir uma microVM leve com um ambiente Linux completo, sincronizar seu workspace para dentro dela, e deixar o agente do Copilot operar livremente lá dentro. Quando termina, as mudanças são sincronizadas de volta.

Eis o que faz isso ser mais do que simplesmente “rodar coisas num container”:

Sincronização bidirecional do workspace que preserva caminhos absolutos. A estrutura do seu projeto fica idêntica dentro do sandbox. Sem falhas de build por causa de caminhos.
Docker daemon privado rodando dentro da microVM. O agente pode construir e rodar containers sem nunca montar o socket Docker do seu host. Isso é muito importante para segurança.
Proxies de filtragem HTTP/HTTPS que controlam o que o agente pode acessar na rede. Você decide quais registries e endpoints são permitidos. Ataques à cadeia de suprimentos por um npm install malicioso dentro do sandbox? Bloqueados.
Modo YOLO — sim, é assim que eles chamam. O agente roda sem prompts de permissão porque literalmente não consegue danificar seu host. Toda ação destrutiva está contida.

Por que desenvolvedores .NET deveriam se importar

Pense no trabalho de modernização que tantos times estão enfrentando agora. Você tem uma solução .NET Framework com 30 projetos e precisa migrá-la para .NET 9. São centenas de alterações de arquivos — arquivos de projeto, atualizações de namespaces, substituições de API, migrações de NuGet.

Com Docker Sandbox, você pode apontar um agente do Copilot para um projeto, deixá-lo refatorar livremente dentro da microVM, rodar dotnet build e dotnet test para validar, e só aceitar as mudanças que realmente funcionam. Sem risco dele acidentalmente destruir seu ambiente de desenvolvimento local enquanto experimenta.

O post também descreve rodar uma frota de agentes em paralelo — cada um no seu próprio sandbox — trabalhando em diferentes projetos simultaneamente. Para soluções .NET grandes ou arquiteturas de microsserviços, isso economiza uma quantidade enorme de tempo. Um agente por serviço, todos rodando isolados, todos validados independentemente.

O ângulo da segurança importa

Aqui está o que a maioria das pessoas ignora: quando você deixa um agente de IA executar comandos arbitrários, está confiando a ele toda a sua máquina. Docker Sandbox inverte esse modelo. O agente recebe autonomia total dentro de um ambiente descartável. O proxy de rede garante que ele só pode baixar de fontes aprovadas. Seu filesystem host, Docker daemon e credenciais ficam intocados.

Para times com requisitos de compliance — e isso é a maioria das empresas .NET — essa é a diferença entre “não podemos usar IA agêntica” e “podemos adotá-la com segurança.”

Conclusão

Docker Sandbox resolve a tensão fundamental da programação agêntica: agentes precisam de liberdade para serem úteis, mas liberdade na sua máquina host é perigoso. MicroVMs te dão os dois. Se você está planejando qualquer refatoração ou modernização .NET em larga escala, vale a pena configurar isso agora. A combinação da inteligência de código do Copilot com um ambiente de execução seguro é exatamente o que times de produção estavam esperando.

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.

.NET Aspire 13.2 Quer Ser o Melhor Amigo do Seu Agente de IA

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

Sabe aquele momento quando seu agente de IA escreve um código sólido, você fica empolgado, e aí tudo desmorona quando ele tenta executar a coisa? Conflitos de porta, processos fantasma, variáveis de ambiente erradas — de repente seu agente está queimando tokens fazendo troubleshooting de problemas de inicialização em vez de construir funcionalidades.

O time do Aspire acabou de publicar um post muito bem pensado sobre exatamente esse problema, e a resposta deles é convincente: Aspire 13.2 foi projetado não apenas para humanos, mas para agentes de IA.

O problema é real

Agentes de IA são incríveis escrevendo código. Mas entregar uma app full-stack funcional envolve muito mais do que gerar arquivos. Você precisa iniciar serviços na ordem certa, gerenciar portas, configurar variáveis de ambiente, conectar bancos de dados e obter feedback quando as coisas quebram. Agora, a maioria dos agentes lida com tudo isso por tentativa e erro — executando comandos, lendo saída de erros, tentando de novo.

Nós empilhamos instruções Markdown, skills personalizados e prompts para guiá-los, mas são imprevisíveis, não podem ser compilados e custam tokens só para fazer parse. O time do Aspire acertou no insight central: agentes precisam de compiladores e APIs estruturadas, não mais Markdown.

Aspire como infraestrutura para agentes

Eis o que o Aspire 13.2 traz para a mesa do desenvolvimento agêntico:

Toda a sua stack em código tipado. O AppHost define toda sua topologia — API, frontend, banco de dados, cache — em TypeScript ou C# compilável:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

Um agente pode ler isso para entender a topologia da app, adicionar recursos, conectar componentes e compilar para verificar. O compilador diz imediatamente se algo está errado. Sem adivinhação, sem tentativa e erro com arquivos de configuração.

Um comando para governar todos. Em vez de agentes malabarizando docker compose up, npm run dev e scripts de inicialização de banco de dados, tudo é simplesmente aspire start. Todos os recursos são lançados na ordem certa, nas portas certas, com a configuração certa. Processos de longa duração também não travam o agente — o Aspire os gerencia.

Modo isolado para agentes paralelos. Com --isolated, cada execução do Aspire recebe suas próprias portas aleatórias e segredos de usuário separados. Tem múltiplos agentes trabalhando em git worktrees? Eles não vão colidir. Isso é enorme para ferramentas como os agentes em segundo plano do VS Code que criam ambientes paralelos.

Olhos de agente através de telemetria. Aqui é onde fica realmente poderoso. A CLI do Aspire expõe dados OpenTelemetry completos durante o desenvolvimento — traces, métricas, logs estruturados. Seu agente não está apenas lendo saída de console e torcendo pelo melhor. Ele pode rastrear uma requisição falhada entre serviços, perfilar endpoints lentos e identificar exatamente onde as coisas quebram. Isso é observabilidade de nível produção no ciclo de desenvolvimento.

A analogia dos para-choques de boliche

O time do Aspire usa uma ótima analogia: pense no Aspire como os para-choques de pista de boliche para agentes de IA. Se o agente não for perfeito (e não será), os para-choques evitam que ele jogue na canaleta. A definição do stack previne erros de configuração, o compilador captura erros, a CLI gerencia processos e a telemetria fornece o ciclo de feedback.

Combine isso com algo como Playwright CLI, e seu agente pode realmente usar sua app — clicando nos fluxos, checando o DOM, vendo coisas quebradas na telemetria, consertando o código, reiniciando e testando de novo. Construir, executar, observar, consertar. Esse é o ciclo de desenvolvimento autônomo que estávamos perseguindo.

Primeiros passos

Novo no Aspire? Instale a CLI em get.aspire.dev e siga o guia de início.

Já usa Aspire? Execute aspire update --self para obter a 13.2, depois aponte seu agente de código favorito para seu repo. Você pode se surpreender com o quanto mais longe ele chega com os guardrails do Aspire.

Concluindo

Aspire 13.2 não é mais apenas um framework para apps distribuídas — está se tornando infraestrutura essencial para agentes. Definições de stack estruturadas, inicialização com um comando, execuções paralelas isoladas e telemetria em tempo real dão aos agentes de IA exatamente o que precisam para ir de escrever código a entregar apps.

Leia o post completo do time do Aspire para todos os detalhes 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.

MCP Apps ganham uma API fluente — Construa interfaces ricas para ferramentas de IA em .NET em três passos

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

Ferramentas MCP são ótimas para dar capacidades aos agentes de IA. Mas e se a sua ferramenta precisa mostrar algo ao usuário — um dashboard, um formulário, uma visualização interativa? É aí que entram as MCP Apps, e elas ficaram muito mais fáceis de construir.

Lilian Kasem da equipe do Azure SDK apresentou a nova API de configuração fluente para MCP Apps no Azure Functions com .NET, e é o tipo de melhoria na experiência do desenvolvedor que faz a gente se perguntar por que não era sempre assim tão simples.

O que são MCP Apps?

MCP Apps estendem o Model Context Protocol permitindo que as ferramentas carreguem suas próprias views de UI, assets estáticos e controles de segurança. Em vez de apenas retornar texto, sua ferramenta MCP pode renderizar experiências HTML completas — dashboards interativos, visualizações de dados, formulários de configuração — tudo invocável por agentes de IA e apresentado aos usuários pelos clientes MCP.

O problema era que conectar tudo isso manualmente exigia conhecer a especificação MCP a fundo: URIs ui://, tipos MIME especiais, coordenação de metadados entre ferramentas e recursos. Não era difícil, mas trabalhoso.

A API fluente em três passos

Passo 1: Defina sua função. Uma ferramenta MCP padrão do Azure Functions:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Passo 2: Promova-a a MCP App. No startup do seu programa:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Passo 3: Adicione sua view HTML. Crie assets/hello-app.html com a interface que você precisa.

É isso. A API fluente cuida de toda a encanação do protocolo MCP — gera a função de recurso sintético, define o tipo MIME correto e injeta os metadados que conectam sua ferramenta à sua view.

A superfície da API é bem projetada

Algumas coisas que eu realmente gosto:

As fontes de views são flexíveis. Você pode servir HTML a partir de arquivos no disco, ou embutir recursos diretamente no seu assembly para deploys independentes:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

O CSP é componível. Você permite explicitamente as origens que sua app precisa, seguindo princípios de menor privilégio. Chame WithCsp várias vezes e as origens se acumulam:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Controle de visibilidade. Você pode tornar uma ferramenta visível apenas para o LLM, apenas para a UI do host, ou ambos. Quer uma ferramenta que só renderiza UI e não deve ser chamada pelo modelo? Fácil:

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

Primeiros passos

Adicione o pacote preview:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

Se você já está construindo ferramentas MCP com Azure Functions, isso é apenas uma atualização de pacote. O quickstart de MCP Apps é o melhor lugar para começar se você é novo no conceito.

Finalizando

MCP Apps são um dos desenvolvimentos mais empolgantes no espaço de ferramentas de IA — ferramentas que não apenas fazem coisas, mas podem mostrar coisas aos usuários. A API fluente remove a complexidade do protocolo e permite que você se concentre no que importa: a lógica da sua ferramenta e sua interface.

Leia o post completo para a referência completa da API e exemplos.

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.

VS Code 1.115 — Notificações de Terminal em Segundo Plano, Modo Agente SSH e Mais

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

VS Code 1.115 acabou de ser lançado, e embora seja uma versão mais leve em termos de funcionalidades principais, as melhorias relacionadas a agentes são genuinamente úteis se você trabalha com assistentes de código com IA diariamente.

Deixa eu destacar o que realmente vale a pena saber.

Terminais em segundo plano se comunicam com agentes

Essa é a funcionalidade destaque. Terminais em segundo plano agora notificam automaticamente os agentes quando comandos são concluídos, incluindo o código de saída e a saída do terminal. Prompts de entrada em terminais em segundo plano também são detectados e exibidos ao usuário.

Por que isso importa? Se você usou o modo agente do Copilot para executar comandos de build ou suítes de testes em segundo plano, você conhece a dor do “será que já terminou?” — terminais em segundo plano eram essencialmente disparar-e-esquecer. Agora o agente é notificado quando seu dotnet build ou dotnet test termina, vê a saída e pode reagir de acordo. É uma mudança pequena que torna os fluxos de trabalho orientados por agentes significativamente mais confiáveis.

Há também uma nova ferramenta send_to_terminal que permite aos agentes enviar comandos para terminais em segundo plano com confirmação do usuário, corrigindo o problema onde run_in_terminal com um timeout movia terminais para segundo plano e os deixava somente leitura.

Hospedagem remota de agentes via SSH

VS Code agora suporta conexão a máquinas remotas via SSH, instalando automaticamente o CLI e iniciando-o em modo host de agentes. Isso significa que suas sessões de agentes de IA podem mirar ambientes remotos diretamente — útil para desenvolvedores .NET que compilam e testam em servidores Linux ou VMs na nuvem.

Rastreamento de edições em sessões de agentes

Edições de arquivos feitas durante sessões de agentes agora são rastreadas e restauradas, com diffs, desfazer/refazer e restauração de estado. Se um agente faz alterações no seu código e algo dá errado, você pode ver exatamente o que mudou e reverter. Tranquilidade para deixar agentes modificarem sua codebase.

Reconhecimento de abas do navegador e outras melhorias

Mais algumas adições de qualidade de vida:

Rastreamento de abas do navegador — o chat agora pode rastrear e linkar abas do navegador abertas durante uma sessão, para que agentes possam referenciar páginas web que você está visualizando
Colagem de arquivos no terminal — cole arquivos (incluindo imagens) no terminal com Ctrl+V, arrastar e soltar, ou clique direito
Cobertura de testes no minimap — indicadores de cobertura de testes agora aparecem no minimap para uma visão visual rápida
Pinch-to-zoom no Mac — o navegador integrado suporta gestos de pinch-to-zoom
Direitos do Copilot em Sessões — a barra de status mostra informações de uso na visualização de Sessões
Favicon em Ir para Arquivo — páginas web abertas mostram favicons na lista de seleção rápida

Conclusão

VS Code 1.115 é uma versão incremental, mas as melhorias de agentes — notificações de terminal em segundo plano, hospedagem de agentes SSH e rastreamento de edições — somam-se a uma experiência notavelmente mais fluida para desenvolvimento assistido por IA. Se você está usando o modo agente do Copilot para projetos .NET, esses são o tipo de melhorias de qualidade de vida que reduzem o atrito no dia a dia.

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

Aspire 13.2 traz uma CLI de documentação — e seu agente de IA também pode usá-la

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

Você conhece aquele momento quando está mergulhado num Aspire AppHost, conectando integrações, e precisa verificar exatamente quais parâmetros a integração Redis espera? Você faz alt-tab pro navegador, procura pelo aspire.dev, aperta os olhos nos docs da API, e volta pro seu editor. Contexto perdido. Flow quebrado.

Aspire 13.2 acabou de lançar uma solução pra isso. A CLI aspire docs permite que você pesquise, navegue e leia documentação oficial do Aspire diretamente do seu terminal. E como é respaldada por serviços reutilizáveis, agentes de IA e skills podem usar os mesmos comandos para consultar docs em vez de alucinar APIs que não existem.

O problema que isso realmente resolve

David Pine acerta em cheio no post original: agentes de IA eram terríveis em ajudar desenvolvedores a construir apps com Aspire. Recomendavam dotnet run em vez de aspire run, referenciavam learn.microsoft.com para docs que vivem no aspire.dev, sugeriam pacotes NuGet desatualizados, e — meu favorito pessoal — alucinavam APIs que não existem.

Por quê? Porque Aspire foi específico de .NET por muito mais tempo do que é poliglota, e os LLMs trabalham com dados de treinamento que antecedem os recursos mais recentes. Quando você dá a um agente de IA a capacidade de consultar os docs atuais, ele para de adivinhar e começa a ser útil.

Três comandos, zero abas do navegador

A CLI é refrescantemente simples:

Listar todos os docs

aspire docs list

Retorna cada página de documentação disponível no aspire.dev. Precisa de saída legível por máquina? Adicione --format Json.

Pesquisar um tópico

aspire docs search "redis"

Pesquisa tanto em títulos quanto em conteúdo com pontuação de relevância ponderada. O mesmo motor de busca que alimenta a ferramenta de documentação internamente. Você obtém resultados ranqueados com títulos, slugs e scores de relevância.

Ler uma página inteira (ou apenas uma seção)

aspire docs get redis-integration

Transmite a página completa como markdown pro seu terminal. Precisa de apenas uma seção?

aspire docs get redis-integration --section "Add Redis resource"

Precisão cirúrgica. Sem rolar por 500 linhas. Só a parte que você precisa.

O ângulo do agente de IA

Aqui é onde fica interessante pra nós desenvolvedores que construímos com ferramentas de IA. Os mesmos comandos aspire docs funcionam como ferramentas para agentes de IA — através de skills, servidores MCP, ou wrappers simples de CLI.

Em vez do seu assistente de IA inventar APIs do Aspire baseadas em dados de treinamento desatualizados, ele pode chamar aspire docs search "postgres", encontrar os docs oficiais de integração, ler a página certa, e te dar a abordagem documentada. Documentação em tempo real e atualizada — não o que o modelo memorizou seis meses atrás.

A arquitetura por trás disso é intencional. O time do Aspire construiu serviços reutilizáveis (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) em vez de uma integração pontual. Isso significa que o mesmo motor de busca funciona para humanos no terminal, agentes de IA no seu editor, e automação no seu pipeline de CI.

Cenários do mundo real

Consultas rápidas no terminal: Você está três arquivos de profundidade e precisa dos parâmetros de configuração do Redis. Dois comandos, noventa segundos, de volta ao trabalho:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

Desenvolvimento assistido por IA: Seu skill do VS Code encapsula os comandos da CLI. Você pergunta “Adicione um banco de dados PostgreSQL ao meu AppHost” e o agente consulta os docs reais antes de responder. Sem alucinações.

Validação CI/CD: Seu pipeline valida configurações de AppHost contra documentação oficial programaticamente. A saída --format Json conecta-se limpo com jq e outras ferramentas.

Bases de conhecimento personalizadas: Construindo suas próprias ferramentas de IA? Envie a saída JSON estruturada direto pra sua base de conhecimento:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

Sem web scraping. Sem chaves de API. Os mesmos dados estruturados que a ferramenta de documentação usa internamente.

A documentação está sempre atualizada

Esta é a parte que mais aprecio. A CLI não baixa um snapshot — ela consulta o aspire.dev com cache baseado em ETag. No momento em que os docs são atualizados, sua CLI e qualquer skill construído sobre ela reflete isso. Sem cópias desatualizadas, sem momentos de “mas o wiki dizia…”.

Pra fechar

aspire docs é uma daquelas funcionalidades pequenas que resolve um problema real de forma limpa. Humanos ganham acesso à documentação direto no terminal. Agentes de IA ganham uma forma de parar de adivinhar e começar a referenciar docs reais. E tudo é sustentado pela mesma fonte de verdade.

Se você está construindo com .NET Aspire e ainda não experimentou a CLI, execute aspire docs search "seu-topico-aqui" e veja como é. Depois considere envolver esses comandos em qualquer skill de IA ou configuração de automação que está usando — seus agentes vão agradecer.

Confira o mergulho profundo de David Pine sobre como a ferramenta de documentação foi construída, e a referência oficial da CLI para todos os detalhes.

Microsoft Agent Framework Chega à 1.0 — Eis O Que Realmente Importa para Desenvolvedores .NET

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

Se você tem acompanhado a jornada do Agent Framework desde os primeiros dias do Semantic Kernel e AutoGen, este é significativo. O Microsoft Agent Framework acabou de chegar à versão 1.0 — pronto para produção, APIs estáveis, compromisso de suporte de longo prazo. Está disponível tanto para .NET quanto para Python, e está genuinamente pronto para cargas de trabalho reais.

Vou cortar o ruído do anúncio e focar no que importa se você está construindo apps com IA usando .NET.

A versão curta

Agent Framework 1.0 unifica o que costumava ser Semantic Kernel e AutoGen em um único SDK open source. Uma abstração de agente. Um motor de orquestração. Múltiplos provedores de IA. Se você estava alternando entre Semantic Kernel para padrões enterprise e AutoGen para workflows multi-agente de nível pesquisa, pode parar. Este é o único SDK agora.

Começar é quase injustamente simples

Aqui está um agente funcional em .NET:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

É isso. Um punhado de linhas e você tem um agente de IA rodando contra o Azure Foundry. O equivalente em Python é igualmente conciso. Adicione ferramentas de funções, conversas multi-turno e streaming conforme avança — a superfície da API escala sem ficar estranha.

Orquestração multi-agente — isso é pra valer

Agentes individuais são bons para demos, mas cenários de produção geralmente precisam de coordenação. Agent Framework 1.0 vem com padrões de orquestração testados em batalha diretamente da Microsoft Research e AutoGen:

Sequencial — agentes processam em ordem (escritor → revisor → editor)
Concorrente — distribui para múltiplos agentes em paralelo, converge resultados
Handoff — um agente delega para outro baseado na intenção
Chat em grupo — múltiplos agentes discutem e convergem para uma solução
Magentic-One — o padrão multi-agente de nível pesquisa do MSR

Todos suportam streaming, checkpointing, aprovações com humano no loop, e pausa/retomada. A parte de checkpointing é crucial — workflows de longa duração sobrevivem a reinícios de processo. Para nós desenvolvedores .NET que construímos workflows duráveis com Azure Functions, isso é familiar.

As funcionalidades que mais importam

Aqui está minha lista do que vale a pena saber:

Hooks de middleware. Sabe como o ASP.NET Core tem pipelines de middleware? Mesmo conceito, mas para execução de agentes. Intercepte cada estágio — adicione segurança de conteúdo, logging, políticas de compliance — sem tocar nos prompts do agente. É assim que você torna agentes prontos para enterprise.

Memória plugável. Histórico conversacional, estado persistente chave-valor, recuperação baseada em vetores. Escolha seu backend: Foundry Agent Service, Mem0, Redis, Neo4j, ou crie o seu próprio. Memória é o que transforma uma chamada LLM sem estado em um agente que realmente lembra do contexto.

Agentes YAML declarativos. Defina as instruções do seu agente, ferramentas, memória e topologia de orquestração em arquivos YAML versionados. Carregue e execute com uma única chamada de API. Isso é um divisor de águas para equipes que querem iterar no comportamento do agente sem reimplantar código.

Suporte A2A e MCP. MCP (Model Context Protocol) permite que agentes descubram e invoquem ferramentas externas dinamicamente. A2A (protocolo Agent-to-Agent) habilita colaboração entre runtimes — seus agentes .NET podem se coordenar com agentes rodando em outros frameworks. O suporte ao A2A 1.0 está chegando em breve.

As funcionalidades em preview que valem acompanhar

Algumas funcionalidades foram lançadas como preview na 1.0 — funcionais mas as APIs podem evoluir:

DevUI — um depurador local baseado em navegador para visualizar a execução do agente, fluxos de mensagens e chamadas de ferramentas em tempo real. Pense no Application Insights, mas para o raciocínio do agente.
GitHub Copilot SDK e Claude Code SDK — use o Copilot ou Claude como harness de agente diretamente do seu código de orquestração. Componha um agente capaz de programar ao lado dos seus outros agentes no mesmo workflow.
Agent Harness — um runtime local customizável que dá aos agentes acesso a shell, sistema de arquivos e loops de mensagens. Pense em agentes de código e padrões de automação.
Skills — pacotes reutilizáveis de capacidades de domínio que dão aos agentes capacidades estruturadas prontas para uso.

Migrando do Semantic Kernel ou AutoGen

Se você tem código existente de Semantic Kernel ou AutoGen, existem assistentes de migração dedicados que analisam seu código e geram planos de migração passo a passo. O guia de migração do Semantic Kernel e o guia de migração do AutoGen te guiam por tudo.

Se você estava nos pacotes RC, atualizar para 1.0 é apenas uma mudança de versão.

Finalizando

Agent Framework 1.0 é o marco de produção que as equipes enterprise estavam esperando. APIs estáveis, suporte multi-provedor, padrões de orquestração que realmente funcionam em escala, e caminhos de migração tanto do Semantic Kernel quanto do AutoGen.

O framework é totalmente open source no GitHub, e você pode começar hoje com dotnet add package Microsoft.Agents.AI. Confira o guia de início rápido e os exemplos para colocar a mão na massa.

Se você estava esperando o sinal de “seguro para usar em produção” — é este.

Atualização de março do Visual Studio permite criar agentes Copilot personalizados — e o find_symbol é revolucionário

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

O Visual Studio acabou de receber sua atualização Copilot mais significativa. Mark Downie anunciou a versão de março, e o destaque são os agentes personalizados — mas honestamente, a ferramenta find_symbol pode ser a que mais muda seu workflow.

Agentes Copilot personalizados no seu repo

Quer que o Copilot siga os padrões de código do seu time? Agentes personalizados são definidos como arquivos .agent.md em .github/agents/. Cada agente tem acesso completo ao workspace, compreensão de código, ferramentas, seu modelo preferido e conexões MCP.

Agent skills: pacotes de instruções reutilizáveis

Skills são carregados automaticamente de .github/skills/ no seu repo ou ~/.copilot/skills/ no seu perfil.

find_symbol: navegação com reconhecimento de linguagem

A nova ferramenta find_symbol dá ao modo agente do Copilot navegação de símbolos baseada em serviços de linguagem. Em vez de buscar texto, o agente pode encontrar todas as referências de um símbolo e acessar informações de tipo e escopo.

Para desenvolvedores .NET, é uma melhoria enorme — bases de código C# com hierarquias de tipos profundas se beneficiam enormemente.

Perfilar testes com Copilot

Há um novo Profile with Copilot no menu de contexto do Test Explorer. O Profiling Agent executa o teste e analisa performance automaticamente.

Perf tips durante debugging ao vivo

A otimização de performance agora acontece durante o debug. O Visual Studio mostra tempo de execução inline. Linha lenta? Clique no Perf Tip e peça sugestões ao Copilot.

Corrigir vulnerabilidades NuGet do Solution Explorer

Um link Fix with GitHub Copilot aparece diretamente no Solution Explorer quando uma vulnerabilidade é detectada.

Conclusão

Agentes personalizados e skills são o destaque, mas find_symbol é a joia escondida — muda fundamentalmente a precisão do Copilot ao refatorar código .NET. Baixe o Visual Studio 2026 Insiders para experimentar.

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.

O Dashboard do Aspire 13.2 agora tem uma API de telemetria — e isso muda tudo

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

Se você tem desenvolvido aplicações distribuídas com .NET Aspire, já sabe que o dashboard é a melhor coisa de toda a experiência. Todos os seus traces, logs e métricas em um só lugar — sem Jaeger externo, sem configuração de Seq, sem momentos de “deixa eu verificar o outro terminal”.

O Aspire 13.2 acabou de melhorar tudo significativamente. James Newton-King anunciou a atualização, e honestamente? Os recursos de exportação de telemetria e a API sozinhos justificam o upgrade.

Exportar telemetria de forma civilizada

Aqui está o cenário que todos já vivemos: você está depurando um problema distribuído, finalmente reproduz depois de vinte minutos de configuração, e agora precisa compartilhar o que aconteceu com o time. Antes? Screenshots. Copiar e colar IDs de traces. A bagunça de sempre.

O Aspire 13.2 adiciona um diálogo de Gerenciar logs e telemetria onde você pode:

Limpar toda a telemetria (útil antes de tentar reproduzir)
Exportar telemetria selecionada em um arquivo ZIP no formato padrão OTLP/JSON
Reimportar esse ZIP em qualquer dashboard Aspire depois

Esse último ponto é o recurso matador. Você reproduz um bug, exporta a telemetria, anexa ao seu work item, e seu colega pode importar no próprio dashboard para ver exatamente o que você viu. Acabou o “consegue reproduzir na sua máquina?”

Traces, spans e logs individuais também têm uma opção “Export JSON” nos menus de contexto. Precisa compartilhar um trace específico? Clique direito, copiar JSON, colar na descrição do PR. Pronto.

A API de telemetria é o verdadeiro divisor de águas

Isso é o que mais me empolga. O dashboard agora expõe uma API HTTP em /api/telemetry para consultar dados de telemetria programaticamente. Endpoints disponíveis:

GET /api/telemetry/resources — listar recursos com telemetria
GET /api/telemetry/spans — consultar spans com filtros
GET /api/telemetry/logs — consultar logs com filtros
GET /api/telemetry/traces — listar traces
GET /api/telemetry/traces/{traceId} — obter todos os spans de um trace específico

Tudo retorna no formato OTLP JSON. Isso alimenta os novos comandos CLI aspire agent mcp e aspire otel, mas a implicação real é maior: agora você pode construir ferramentas, scripts e integrações com agentes de IA que consultam a telemetria da sua app diretamente.

Imagine um agente de IA que pode ver seus traces distribuídos reais enquanto você depura. Isso não é mais hipotético — é o que esta API possibilita.

Telemetria GenAI fica prática

Se você está construindo apps com IA usando Semantic Kernel ou Microsoft.Extensions.AI, vai gostar do visualizador de telemetria GenAI melhorado. O Aspire 13.2 adiciona:

Descrições de ferramentas IA renderizadas como Markdown
Um botão dedicado de GenAI na página de traces para acesso rápido
Melhor tratamento de erros para JSON de GenAI truncado ou não padrão
Navegação click-to-highlight entre definições de ferramentas

O post menciona que VS Code Copilot chat, Copilot CLI e OpenCode suportam configurar um OTEL_EXPORTER_OTLP_ENDPOINT. Aponte-os para o dashboard Aspire e você pode literalmente assistir seus agentes IA pensando em tempo real pela telemetria. Essa é uma experiência de depuração que você não encontra em nenhum outro lugar.

Conclusão

O Aspire 13.2 transforma o dashboard de “UI bonita de depuração” para “plataforma de observabilidade programável”. O workflow de exportação/importação sozinho economiza tempo real na depuração distribuída, e a API de telemetria abre a porta para diagnósticos assistidos por IA.

Se você já usa Aspire, atualize. Se não — esta é uma boa razão para conhecer aspire.dev.

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.

VS Code 1.112: O que desenvolvedores .NET realmente deveriam se importar

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

VS Code 1.112 acabou de chegar, e honestamente? Este aqui bate diferente se você passa seus dias em território .NET. Tem muita coisa nas notas de versão oficiais, mas deixe-me poupar alguma rolagem e focar no que realmente importa para nós.

Copilot CLI ficou muito mais útil

O grande tema desta versão é a autonomia do agente — dar ao Copilot mais espaço para fazer seu trabalho sem você supervisionar cada passo.

Direcionamento e fila de mensagens

Sabe aquele momento quando o Copilot CLI está no meio de uma tarefa e você percebe que esqueceu de mencionar algo? Antes, você tinha que esperar. Agora pode enviar mensagens enquanto uma requisição ainda está em andamento — seja para direcionar a resposta atual ou enfileirar instruções de acompanhamento.

Isso é enorme para aquelas tarefas mais longas de scaffolding dotnet onde você está assistindo o Copilot configurar um projeto e pensa “oh espera, também preciso de MassTransit ali”.

Níveis de permissão

Este é o que mais me empolga. Sessões do Copilot CLI agora suportam três níveis de permissão:

Permissões padrão — o fluxo usual onde as ferramentas pedem confirmação antes de executar
Ignorar aprovações — auto-aprova tudo e tenta novamente em erros
Autopiloto — totalmente autônomo: aprova ferramentas, responde suas próprias perguntas e continua até a tarefa estar completa

Se você está fazendo algo como criar uma nova API ASP.NET Core com Entity Framework, migrations e setup Docker — o modo Autopiloto significa que você descreve o que quer e vai pegar um café. Ele vai resolver.

Você pode habilitar o Autopiloto com a configuração chat.autopilot.enabled.

Pré-visualizar mudanças antes de delegar

Quando você delega uma tarefa ao Copilot CLI, ele cria um worktree. Antes, se você tivesse mudanças não commitadas, tinha que verificar o Controle de Código Fonte para ver o que seria afetado. Agora a visualização do Chat mostra as mudanças pendentes ali mesmo antes de você decidir se copia, move ou ignora.

Coisa pequena, mas salva você daquele momento de “espera, o que eu tinha no staging?”.

Depure apps web sem sair do VS Code

O navegador integrado agora suporta depuração completa. Você pode colocar breakpoints, fazer step through do código e inspecionar variáveis — tudo dentro do VS Code. Acabou o trocar para Edge DevTools.

Há um novo tipo de debug editor-browser, e se você já tem configurações de lançamento msedge ou chrome existentes, migrar é tão simples quanto mudar o campo type no seu launch.json:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Para desenvolvedores Blazor, isso é um divisor de águas. Você já está executando dotnet watch no terminal — agora sua depuração fica na mesma janela também.

O navegador também ganhou níveis de zoom independentes (finalmente), menus de contexto com clique direito apropriados, e o zoom é lembrado por site.

Sandboxing de servidores MCP

Isso importa mais do que você imagina. Se você está usando servidores MCP — talvez tenha configurado um personalizado para seus recursos Azure ou consultas de banco de dados — eles estavam rodando com as mesmas permissões do seu processo VS Code. Isso significa acesso total ao seu sistema de arquivos, rede, tudo.

Agora você pode colocá-los em sandbox. No seu mcp.json:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

Quando um servidor em sandbox precisa de acesso a algo que não tem, o VS Code solicita que você conceda permissão. Muito melhor que a abordagem de “torcer para ninguém fazer nada estranho”.

Descoberta de personalizações em monorepos

Se você trabalha em um monorepo (e sejamos honestos, muitas soluções .NET empresariais acabam virando um), isso resolve um ponto de dor real.

Anteriormente, se você abria uma subpasta do seu repositório, o VS Code não encontrava seu copilot-instructions.md, AGENTS.md, ou skills personalizados na raiz do repositório. Agora com a configuração chat.useCustomizationsInParentRepositories, ele sobe até a raiz .git e descobre tudo.

Isso significa que seu time pode compartilhar instruções de agente, arquivos de prompt e ferramentas personalizadas entre todos os projetos em um monorepo sem que todos precisem abrir a pasta raiz.

/troubleshoot para depuração de agentes

Já configurou instruções personalizadas ou skills e se perguntou por que não estão sendo detectados? O novo skill /troubleshoot lê os logs de depuração do agente e te diz o que aconteceu — quais ferramentas foram usadas ou puladas, por que as instruções não carregaram, e o que está causando respostas lentas.

Habilite com:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

Então simplesmente digite /troubleshoot why is my custom skill not loading? no chat.

Você também pode exportar e importar esses logs de depuração agora, o que é ótimo para compartilhar com seu time quando algo não está funcionando como esperado.

Suporte a arquivos de imagem e binários

Agentes agora podem ler arquivos de imagem do disco e arquivos binários nativamente. Os arquivos binários são apresentados em formato hexdump, e saídas de imagem (como capturas de tela do navegador integrado) aparecem em uma visualização de carrossel.

Para desenvolvedores .NET, pense: cole uma captura de tela de um bug de UI no chat e faça o agente entender o que está errado, ou faça-o analisar a saída de renderização de um componente Blazor.

Referências automáticas de símbolos

Pequena melhoria de qualidade de vida: quando você copia o nome de um símbolo (uma classe, método, etc.) e cola no chat, o VS Code agora automaticamente converte em uma referência #sym:Name. Isso dá ao agente contexto completo sobre aquele símbolo sem você ter que adicioná-lo manualmente.

Se quiser texto puro, use Ctrl+Shift+V.

Plugins agora podem ser habilitados/desabilitados

Anteriormente, desabilitar um servidor MCP ou plugin significava desinstalá-lo. Agora você pode ligá-los e desligá-los — tanto globalmente quanto por workspace. Clique direito na visualização de Extensões ou na visualização de Personalizações e pronto.

Plugins de npm e pypi também podem se auto-atualizar agora, embora peçam aprovação primeiro já que atualizações significam executar código novo na sua máquina.

Para finalizar

VS Code 1.112 está claramente empurrando forte na experiência do agente — mais autonomia, melhor depuração, segurança mais apertada. Para desenvolvedores .NET, a depuração do navegador integrado e as melhorias do Copilot CLI são as funcionalidades destaque.

Se você ainda não experimentou rodar uma sessão completa do Copilot CLI em modo Autopiloto para um projeto .NET, esta versão é um bom momento para começar. Só lembre de configurar suas permissões e deixar cozinhar.

Baixar VS Code 1.112 ou atualizar de dentro do VS Code via Ajuda > Verificar Atualizações.

Ai | The .NET Blog

NL2SQL é a Injeção SQL da Era Agêntica

Os Problemas sobre os quais Ninguém Fala na Demo

O que o SQL MCP Server Realmente Resolve

A Pergunta Certa

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

O Padrão Handoff: Quando Um Agente Não É Suficiente

Como Handoff Funciona

Um Exemplo Mínimo

Quando Usar Handoff (e Quando Não)

Arestas de Retorno e Human-in-the-Loop

Conclusão

Workflows Duráveis no Microsoft Agent Framework: De In-Memory ao Azure Functions

Os Blocos de Construção Fundamentais

O Runner In-Memory para Desenvolvimento Local

Adicionando Durabilidade com Durable Task

Hospedagem no Azure Functions

Por Que Isso Importa

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

Construir Agentes É a Parte Fácil — Executá-los com Segurança É a Parte Difícil

O Que Cada Projeto Realmente Faz

Conectar-se É Apenas Adicionar Middleware

O Que Você Obtém

Cinco Cenários da Indústria

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

Azure SQL Agora Pode Gerar Embeddings — Em T-SQL Puro, Sem Camada de Aplicação

O Que Elas Fazem

O Fluxo de Trabalho Completo

Formatos de API e Opções Suportadas

O Que Isso Habilita para Aplicações .NET

Conclusão

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

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

Construindo um app de conferência com IA com a stack componível do .NET

O que o ConferencePulse faz

Microsoft.Extensions.AI: uma abstração para tudo

Pipeline de DataIngestion

VectorData: busca independente do provedor

MCP: conteúdo da sessão como ferramentas

Agent Framework: resumo multi-agente em paralelo

O princípio de design

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

O que é um Agente (vs. um Chatbot)

O Fluxo de Implantação com `azd`