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

Uma aula técnica para devs e arquitetos que ouvem 'agente de IA' todo dia mas querem entender de verdade o que diferencia um agente de um LLM puro, de um pipeline fixo ou de RAG simples. Cobrimos a anatomia completa — modelo, ferramentas, memória, planner — e o loop ReAct passo a passo com um exemplo concreto. Sem hype; com trade-offs reais.

- URL: https://fernando.moretes.com/studies/agentes-de-ia-por-dentro-1-o-que-e-um-agente

- Markdown: https://fernando.moretes.com/studies/agentes-de-ia-por-dentro-1-o-que-e-um-agente/study.md?lang=pt

- Type: Guia / Deep Dive

- Domain: IA / Agentes

- Date: 2026-06-26

- Tags: ai-agents, llm, react-loop, function-calling, architecture, bedrock, foundational, series

- Reading time: 8 min

---

Se você é desenvolvedor ou arquiteto de software e está entrando no mundo de IA generativa, provavelmente já ouviu 'agente de IA' dezenas de vezes — em demos de produto, em vagas de emprego, em pitches de startup. O problema é que o termo é usado para coisas radicalmente diferentes: desde um chatbot com um if/else sofisticado até sistemas que realmente tomam decisões autônomas e executam ações no mundo real. Essa confusão tem custo: equipes constroem soluções erradas para o problema certo, ou gastam complexidade desnecessária onde um simples pipeline resolveria. Esta é a Parte 1 de uma série de três aulas. Aqui você vai entender o que um agente de IA realmente é — com precisão conceitual, sem jargão vazio. A Parte 2 cobre os padrões de arquitetura multi-agente (orquestrador, subagentes, padrões de composição). A Parte 3 fecha com produção na AWS usando Bedrock AgentCore. Comece aqui.

## O que você vai aprender

- A definição precisa de agente de IA e os cinco ingredientes que o compõem
- O que diferencia um agente de um LLM puro, de um workflow fixo e de RAG simples — com tabela comparativa
- A anatomia interna: modelo (cérebro), ferramentas, memória de curto e longo prazo, e o planner
- O loop ReAct (percepção → raciocínio → ação → observação) explicado passo a passo com exemplo concreto
- Tool/function calling por dentro: como o modelo emite uma intenção estruturada e o runtime executa
- Quando você precisa de um agente — e quando não precisa (a resposta honesta)

## Glossário Rápido — Termos desta Aula

- **LLM:** Large Language Model — um modelo de linguagem grande treinado para prever o próximo token. Pense nele como uma função: texto entra, texto sai. Sem estado, sem memória própria entre chamadas.
- **Agente de IA:** Um sistema que usa um LLM como motor de raciocínio, tem um objetivo, acessa ferramentas, mantém memória e decide autonomamente os próximos passos até completar a tarefa.
- **Tool / Function Calling:** Mecanismo pelo qual o LLM emite uma intenção estruturada (JSON) dizendo 'quero chamar esta função com estes parâmetros'. O runtime executa e devolve o resultado.
- **RAG:** Retrieval-Augmented Generation — padrão onde você busca documentos relevantes num banco vetorial e injeta no contexto do LLM antes de gerar a resposta. Fluxo fixo, sem autonomia.
- **ReAct:** Reasoning + Acting — framework de Yao et al. (2022) que intercala passos de raciocínio ('Thought') com passos de ação ('Action') e observação do resultado ('Observation') num loop.
- **Planner:** Componente (pode ser o próprio LLM) responsável por decompor um objetivo em subtarefas e decidir a ordem de execução.
- **Context Window:** O 'buffer de memória de trabalho' do LLM — tudo que ele pode 'ver' numa única chamada. É a memória de curto prazo do agente.
- **Runtime / Orchestrator:** O código que gerencia o loop do agente: chama o LLM, interpreta a intenção de tool call, executa a ferramenta, injeta o resultado de volta no contexto e repete.

## Subindo o Elevador: do negócio para a tecnologia

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.

## A Definição Precisa: cinco ingredientes

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.

## Agente × Workflow × RAG × LLM Puro — o que cada um é
| Critério | Dimensão | LLM Puro | RAG Simples | Workflow / Pipeline Fixo | Agente Autônomo |
| --- | --- | --- | --- | --- | --- |
| Quem decide o fluxo? | Ninguém — uma chamada | Código fixo (retrieve → generate) | Código fixo (grafo de passos) | O próprio LLM em runtime | — |
| Ferramentas externas? | Não | Apenas busca vetorial | Sim, mas pré-definidas e ordenadas | Sim, escolhidas dinamicamente | — |
| Memória entre passos? | Não | Contexto injetado, sem estado | Estado passado entre nós do grafo | Curto prazo (contexto) + longo prazo (externo) | — |
| Número de chamadas ao LLM? | 1 | 1 (ou poucos, fixo) | N fixo (definido no grafo) | N variável (o agente decide) | — |
| Custo / latência | Baixo e previsível | Baixo e previsível | Médio e previsível | Alto e variável (risco de loop) | — |
| Quando usar? | Tarefa simples, resposta direta | Q&A sobre documentos internos | Processo conhecido, passos fixos | Tarefa aberta, passos desconhecidos a priori | — |

## Diagrama 1: Anatomia de um Agente de IA

Os cinco componentes internos de um agente e como se relacionam. O LLM é o centro de raciocínio; o runtime/orquestrador é o loop de controle; ferramentas são as saídas para o mundo; memória é o estado persistido.

### 🧠 Núcleo de Raciocínio / Reasoning Core

- LLM (Modelo / Brain) (ai)
- Planner (decompõe o objetivo) (ai)

### 🔄 Runtime / Orchestrator

- Agent Runtime (loop de controle) (compute)

### 🧰 Ferramentas / Tools

- Web Search API (external)
- Database Query (data)
- Code Executor (compute)
- External API / System (external)

### 💾 Memória / Memory

- Memória Curto Prazo (Context Window) (storage)
- Memória Longo Prazo (Vector Store / DB) (storage)

### 👤 Entrada / Input

- Usuário / Sistema (objetivo / tarefa) (user)

### Fluxos

- user -> runtime: objetivo
- runtime -> llm: prompt + contexto
- llm -> planner: raciocínio / decomposição
- planner -> runtime: próximo passo
- runtime -> tool_search: tool call
- runtime -> tool_db: tool call
- runtime -> tool_code: tool call
- runtime -> tool_api: tool call
- tool_search -> runtime: resultado
- tool_db -> runtime: resultado
- tool_code -> runtime: resultado
- tool_api -> runtime: resultado
- runtime -> mem_short: lê/escreve contexto
- runtime -> mem_long: persiste / recupera
- runtime -> user: resposta final

## Tool Calling por Dentro: o coração do agente

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:

```json
{
  "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.

## Diagrama 2: O Loop ReAct — Percepção → Raciocínio → Ação → Observação

Exemplo concreto: agente recebe a tarefa 'Qual o impacto da variação da Selic nos últimos 6 meses sobre o preço médio de CDBs de grandes bancos?' — uma tarefa que exige múltiplos passos e fontes.

### 👤 Entrada / Input

- Tarefa do Usuário (objetivo complexo) (user)

### 🔄 Loop ReAct (iterações do agente)

- Thought 1 'Preciso da série histórica da Selic' (ai)
- Action 1 search_web('Selic histórico 6 meses') (compute)
- Observation 1 [dados da Selic retornados] (data)
- Thought 2 'Agora preciso de dados de CDB' (ai)
- Action 2 query_db('CDB grandes bancos 6m') (compute)
- Observation 2 [taxas CDB retornadas] (data)
- Thought 3 'Tenho dados suficientes — calcular correlação' (ai)
- Action 3 execute_code('correlação Selic × CDB') (compute)
- Observation 3 [resultado: correlação 0.87] (data)
- Final Answer (relatório gerado) (ai)

### 🧰 Ferramentas Externas / External Tools

- Web Search API (external)
- Market Data Database (data)
- Code Executor (compute)

### Fluxos

- goal -> t1: percepção do objetivo
- t1 -> a1: decide ação
- a1 -> ext_web: tool call
- ext_web -> o1: resultado
- o1 -> t2: novo contexto
- t2 -> a2: decide ação
- a2 -> ext_db: tool call
- ext_db -> o2: resultado
- o2 -> t3: novo contexto
- t3 -> a3: decide ação
- a3 -> ext_code: tool call
- ext_code -> o3: resultado
- o3 -> final: suficiente → resposta

## O Loop ReAct: Thought, Action, Observation

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.

## Quando você precisa de um agente — e quando não precisa

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.

## Por onde começar — checklist mental do arquiteto

- ✅ Antes de chamar de 'agente': os passos da tarefa são conhecidos a priori? Se sim → workflow.
- ✅ A tarefa exige apenas recuperação de informação + geração de texto? Se sim → RAG simples.
- ✅ Se for agente: defina o objetivo com precisão. Objetivo vago = loop infinito.
- ✅ Liste as ferramentas necessárias com schemas precisos. Ferramenta mal descrita = alucinação de parâmetros.
- ✅ Defina um limite máximo de iterações (circuit breaker). Sem isso, o agente pode iterar indefinidamente.
- ✅ Separe memória de curto prazo (context window) de longo prazo (storage externo) desde o início.

> **Perspectiva do Arquiteto — Fernando Azevedo:** Depois de 16 anos construindo sistemas financeiros onde um bug pode significar perda real de dinheiro ou violação regulatória, minha reação instintiva a 'agente autônomo' é cautela — não ceticismo, cautela. O loop ReAct é genuinamente poderoso, mas autonomia tem custo: você troca previsibilidade por flexibilidade, e em sistemas regulados essa troca precisa ser justificada explicitamente. O que me convence a usar um agente não é a tecnologia em si, mas a natureza do problema: se o fluxo de decisão é genuinamente desconhecido a priori e depende de dados intermediários, o agente é a ferramenta certa. Se você consegue desenhar o fluxo antes de escrever código, use um pipeline. A maioria dos casos que vejo rotulados como 'agente' na prática são workflows com RAG — e não há nada errado nisso. Simplicidade é uma feature de arquitetura. Dito isso, para tarefas exploratórias, pesquisa de dados não estruturados e automação de processos complexos onde a sequência depende do que você encontra no caminho, o modelo mental desta aula vai servir como base sólida para tudo que vem depois — incluindo as decisões de produção na AWS que cobrimos na Parte 3.

## Veredicto — O que você deve levar desta aula

Um agente de IA não é um LLM com um prompt melhor. É um sistema com cinco ingredientes precisos — modelo, objetivo, ferramentas, memória e autonomia — onde o LLM age como motor de raciocínio num loop iterativo (ReAct) que percebe, raciocina, age e observa até completar a tarefa. O mecanismo central que torna isso possível é o tool/function calling: o modelo emite intenções estruturadas em JSON, o runtime executa, e o resultado alimenta o próximo ciclo de raciocínio. A distinção entre agente, workflow e RAG não é semântica — ela determina custo, previsibilidade, superfície de falha e requisitos de observabilidade. Use o agente quando a autonomia é genuinamente necessária; use o pipeline quando o fluxo é conhecido. Na Parte 2, vamos subir um andar no elevador e olhar para os padrões de arquitetura que emergem quando você compõe múltiplos agentes — orquestrador, subagentes, paralelismo e os trade-offs de cada abordagem. Na Parte 3, descemos para o chão de fábrica: produção real na AWS com Bedrock AgentCore.

## Referências

- [Anthropic — Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)
- [Yao et al. — ReAct: Synergizing Reasoning and Acting in Language Models (arXiv 2210.03629)](https://arxiv.org/abs/2210.03629)
- [AWS — What are AI agents?](https://aws.amazon.com/what-is/ai-agents/)
- [Gregor Hohpe — The Architecture Elevator (book)](https://architectelevator.com/)

## Fontes do caso

- [Anthropic — Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)
- [Yao et al. — ReAct: Synergizing Reasoning and Acting in LLMs](https://arxiv.org/abs/2210.03629)
- [AWS — What are AI agents?](https://aws.amazon.com/what-is/ai-agents/)