Agentes Não São Ferramentas — Mas Às Vezes Deveriam Ser

Existe um debate acontecendo na comunidade de engenharia de IA que parece técnico, mas é fundamentalmente arquitetural. A pergunta: agentes são ferramentas, ou são algo categoricamente diferente?

A resposta rápida é “são diferentes.” A resposta correta é “depende do que você está construindo.” E a resposta que realmente importa é: “seu sistema sabe a diferença?”

O Argumento Original

Philip Stephens publicou recentemente no Google Dev Forum um artigo chamado “Agents Are Not Tools” que merece atenção. O argumento central é preciso: ferramentas e agentes operam sob contratos fundamentalmente distintos.

Ferramentas seguem uma sequência temporal definida. Requisição, ação, conclusão ou erro. Entradas estruturadas, saídas estruturadas, domínio limitado. Você chama uma função, ela retorna um resultado. O fluxo de controle permanece com quem chamou.

Agentes lidam com estados incompletos, requisitos que mudam no meio da execução, interações que se estendem por múltiplos turnos. A ação não é garantida de ser completada no retorno. O agente pode pedir esclarecimento, delegar para outro agente, ou descobrir que o problema original era diferente do que se imaginava.

Stephens usa uma analogia provocativa: interfaces de agente são comparáveis a instruções GOTO na programação. Ambas perturbam o fluxo de execução esperado. Ambas introduzem imprevisibilidade no sistema.

A formulação mais elegante do artigo é esta: “A interface de ferramenta é um caso degenerativo da interface de agente.” Agentes podem se comportar como ferramentas quando o cenário exige apenas um turno. Ferramentas não podem se comportar como agentes.

Por Que Isso Não É Apenas Teoria

Se a distinção fosse puramente acadêmica, não mereceria um artigo. Mas dois protocolos de infraestrutura demonstram que a indústria já está codificando essa separação.

MCP (Model Context Protocol), lançado pela Anthropic em novembro de 2024, resolve a integração vertical — agente conecta a ferramentas, dados e serviços. É o protocolo que permite a um agente chamar uma API, consultar um banco de dados ou executar um comando. A adoção foi explosiva: de 100 mil downloads no lançamento para 97 milhões de downloads mensais do SDK ao final de 2025.

A2A (Agent-to-Agent), lançado pelo Google em abril de 2025, resolve a integração horizontal — agente comunica com agente. É o protocolo que permite a um agente de planejamento de viagem negociar com agentes de voo, hotel e locação, cada um operando com autonomia e estado próprios.

Ambos foram doados para a Agentic AI Foundation da Linux Foundation em dezembro de 2025. Não são propostas experimentais. São infraestrutura de produção.

A distinção importa porque os dados confirmam a direção. A Gartner registrou um aumento de 1.445% em consultas sobre sistemas multi-agente entre o primeiro trimestre de 2024 e o segundo trimestre de 2025. A Databricks documentou crescimento de 327% em workflows multi-agente. O mercado não está debatendo se agentes são diferentes de ferramentas. Está construindo infraestrutura separada para cada um.

O Exemplo Que Clarifica

Stephens usa o exemplo de um sistema de planejamento de viagem para ilustrar a diferença. Vale expandir, porque o exemplo revela algo que muitos engenheiros intuem mas raramente articulam.

Um sistema baseado em ferramentas para planejar uma viagem funciona assim: o usuário fornece parâmetros completos (origem, destino, datas, orçamento), o sistema chama APIs de voo, hotel e carro, retorna resultados. Previsível, testável, confiável.

Um sistema baseado em agentes funciona assim: o usuário diz “preciso ir a São Paulo na próxima semana para uma reunião.” O agente de orquestração percebe que faltam informações. Delega para o agente de voo, que descobre que os voos diretos estão esgotados e propõe conexões. O agente de hotel percebe que a reunião é no Itaim Bibi e sugere opções próximas. O agente de orquestração nota que a combinação de voo com conexão e hotel perto da reunião ultrapassa o orçamento e volta ao usuário com alternativas. O problema original — “preciso ir a São Paulo” — foi redefinido ao longo da execução.

A diferença não é de complexidade. É de contrato. No sistema de ferramentas, o fluxo de controle é linear e retorna ao chamador. No sistema de agentes, o controle migra entre agentes, cada um com capacidade de redefinir o problema.

Onde Stephens Está Certo — E Onde a Realidade Complica

O argumento de Stephens está correto no nível conceitual. Tratar agentes como ferramentas — esperar retorno síncrono, respostas completas, fluxo linear — produz sistemas frágeis que quebram no primeiro cenário imprevisto.

Mas a prática de construir sistemas de produção revela uma nuance que o artigo não explora: às vezes, tratar agentes como ferramentas é a abstração correta.

Operamos uma equipe multi-agente na Victorino Group. Temos agentes com papéis definidos — CEO, CTO, estrategista de marketing, líderes técnicos. Eles se comunicam, delegam, redefinem problemas. Esse é o modo agente. Mas quando um agente precisa executar uma tarefa bem definida dentro de um fluxo maior — gerar um relatório, validar um schema, verificar conformidade — ele opera como ferramenta. Entrada definida, saída definida, sem negociação.

A questão prática não é “agente ou ferramenta?” É “quando cada padrão se aplica?”

Os Três Regimes

Depois de construir e operar sistemas multi-agente em produção, identificamos três regimes distintos onde a escolha de padrão muda.

Regime 1: Execução Determinística

Quando usar ferramentas. A tarefa tem entradas e saídas conhecidas. O domínio é limitado. Falha significa erro, não redefinição do problema.

Exemplos: validação de dados, transformação de formato, consultas a APIs estruturadas, cálculos financeiros.

Usar agente aqui é over-engineering. Adiciona latência, imprevisibilidade e custo sem benefício proporcional.

Regime 2: Resolução Adaptativa

Quando usar agentes. A tarefa envolve descoberta, os requisitos podem mudar, múltiplas interações são esperadas.

Exemplos: análise de incidentes em produção, planejamento de projetos complexos, investigação de problemas em sistemas distribuídos.

Usar ferramenta aqui produz sistemas frágeis. A rigidez quebra no primeiro cenário que não foi previsto antecipadamente.

Regime 3: Composição Híbrida

Quando ambos são necessários. O sistema precisa de orquestração agêntica no nível macro e execução de ferramenta no nível micro.

Este é o regime onde a maioria dos sistemas de produção realmente opera. Um agente de orquestração decide o que fazer, delega para agentes especializados que decidem como fazer, e esses agentes usam ferramentas para executar. Três camadas, dois padrões, um sistema.

A equipe do Azure SRE Agent chegou à mesma conclusão por um caminho diferente: começaram com 100+ ferramentas estreitas, descobriram que o sistema era frágil, colapsaram para poucos agentes generalistas com ferramentas amplas. A composição híbrida emergiu da prática, não da teoria.

A Analogia GOTO — E Seus Limites

Stephens compara interfaces de agente a instruções GOTO. A analogia é produtiva até certo ponto. Assim como GOTO transfere controle de forma imprevisível, uma chamada de agente transfere controle sem garantia de quando ou como ele retorna.

Mas a analogia tem um limite importante. A solução para GOTO foi programação estruturada — funções, loops, condicionais que encapsulam fluxo de controle. A solução para agentes descontrolados não é eliminar agentes. É criar abstrações que encapsulam a complexidade agêntica.

É exatamente o que protocolos como MCP e A2A fazem. Eles não eliminam a distinção entre agentes e ferramentas. Eles fornecem interfaces estáveis para cada padrão. MCP padroniza como agentes consomem ferramentas. A2A padroniza como agentes se comunicam entre si.

A programação estruturada não eliminou os saltos de controle. Ela os tornou gerenciáveis. Os protocolos de infraestrutura agêntica fazem o mesmo.

Implicações Para o Design de Sistemas

Se você está construindo sistemas agênticos, três princípios emergem dessa discussão.

Primeiro: projete para ambos os modos. Seu sistema precisa operar tanto no modo ferramenta (síncrono, determinístico, previsível) quanto no modo agente (assíncrono, adaptativo, multi-turno). A arquitetura deve suportar os dois sem forçar tudo em um padrão único.

Segundo: torne a transição explícita. Quando um componente muda de modo ferramenta para modo agente — quando passa de “executar esta tarefa definida” para “resolver este problema aberto” — essa transição deve ser visível no sistema. Logs, métricas, contratos de interface. Se a transição é implícita, você perdeu observabilidade.

Terceiro: o padrão default deve ser ferramenta. Agentes introduzem complexidade, latência e imprevisibilidade. Só devem ser usados quando o problema exige. Como Stephens corretamente observa, a interface de ferramenta é um caso degenerativo da interface de agente. Comece pelo caso simples e escale para o complexo apenas quando necessário.

O Que Realmente Está em Jogo

O debate “agentes vs ferramentas” parece uma questão de taxonomia. Não é. É uma questão de consciência arquitetural.

Sistemas que tratam tudo como ferramenta são frágeis — quebram quando o mundo é mais complexo do que o previsto. Sistemas que tratam tudo como agente são imprevisíveis — custam mais, demoram mais e são mais difíceis de depurar.

Sistemas que sabem quando usar cada padrão são os que chegam a produção e permanecem lá.

O verdadeiro insight do artigo de Stephens não é que agentes não são ferramentas. É que a indústria precisa de consciência sobre quando cada padrão se aplica. Os protocolos existem. A infraestrutura está sendo construída. A pergunta que resta é se os times de engenharia estão projetando seus sistemas com essa distinção em mente — ou se estão forçando tudo em um único paradigma e esperando que funcione.

Na nossa experiência, a resposta é quase sempre a segunda opção. E o custo aparece em produção.

Na Victorino Group, construímos e operamos sistemas multi-agente com governança integrada. Se você está projetando arquiteturas agênticas e precisa de clareza sobre quando usar cada padrão, vamos conversar: contato@victorino.com.br | www.victorino.com.br

Fontes: “Agents Are Not Tools” de Philip Stephens (Google Dev Forum, junho 2025); Google A2A Protocol (abril 2025); Anthropic MCP (novembro 2024); Agentic AI Foundation — Linux Foundation (dezembro 2025); dados de adoção do Gartner e Databricks.