O Papel das Ferramentas (Tools) em Agentes de IA

Artigo 4 da Série IA Agêntica: Sistemas que Percebem, Decidem e Agem

< Artigo Anterior | Próximo artigo >

Imagine contratar um consultor brilhante, alguém com conhecimento enciclopédico sobre finanças, medicina, direito, programação. Mas esse consultor nunca pode acessar a internet, não pode ligar para ninguém, não pode abrir um documento, não pode fazer uma transferência bancária. Ele só pode falar.

Esse consultor seria útil? Sim. Mas seria poderoso? Definitivamente não.

Esse é exatamente o problema de um LLM sem ferramentas.

No artigo anterior, vimos a anatomia de um agente de IA: percepção, memória, planejamento e ação. As ferramentas vivem na camada de ação, e sem elas, o agente está preso dentro de si mesmo.

Um LLM, por natureza, é uma máquina de completar texto. Dado um input, ele gera um output textual. O modelo produz texto e só isso. Permanece inerte ao mundo externo, alheio ao que acontece depois de responder.

Isso não é um defeito, é simplesmente o que um modelo de linguagem é. O que muda tudo é o que colocamos ao redor dele.

O Que São Tools (Ferramentas)?

No contexto de agentes de IA, uma tool é qualquer função, API ou automação que o agente pode invocar para interagir com o mundo externo ou executar uma tarefa concreta.

Pense como um menu de capacidades. O agente, ao processar uma tarefa, pode “pedir” para executar uma ou mais ferramentas, receber o resultado e continuar seu raciocínio com base nessa nova informação.

Exemplos concretos de tools:

Cada uma dessas ferramentas é uma ponte entre o mundo do texto e o mundo real.

Como o Agente Usa uma Ferramenta?

O agente não executa as ferramentas diretamente. O que ele faz é declarar a intenção de usar uma ferramenta em um formato estruturado. O sistema ao redor do agente (o orchestrator) então executa a ferramenta de verdade e devolve o resultado para o agente.

O fluxo é assim:

Na prática, quando você usa um modelo como o Claude ou o GPT com tools habilitadas, o modelo aprende a emitir chamadas de função em um formato JSON estruturado. O framework (LangChain, LlamaIndex, CrewAI, ou um sistema customizado) intercepta essa saída, executa a função correspondente e injeta o resultado de volta no contexto do modelo.

O modelo então lê o resultado da ferramenta como mais contexto e continua seu raciocínio.

Três Categorias Fundamentais de Ferramentas

É útil pensar as tools em três grandes grupos, segundo o tipo de efeito que produzem:

1. Ferramentas de Leitura (Read Tools)

Expandem o que o agente pode saber. Trazem informação sem alterar o estado do mundo.

• Busca na web
• Leitura de arquivos e documentos
• Consultas a bancos de dados (SELECT)
• Chamadas a APIs de dados (clima, cotações, notícias)
• Leitura de e-mails ou mensagens

Essas são as ferramentas mais seguras. Sistemas em produção as liberam com mais facilidade.

2. Ferramentas de Escrita / Ação (Write Tools)

Produzem um efeito real no mundo. Alteram estado externo.

• Envio de e-mails ou mensagens
• Criação de registros em banco de dados (INSERT, UPDATE, DELETE)
• Execução de scripts ou comandos
• Postagem em redes sociais
• Criação de tarefas ou tickets

Essas ferramentas exigem mais cuidado. Um agente mal projetado pode, por exemplo, enviar e-mails em loop ou deletar registros por engano.

3. Ferramentas de Composição (Meta Tools)

Ferramentas que invocam outros agentes ou orquestrações mais complexas.

• Chamar um sub-agente especializado
• Disparar um workflow em uma plataforma de automação (n8n, Zapier, Make)
• Iniciar um processo assíncrono e monitorar seu resultado

Essa categoria é o que permite construir sistemas multi-agentes, algo que exploraremos em fundo nos próximos artigos.

Por Que um Agente Sem Ferramentas é Fundamentalmente Limitado

Um LLM sem ferramentas é um agente em estagio inicial, capaz de raciocinar, mas incapaz de agir.

Considere o caso de uso mais comum: um assistente de suporte ao cliente. Sem tools, o agente pode:

• Explicar políticas da empresa (se estiverem no contexto)
• Sugerir soluções genéricas
• Responder perguntas frequentes

Com tools, o mesmo agente pode:

• Consultar o histórico real do cliente em tempo real
• Verificar o status de um pedido diretamente no sistema
• Emitir um reembolso automaticamente
• Criar um ticket e atribuir à equipe correta
• Enviar uma notificação por e-mail ou SMS confirmando a ação

A diferença é radical: de um lado um chatbot e do outro um sistema que resolve problemas de verdade.

A inteligência sem agência é consulta. A inteligência com agência é execução.

O Conceito de Function Calling

O mecanismo técnico por trás de tudo isso tem um nome: function calling (ou tool use, como chamado pela Anthropic no Claude).

A ideia é simples: você define as ferramentas disponíveis para o modelo em um schema estruturado (geralmente JSON) descrevendo o nome da função, o que ela faz, e quais parâmetros aceita. O modelo é treinado para, quando apropriado, retornar uma chamada de função ao invés de (ou além de) texto livre.

Um exemplo simplificado de como uma tool é definida:

{
  "name": "buscar_pedido",
  "description": "Busca informações sobre um pedido do cliente no sistema.",
  "parameters": {
    "type": "object",
    "properties": {
      "numero_pedido": {
        "type": "string",
        "description": "O número único do pedido, no formato PED-XXXXX"
      }
    },
    "required": ["numero_pedido"]
  }
}

Quando o agente decide usar essa ferramenta, ele retorna algo como:

{
  "name": "buscar_pedido",
  "arguments": {
    "numero_pedido": "PED-00421"
  }
}

O sistema então executa a função real com esse argumento, obtém o resultado (por exemplo, os dados do pedido) e injeta isso de volta no contexto do modelo. O modelo continua e usa esse dado para formular sua resposta.

Como Projetar Ferramentas

A qualidade das ferramentas projetadas importa muito para um agente.

Um agente é tão bom quanto as ferramentas que tem à disposição, e a clareza com que essas ferramentas são descritas. Se a descrição de uma função é ambígua, o modelo pode chamá-la no momento errado, com parâmetros errados, ou deixar de chamá-la quando deveria.

Alguma boas práticas para projetar ferramentas são:

1. Nomes e descrições precisos O modelo usa o nome e a descrição para decidir quando e como usar a ferramenta. Seja específico. get_weather é melhor que weather. search_customer_by_email é melhor que search_customer.

2. Granularidade adequada Uma tool que faz coisas demais é difícil de controlar. Prefira ferramentas com responsabilidade única e bem definida. Mas ferramentas granulares demais exigem que o agente faça muitas chamadas encadeadas, aumentando a latência e o risco de erro.

3. Retornos ricos e estruturados O resultado de uma tool deve conter contexto suficiente para o agente continuar. Retornar apenas {"status": "ok"} geralmente não basta. Inclua dados relevantes que o agente precisa para raciocinar sobre o próximo passo.

4. Tratamento de erros explícito Se uma tool falhar, o retorno deve deixar claro o que aconteceu e, se possível, sugerir uma alternativa. Um agente que recebe um erro sem explicação fica “perdido” e pode tomar decisões erradas.

Um Exemplo Real: Agente de Agendamento

Imagine um agente de agendamento para uma clínica médica. As tools disponíveis são:

• check_availability(doctor_id, date_range): verifica horários livres
• book_appointment(patient_id, doctor_id, datetime): cria o agendamento
• send_confirmation(patient_id, appointment_details): envia confirmação por e-mail/SMS
• lookup_patient(email_or_cpf): busca o paciente no sistema
• get_doctor_info(doctor_id): retorna informações sobre o médico

Uma conversa com esse agente poderia ser:

Usuário: Quero marcar uma consulta com um cardiologista para a próxima semana.

O agente então executa, internamente, algo como:

1. get_doctor_info → encontra cardiologistas disponíveis
2. check_availability(doctor_id=42, date_range="próxima semana") → retorna horários livres
3. Apresenta as opções ao usuário
4. Usuário escolhe: “Quinta às 14h”
5. lookup_patient(email="usuario@email.com") → recupera o ID do paciente
6. book_appointment(patient_id=1337, doctor_id=42, datetime="2026-04-09T14:00") → confirma o agendamento
7. send_confirmation(...) → envia confirmação

O que parece uma conversa simples, por baixo dos panos, é uma orquestração de 5 chamadas a tools diferentes, tudo coordenado pelo agente de forma autônoma.

Riscos

O uso de ferramentas exige o planejamento cuidadoso da arquitetura. Um agente mas projetado ou mal instruído, com acesso a tools de escrita pode:

• Enviar e-mails não autorizados em nome da empresa
• Deletar registros em um banco de dados
• Fazer compras ou transações financeiras indesejadas
• Expor dados sensíveis ao chamar APIs incorretas

Por isso, sistemas de agentes bem arquitetados implementam o princípio do mínimo privilégio: o agente só tem acesso às ferramentas necessárias para a tarefa. Por exemplo, para agentes de atendimento, apenas ferramentas de leitura são disponibilizadas.

Também é importante implementar confirmações humanas (human-in-the-loop) para ações irreversíveis, especialmente em ambientes de produção. Antes de um agente enviar um e-mail para 10.000 clientes, um humano deveria revisar.

Voltaremos a esse tema em profundidade quando falarmos sobre segurança em agentes de IA.

Ferramentas Como Interface com o Mundo

As ferramentas são a interface do agente com o mundo. Por elas o agente transita do raciocínio para a ação.

Ao projetar um sistema de agentes, a pergunta central não é apenas “qual LLM usar?”, mas também “quais ferramentas esse agente precisa ter? Quais pode ter? Quais é melhor que nunca tenha?”

O conjunto de tools disponíveis define o espaço de possibilidades do agente. Expanda esse espaço com cuidado e monitore o comportamento.

Conclusão: Tools São o Que Torna Agentes Reais

Um LLM sem ferramentas é inteligente, mas inerte. Com ferramentas, ele age: consulta, cria, envia, executa. A escolha de quais tools disponibilizar, e com quais restrições, é a decisão de design mais importante em qualquer sistema de agentes.

No próximo artigo, exploramos os tipos de agentes: reativos, planejadores e autônomos, e como o conjunto de ferramentas disponíveis determina em qual categoria um agente se encaixa.

Este é o quarto artigo de uma série sobre IA agente, sistemas que percebem, decidem e agem. É técnico o suficiente para desenvolvedores, mas ainda acessível para quem está começando.

< Artigo Anterior

Equipo de ingeniería de InnoVox
Engenheiros focados em construir sistemas de IA confiáveis

CONTÁCTANOS