Agents | 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?

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

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.

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.

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

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

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.

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

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

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.

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

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

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

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

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

O que é Azure MCP Server?

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

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

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

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

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

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

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

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

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

Endurecimento de segurança

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

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

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

Onde você pode usá-lo?

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

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

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

Por que isso importa para desenvolvedores .NET

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

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

Começando

Escolha seu caminho:

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

Resumindo

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

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

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

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

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

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

O que o Git-APE realmente faz

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

Aqui está a configuração:

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

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

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

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

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

Por que isso importa

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

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

A limpeza é igualmente simples:

@git-ape destroy my-resource-group

Minha opinião

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

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

Concluindo

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

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

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.

VS Code 1.116 — App de Agentes Ganha Navegação por Teclado e Autocompletação de Contexto de Arquivos

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

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

VS Code 1.116 é a versão de abril de 2026, e embora seja mais leve que algumas atualizações recentes, as mudanças são focadas e significativas — especialmente se você está usando a app de Agentes diariamente.

Aqui está o que chegou, baseado nas notas de versão oficiais.

Melhorias na app de Agentes

A app de Agentes continua amadurecendo com polimento de usabilidade que faz uma diferença real nos fluxos de trabalho diários:

Atalhos de teclado dedicados — agora você pode focar a visualização de Mudanças, a árvore de arquivos dentro de Mudanças e a visualização de Personalizações do Chat com comandos e atalhos de teclado dedicados. Se você estava clicando pela app de Agentes para navegar, isso traz fluxos de trabalho totalmente controlados por teclado.

Diálogo de ajuda de acessibilidade — pressionar Alt+F1 na caixa de entrada do chat agora abre um diálogo de ajuda de acessibilidade mostrando comandos e atalhos disponíveis. Usuários de leitores de tela também podem controlar a verbosidade dos anúncios. Boa acessibilidade beneficia a todos.

Autocompletação de contexto de arquivos — digite # no chat da app de Agentes para ativar autocompletação de contexto de arquivos no seu workspace atual. Esta é uma daquelas pequenas melhorias de qualidade de vida que aceleram cada interação — chega de digitar caminhos completos de arquivos ao referenciar código.

Resolução de links CSS `@import`

Uma boa para desenvolvedores frontend: VS Code agora resolve referências CSS @import que usam caminhos de node_modules. Você pode fazer Ctrl+clique através de imports como @import "some-module/style.css" ao usar bundlers. Pequeno, mas elimina um ponto de atrito nos fluxos de trabalho CSS.

Conclusão

VS Code 1.116 é sobre refinamento — tornar a app de Agentes mais navegável, mais acessível e mais amigável ao teclado. Se você passa tempo significativo na app de Agentes (e suspeito que muitos de nós passamos), essas mudanças se acumulam.

Confira as notas de versão completas para a lista completa.

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

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

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.

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.

Agents | 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

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

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

O que é CodeAct?

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

Configuração mínima

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

Experimente agora

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

Dois padrões fundamentais

Como o Agent Framework abstrai isso

Referência rápida de provedores

Como escolher

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

O que é um Toolbox?

Os quatro pilares (dois disponíveis hoje)

Exemplo prático

Sem lock-in no Foundry Agents

Por que importa agora

Conclusão

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

O modo Autopilot finalmente lembra sua preferência

Worktree e isolamento git para sessões de agentes

Subagentes e equipes de agentes

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

O app Agents no macOS se atualiza sozinho

As coisas menores que vale a pena saber

A conclusão

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

As seis opções de relance

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

Deploy é genuinamente simples

Gerenciamento de conversas integrado

Meu framework de decisão

Para finalizar

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

O que é Azure MCP Server?

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

Endurecimento de segurança

Onde você pode usá-lo?

Por que isso importa para desenvolvedores .NET

Começando

Resumindo

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

O que o Git-APE realmente faz

Por que isso importa

Minha opinião

Concluindo

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

VS Code 1.116 — App de Agentes Ganha Navegação por Teclado e Autocompletação de Contexto de Arquivos

Melhorias na app de Agentes

Resolução de links CSS @import

Conclusão

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

Executar e depurar agentes IA sem fazer deploy

GitHub Copilot configura seu projeto azd

Container App Jobs e melhorias de deploy

Melhorias de DX

Conclusão

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

Resolução de links CSS `@import`