Foundry | The .NET Blog

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

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

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

Foundry Local está Geralmente Disponível

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

GPT-5.5

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

Rastreamento do Agent Framework no Foundry

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

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

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

CodeAct com Hyperlight (Alpha)

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

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

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

Painel de Monitoramento de Agentes (Preview)

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

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

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

Inventário de Agentes no Plano de Controle

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

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

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

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

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

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

O Que o Foundry Hosted Agents Realmente Faz

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

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

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

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

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

Em .NET:

using Microsoft.Agents.AI.Foundry.Hosting;

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

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

app.Run();

Em Python:

server = ResponsesHostServer(agent)
server.run()

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

Dois Protocolos, Um Agente

Os Hosted Agents suportam dois estilos de endpoints:

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

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

O Fluxo de Implantação com `azd`

Quando você executa azd up com um agente MAF:

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

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

Conclusão

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

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

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

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

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

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

Transcrição de Áudio em Directo

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

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

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

Embeddings de Texto

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

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

API de Respostas

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

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

Melhorias no Tamanho do Pacote

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

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

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

Por Que Importa

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

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

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

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

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 RFT do Foundry ficou mais barato e inteligente — Veja o que mudou

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

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

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.

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

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

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

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.

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

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

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.

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)

Se você vem do pacote azure-ai-agents, os agentes agora são operações de primeira classe no AIProjectClient em azure-ai-projects. Remova a dependência standalone e use get_openai_client() para conduzir as respostas.

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.

Foundry | The .NET Blog

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

Foundry Local está Geralmente Disponível

GPT-5.5

Rastreamento do Agent Framework no Foundry

CodeAct com Hyperlight (Alpha)

Painel de Monitoramento de Agentes (Preview)

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

Inventário de Agentes no Plano de Controle

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

O Que o Foundry Hosted Agents Realmente Faz

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

Dois Protocolos, Um Agente

O Fluxo de Implantação com azd

Conclusão

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

Transcrição de Áudio em Directo

Embeddings de Texto

API de Respostas

Melhorias no Tamanho do Pacote

Por Que Importa

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

A progressão do GPT-5

O que realmente mudou

Preços

Por que o Foundry importa

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

Treinamento Global para o4-mini

Novos Avaliadores de Modelo: Família GPT-4.1

A Pegadinha do Formato de Dados do RFT

Por Que Isso Importa para Desenvolvedores .NET

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

Por que essa combinação faz sentido

Opções de autenticação

Configurando

Minha opinião

Finalizando

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

Foundry Agent Service está pronto para produção

GPT-5.4 — confiabilidade acima de inteligência pura

O SDK finalmente está estável

Fireworks AI traz modelos abertos para o Azure

Outros destaques

Conclusão

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

O que está realmente acontecendo aqui

Configurando

Controlando o que seu agente pode acessar

Por que isso é interessante para equipes .NET

O panorama maior do MCP

Para finalizar

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

O novo fluxo de trabalho azd ai agent

O que acontece por baixo dos panos

O ciclo interno de desenvolvimento

Monitoramento em tempo real

O conjunto completo de comandos

Por que isso importa para desenvolvedores .NET

Para finalizar

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

Construído sobre a Responses API

Rede privada: o bloqueador empresarial removido

Autenticação MCP feita direito

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

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

Seis novas regiões para agentes hospedados

Por que isso importa para desenvolvedores .NET

Para finalizar

O Fluxo de Implantação com `azd`

O novo fluxo de trabalho `azd ai agent`