Azure AI Foundry Agent Service e tool use em produção
TL;DR
Em 2026, o Azure AI Foundry Agent Service se posiciona como uma camada gerenciada para construir e operar agents que usam ferramentas sem que o time precise montar, do zero, a infraestrutura de execução. Isso importa porque o serviço concentra hosting, escala, identidade, observabilidade e segurança, enquanto o agente decide quando chamar cada tool.
Na prática, o ganho é reduzir a parte “plataforma” do projeto e focar na lógica do agente, no catálogo de ferramentas e nas integrações com sistemas internos ou servidores MCP. Para times brasileiros, isso pesa ainda mais quando o custo e a latência de manter infraestrutura própria em nuvens com faturamento em dólar entram na conta.
O que muda com uma camada de execução gerenciada
O ponto central do Foundry Agent Service é que ele não é só um lugar para registrar prompts. A documentação o descreve como um serviço “fully managed” para construir, publicar e escalar agents, assumindo hosting, scaling, identity, observability and enterprise security. Isso muda a responsabilidade arquitetural: em vez de você gerenciar o runtime, o serviço passa a operar a base onde o agent roda.
Esse detalhe é o que faz sentido chamar de managed execution layer. A lógica do agente continua sua, mas a execução vive em uma camada com identidade própria, endpoint dedicado e integração com o ecossistema do Azure. Para produção, isso reduz a fricção entre prototipar um agent e colocá-lo em um fluxo real de negócio.
Por que isso afeta tool use
Quando um agent chama ferramentas, o gargalo normalmente não é só o modelo. É também autenticação, roteamento, disponibilidade da infraestrutura e observabilidade das chamadas. No Foundry Agent Service, o catálogo de ferramentas organiza esse uso: o modelo decide quando invocar uma tool com base nas instruções e nas definições disponíveis, incluindo ferramentas built-in e customizadas (tool catalog).
Na prática, isso cria uma separação útil. O time define as tools, o catalog gerencia o que está disponível, e o serviço cuida da operação da camada onde essas decisões são executadas. Para um use case de suporte interno, por exemplo, o agent pode consultar um sistema de chamados, buscar dados em uma base indexada e devolver uma resposta sem que você precise embrulhar cada integração em uma aplicação autônoma diferente.
Catálogo de ferramentas: o ponto de controle do agente
O tool catalog é o mecanismo declarativo que deixa explícito o que o agent pode usar. A documentação separa ferramentas built-in e custom, e indica que a chamada acontece quando o modelo julga necessário a partir das instruções e das definições associadas tool catalog.
Esse desenho é importante porque evita espalhar lógica de integração pelo código do app. Em vez de cada funcionalidade depender de um wrapper diferente, o agent recebe um conjunto de capacidades e escolhe a ferramenta adequada no contexto da conversa ou da tarefa. Em produção, isso tende a facilitar governança, auditoria e evolução do bot para assistente operacional.
Tool use em produção pede previsibilidade
Em cenário real, tool use só vira vantagem quando a operação é previsível. Se o agent depende de identity, logging e controle de permissão, essas peças precisam estar no mesmo plano da execução. É aqui que a proposta do serviço é prática: ele absorve as preocupações de plataforma para que o time concentre revisão de instruções, desenho de catálogo e limites de acesso.
Isso também se conecta com a operação diária. Um agent sem observabilidade clara vira uma caixa-preta difícil de depurar quando uma tool falha, um serviço downstream retorna erro ou uma permissão está incompleta. Como o Foundry Agent Service já declara observabilidade como parte da responsabilidade do serviço, a depuração fica mais próxima do produto e menos da infraestrutura artesanal overview.
MCP: como integrar ferramentas remotas
Uma das partes mais interessantes da história é a integração via MCP. O Foundry Agent Service documenta a conexão com servidores remotos de MCP usando o tool mcp, com autenticação via project connection e suporte a endpoints externos Model Context Protocol. Isso abre caminho para expor capacidades de sistemas legados, serviços internos e conectores especializados sem reescrever tudo dentro do agent.
O valor prático é simples: seu agent não precisa “conhecer” cada sistema pelo detalhe da implementação. Ele fala com um servidor MCP e recebe uma interface de ferramenta já organizada. Para times que lidam com múltiplos backends, isso reduz a fragmentação entre integrações e melhora a separação entre o domínio do agent e o domínio dos serviços.
Autenticação e operação ficam centralizadas
Em produção, a parte chata de tool use costuma ser segurança. O Foundry Agent Service descreve suporte a conexão autenticada com servidores MCP remotos, usando project connection para amarrar o acesso documentação de MCP. Isso ajuda a evitar credenciais espalhadas em vários lugares e simplifica a gestão de acesso.
Para uma empresa brasileira que precisa alinhar IAM, auditoria e requisitos internos de segurança, essa centralização vale ouro. Não é só conveniência técnica: é também menos superfície para erro operacional, algo que pesa quando a equipe precisa demonstrar controle sobre acesso a dados e integrações que podem tocar informação pessoal sob regras como a LGPD.
Hosted agents: execução com identidade própria
O conceito de hosted agents é a peça que mais claramente representa a camada de execução gerenciada. Na documentação, o serviço faz o pull da imagem, provisiona compute, atribui uma Microsoft Entra ID dedicada ao agent e expõe um endpoint específico hosted agents. Em outras palavras, o runtime passa a existir como recurso gerenciado, não como “script solto” em uma VM improvisada.
Isso é útil quando o agent precisa chamar ferramentas ou serviços downstream com uma identidade consistente. Em vez de depender de credenciais embarcadas na aplicação, o próprio serviço administra a identidade do agent. Para produção, isso encaixa bem em cenários de automação corporativa, onde rastreabilidade e segregação de acesso importam tanto quanto a resposta do modelo.
Esta seção descreve a arquitetura atual do Azure AI Foundry Agent Service. APIs e fluxos de agentes mudam rápido — confira a documentação oficial antes de adotar em produção.
Como pensar arquitetura de produção em 2026
Se você for traduzir isso para uma arquitetura prática, a separação fica mais ou menos assim: o agent decide, o catálogo expõe, o MCP conecta e o serviço executa. O time desenvolve a lógica do comportamento, registra as ferramentas e controla as permissões. A plataforma operacional do Azure entra como camada gerenciada de hospedagem, escala e observabilidade overview.
Esse desenho também conversa com frameworks. A própria documentação indica que hosted agents podem ser construídos com Agent Framework, LangGraph ou código próprio Microsoft Learn. Isso reduz o risco de aprisionamento em um único estilo de implementação, porque a camada gerenciada fica abaixo da lógica de orquestração.
Onde esse modelo ajuda de verdade
Ele ajuda quando você quer sair do protótipo e chegar a algo auditável. Em bancos, seguradoras, varejo e SaaS B2B no Brasil, a preocupação quase nunca é apenas “o agent responde?”. É também “quem chamou o quê?”, “com qual identidade?”, “em qual serviço?”, “com qual rastreabilidade?”. A camada gerenciada responde a essas perguntas com muito mais disciplina do que uma montagem caseira de containers e filas.
Também ajuda no custo de operação. Para times que pagam cloud em dólar e precisam caber no orçamento em BRL, reduzir o volume de peças infra que precisam ser mantidas manualmente é relevante. Menos componentes próprios significa menos horas gastas em manutenção de runtime, mais foco em valor de produto e menos risco de uma pipeline de agent virar passivo operacional.
Por que importa pro dev brasileiro
O ângulo brasileiro aqui não é decorativo. Em muitas empresas do Brasil, especialmente SaaS, fintechs e times internos de produtos digitais, a pressão por governança vem junto com restrições de orçamento e de pessoal. Além disso, a LGPD exige disciplina com dados pessoais e com o caminho que esses dados percorrem, o que torna especialmente valiosa uma camada que concentre identidade, observabilidade e controle de acesso.
Há também um fator operacional bem concreto: boa parte dos sistemas corporativos brasileiros ainda convive com integrações legadas, múltiplos fornecedores e janelas de manutenção apertadas. Nesse cenário, adotar uma camada gerenciada para tool use reduz a chance de a equipe gastar tempo demais sustentando infra de agent em vez de entregar automações que realmente ajudam o negócio.
Conclusão
O Azure AI Foundry Agent Service mostra uma direção clara para 2026: tirar do time a responsabilidade de montar a base de execução de agents e deixar a orquestração operacional com o serviço. O resultado é um modelo mais coerente para produção, especialmente quando o projeto depende de tools, MCP, identidade dedicada e observabilidade.
Se você trabalha com agents em produção, a melhor forma de validar isso em menos de uma hora é abrir a documentação oficial do tool catalog e do MCP, depois mapear uma integração real do seu sistema atual para uma tool remota. Esse exercício já deixa visível se o seu caso pede uma camada gerenciada ou se ainda está no estágio de protótipo local.
Conteúdos da DIO para quem quer aprofundar
- Aceleração Microsoft AI Agents — Acelere a sua ligação com a IA em um evento prático, ao vivo e com reconhecimento da Microsoft, com foco em agentes e ferramentas de IA para o desenvolvimento.
- Microsoft Certification Challenge #5 - AI 102 — Bootcamp voltado à certificação AI-102, com projeto de solução de IA no Azure e uso de ferramentas da plataforma.
- Microsoft AI for Tech - OpenAI Services — Formação para integrar serviços de OpenAI no Azure e criar aplicações com IA em cenários de backend e cloud.
- Formação AI-102 Certification — Trilha para quem quer dominar a criação e implantação de soluções inteligentes com Azure AI e Azure OpenAI Service.
- Microsoft AI for Tech - GitHub Copilot — Conteúdo prático sobre o uso do GitHub Copilot para acelerar o desenvolvimento e automatizar tarefas do dia a dia.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
