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.

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.

Microsoft-Foundry | The .NET Blog