Agentes de IA por Dentro (1/3): Anatomia e o Loop de Raciocínio

Gregor Hohpe usa a metáfora do 'Architecture Elevator' para descrever o trabalho do arquiteto: transitar conscientemente entre o andar de negócios (o porquê) e o andar de tecnologia (o como), sem perder o fio condutor. Vamos usar isso aqui.

Andar de negócios: Empresas querem automatizar tarefas que hoje exigem um humano tomando decisões em sequência, pesquisar informações, interpretar resultados, decidir o próximo passo, executar uma ação, verificar se funcionou, corrigir o curso. Um analista financeiro que pesquisa dados de mercado, compara com uma política interna, decide se precisa de mais dados e então redige um relatório está fazendo exatamente isso. O valor está na autonomia do ciclo decisório, não apenas na geração de texto.

Andar de tecnologia: Para replicar isso em software, você precisa de mais do que um LLM. Você precisa de um sistema que perceba o estado do mundo, raciocine sobre ele, decida uma ação, execute essa ação via ferramentas externas, observe o resultado e itere, tudo guiado por um objetivo. Isso é um agente. A distinção não é filosófica; ela tem consequências diretas de arquitetura: latência, custo por tarefa, superfície de falha, observabilidade e segurança mudam completamente quando você sai de uma chamada de LLM para um loop autônomo.

Um agente de IA é um sistema computacional com cinco ingredientes que trabalham juntos:

1. LLM como motor de raciocínio: o modelo não é o agente; ele é o cérebro. Pense nele como a CPU de um computador: poderosa, mas inerte sem o resto do sistema.
2. Objetivo: uma tarefa ou meta que o agente deve atingir. Sem objetivo, o LLM é apenas um gerador de texto responsivo.
3. Ferramentas (Tools): interfaces para o mundo externo: APIs, bancos de dados, buscas na web, execução de código, sistemas internos. São os efetores do agente, mãos e olhos.
4. Memória: curto prazo (o context window da chamada atual) e longo prazo (armazenamento externo: banco vetorial, banco relacional, cache). Sem memória de longo prazo, o agente esquece tudo entre sessões.
5. Autonomia para decidir os próximos passos: este é o ingrediente que separa agente de tudo o mais. O agente decide em runtime quais ferramentas chamar, em que ordem, quantas vezes, e quando parar. Não é um grafo de fluxo pré-definido.

A Anthropic resume bem em seu guia: 'Agents are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.' Autonomia dinâmica é a palavra-chave.

Se você já trabalhou com APIs REST, entende function calling imediatamente com esta analogia: o LLM é um cliente que não pode fazer HTTP diretamente. Em vez disso, ele escreve um pedido de chamada num formato estruturado (JSON), e o runtime age como um proxy que executa a chamada real e devolve o resultado.

Na prática, funciona assim. Você registra ferramentas no sistema com um schema JSON, nome, descrição, parâmetros. O LLM recebe esse schema junto com o prompt do usuário. Quando o modelo decide que precisa de uma ferramenta, em vez de gerar texto livre, ele emite um objeto JSON especial:

{
  "tool_use": "search_web",
  "parameters": { "query": "taxa Selic hoje" }
}

O runtime intercepta isso, executa a função search_web com o parâmetro fornecido, obtém o resultado (digamos, "13,25% a.a.") e injeta de volta no contexto como uma mensagem de observação. O LLM então continua o raciocínio com essa nova informação disponível.

Por que isso é o coração do agente? Porque é o mecanismo que transforma o LLM de um gerador de texto passivo num ator que afeta o mundo. Sem tool calling, o agente não age, ele apenas planeja em voz alta. Com tool calling, cada iteração do loop pode mudar o estado externo: criar um arquivo, chamar uma API, escrever num banco de dados. Isso também é onde mora o risco: uma ferramenta mal especificada ou sem guardrails pode causar efeitos colaterais irreversíveis. Voltaremos a isso na Parte 2.

O paper de Yao et al. (2022) formalizou algo que parece óbvio em retrospecto mas foi um salto conceitual importante: intercalar raciocínio explícito com ações reais melhora drasticamente a qualidade e rastreabilidade do agente.

O loop tem quatro fases que se repetem:

Percepção (Perception): O agente recebe o estado atual, a tarefa original, o histórico de ações anteriores e as observações acumuladas. Tudo isso está no context window. É como abrir o seu IDE com o diff completo do que aconteceu até agora.

Raciocínio (Thought): O LLM gera um passo de raciocínio em linguagem natural: 'Eu tenho os dados da Selic, mas ainda não tenho os dados de CDB. Preciso consultar o banco de dados de mercado.' Esse passo não executa nada, é o modelo pensando em voz alta. Isso é crucial para debugabilidade: você pode ler o raciocínio do agente como um log.

Ação (Action): Com base no raciocínio, o LLM emite uma tool call estruturada. O runtime executa.

Observação (Observation): O resultado da ferramenta é injetado de volta no contexto como uma mensagem de sistema. O loop recomeça com esse novo contexto.

O agente para quando decide que tem informação suficiente para responder ao objetivo original, ou quando atinge um limite de iterações (seu circuit breaker). Sem esse limite, você tem um loop infinito, e uma fatura de API infinita.

Esta é a pergunta mais importante desta aula, e a resposta honesta é: na maioria dos casos reais, você não precisa de um agente autônomo.

A Anthropic é direta no seu guia de engenharia: 'When building applications with LLMs, we recommend finding the simplest solution possible, and only adding complexity when needed.' Isso não é modéstia corporativa, é arquitetura sólida.

Use workflow + RAG quando: os passos são conhecidos e fixos, o processo pode ser modelado como um grafo determinístico, a previsibilidade de custo e latência é crítica, e o domínio tem baixa tolerância a erros (financeiro regulado, saúde, jurídico). Um pipeline de onboarding de cliente, um sistema de Q&A sobre documentos regulatórios, uma geração de relatório com template fixo, tudo isso é workflow, não agente.

Use agente quando: a tarefa é aberta e os passos necessários não podem ser determinados a priori, o problema exige raciocínio adaptativo baseado em resultados intermediários, e você aceita variabilidade de custo e latência em troca de flexibilidade. Pesquisa exploratória, assistentes de debugging, automação de processos onde a sequência depende dos dados encontrados, esses são casos genuínos.

O sinal de alerta: se você consegue desenhar o fluxo completo em um diagrama de sequência antes de escrever código, provavelmente é um workflow. Se o diagrama tem um ponto de interrogação no meio: 'depende do que o LLM encontrar', aí você tem um candidato a agente. Comece sempre pelo mais simples.