O que é um AI Agent: cinco tipos clássicos, duas definições rivais

O exemplo mais antigo da área é um aspirador de pó em um mundo de dois quadrados, A e B, cada um limpo ou sujo.¹ Ele aparece em todos os livros-texto porque é o menor mundo em que um agent pode estar certo ou errado.

O percepto é um par — onde estou e se aqui está sujo — e as ações são SUCK, LEFT e RIGHT. O programa inteiro é uma linha.

type Percept = { dirty: boolean; where?: "A" | "B" };
type Action = "SUCK" | "LEFT" | "RIGHT";

const textbook = (p: Percept): Action =>
  p.dirty ? "SUCK" : p.where === "A" ? "RIGHT" : "LEFT";   

Rode contra todas as configurações iniciais do mundo de dois quadrados:

A dirty, B dirty, start A    -> steps=3 clean=true
A clean, B dirty, start A    -> steps=2 clean=true
A dirty, B clean, start B    -> steps=2 clean=true

Isso é um simple reflex agent: ele age apenas com base no percepto atual, sem memória de nada antes dele. Não é uma categoria de brinquedo — um termostato é assim, e uma única chamada a um modelo de linguagem sem conversa associada também.

Agora quebre do jeito que a realidade quebra. Um robô aspirador real tem um sensor de sujeira e um para-choque, não um quadrado rotulado A debaixo do tapete. Tire a localização do percepto e não mude mais nada:

const dirtOnly = (p: Percept): Action => (p.dirty ? "SUCK" : "RIGHT");

A dirty, B dirty, start A    -> steps=3   clean=true   still dirty=0
      t=0 at=A percept={dirty:true}  -> SUCK
      t=1 at=A percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:true}  -> SUCK

A dirty, B clean, start B    -> steps=500 clean=false  still dirty=1
      t=0 at=B percept={dirty:false} -> RIGHT
      t=1 at=B percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:false} -> RIGHT
      t=3 at=B percept={dirty:false} -> RIGHT

O mesmo programa, dois quadrados. A partir de um estado inicial ele termina em três passos; a partir de outro, bate na parede da direita quinhentas vezes e continuaria até a bateria morrer. Ele não consegue perceber a diferença entre as duas situações, então não consegue agir de forma diferente nelas. Russell e Norvig enunciam o resultado geral em uma linha: loops infinitos muitas vezes são inevitáveis para simple reflex agents em ambientes parcialmente observáveis.¹

Há uma correção que custa uma linha e nenhuma memória, e vale medi-la antes de recorrer a algo mais esperto.

let seed = 12345;
const rnd = () => ((seed = (seed * 1103515245 + 12345) & 0x7fffffff) / 0x7fffffff);

const coin = (p: Percept): Action => (p.dirty ? "SUCK" : rnd() < 0.5 ? "LEFT" : "RIGHT");  

Duas mil execuções de um corredor todo sujo em três tamanhos, com um único gerador semeado do começo ao fim:

A randomização remove o loop por completo. Ela também cobra: oito cômodos exigem quinze movimentos se você sabe o que está fazendo, e este agent faz 68,7 em média e uma vez levou 306. Esse é o capítulo inteiro em miniatura. Cada capacidade que adicionamos compra correção em um caso que o agent anterior não conseguia tratar, e cobra por isso em uma moeda que você precisa nomear primeiro.

Um agent percebe seu ambiente por meio de sensores e age por meio de atuadores. O programa do agent é a função de perceptos para ações — cada listagem acima é uma. A sequência de perceptos é tudo que foi percebido até agora, e um simple reflex agent ignora tudo exceto o último item.

Racionalidade é a palavra que a maioria dos artigos entende errado, e entendê-la corretamente torna o restante deste capítulo utilizável. Um agent não é racional ou irracional em si. Russell e Norvig definem um agent racional como aquele que, para cada sequência possível de perceptos, seleciona a ação que se espera maximizar sua medida de desempenho, dadas as evidências dessa sequência e qualquer conhecimento embutido que ele tenha.¹ A medida de desempenho não está dentro do agent: ela pertence ao designer, e racionalidade só é definida em relação a ela.

A especificação é convencionalmente escrita como quatro coisas, PEAS: medida de desempenho, ambiente, atuadores, sensores.

Repare qual linha é a exceção. Quase toda equipe que constrói agents em 2026 escreve E, A e S — os schemas de tools, as integrações, o formato da mensagem — porque o código não roda sem eles. Quase ninguém escreve P. Sem isso, “nosso agent está indo bem” não tem significado que alguém possa verificar, e “racional” não pode ser aplicado ao sistema de forma alguma, apenas a uma demonstração. O Capítulo 29 é sobre transformar P em um número, e é por isso que ele existe.

    ┌───────────────────────── the environment ─────────────────────────┐
    │                                                                   │
    │   ┌──────────────────────── the agent ─────────────────────┐      │
    │   │                                                        │      │
 ───┼──►│  sensors  ──►  the agent program  ──►  actuators  ─────┼──────┼──►
percept │                                                        │    action
    │   └────────────────────────────────────────────────────────┘      │
    └───────────────────────────────────────────────────────────────────┘
                                   ▲
              the performance measure lives out here, in the head of
              whoever built the thing, and the agent cannot change it

Ambientes de tarefa são ainda classificados ao longo de sete eixos, cinco dos quais decidem a maior parte da dificuldade aqui: totalmente ou parcialmente observável, determinístico ou não, episódico ou sequencial, estático ou dinâmico, conhecido ou desconhecido.¹ Um agent falando com tools reais por uma rede real está no canto difícil dos cinco — não determinístico mesmo com temperatura zero (Capítulo 17) e, o ponto subestimado, desconhecido, porque você não tem um modelo confiável do que suas próprias tools fazem ao mundo. É por isso que o loop do Capítulo 23 precisa mais de tratamento de erros do que de planejamento.

Pisos reais não são unidimensionais, então promova o mundo a uma planta. Cerquilhas são paredes, asteriscos são sujeira, e o robô começa na câmara do meio:

        col  0 1 2 3 4 5 6
      row 0  * . . # . . *
      row 1  . # . # . # .
      row 2  . # . S . # .        S = the robot starts here
      row 3  . # . # . # .
      row 4  * . . # . . *

O upgrade óbvio é memória. O agent mantém um mapa: cada quadrado em que pisou e cada quadrado em que o para-choque disparou. Sua regra é entrar em um quadrado adjacente que ainda não visitou — direita, depois baixo, depois esquerda, depois cima — e recuar quando tudo ao redor já é conhecido. Isso é um model-based reflex agent: ele mantém estado interno a partir do histórico de perceptos, então pode agir com base no que não consegue ver no momento.

É uma melhoria real, e ainda assim não basta:

5,000 steps allowed -> steps=5,000  distinct squares visited=13/25  still dirty=2/4

Cinco mil movimentos, metade do piso nunca vista. O mapa está correto e as regras estão corretas. O que o agent não consegue fazer é usar o mapa para ir a algum lugar: suas regras só respondem “em qual dos meus quatro vizinhos devo pisar”, então, quando acabam os quadrados não visitados ao lado dele, ele não tem como expressar o pensamento há um quadrado não visitado a oito movimentos daqui e eu gostaria de estar nele. Ele sabe onde está. Não sabe onde quer estar.

Um goal-based agent mantém, além de seu modelo do mundo, uma descrição da situação que quer produzir, e escolhe ações pesquisando sequências delas até encontrar uma que termina lá. Objetivos transformam a seleção de ação de uma consulta em uma busca.

O objetivo é “não restar nenhum quadrado sujo”. A busca é uma caminhada em largura até o quadrado sujo mais próximo, e o caminho que ela retorna é o plano.

goal-based (fewest moves)      -> moves=27  battery=52  still dirty=0
      from 2,3 -> 4,6 via 5 moves:  2,3 2,4 3,4 4,4 4,5 4,6
      from 4,6 -> 0,6 via 4 moves:  4,6 3,6 2,6 1,6 0,6
      from 0,6 -> 4,0 via 10 moves: 0,6 0,5 0,4 1,4 2,4 2,3 2,2 3,2 4,2 4,1 4,0
      from 4,0 -> 0,0 via 4 moves:  4,0 3,0 2,0 1,0 0,0

Vinte e sete movimentos, piso limpo. Mas observe a coluna da bateria e a última perna do plano. A coluna 0 tem carpete: cruzar um quadrado com carpete custa seis unidades de bateria; um quadrado com piso, uma. O agent voltou para casa pela coluna 0 porque são quatro movimentos em vez de oito, e esses quatro movimentos com carpete custaram 24, enquanto o desvio de oito movimentos teria custado 13.

Ele não pode fazer diferente. Um objetivo é um teste binário: o piso está limpo ou não está. Todo plano que termina com o piso limpo o satisfaz igualmente, então, quando vários têm sucesso, o agent não tem como escolher entre eles. Preferir um sucesso a outro exige um número sobre os resultados, e esse número é uma função de utilidade. Um agent que a maximiza é um utility-based agent.

A mudança no código é um termo dentro da busca. A busca em largura conta movimentos; faça-a contar custo em vez disso e você tem o algoritmo de Dijkstra e um agent diferente:

const nd = dist.get(k)! + (byCost ? cell.cost : 1);   // <- the entire difference

goal-based    (fewest moves)   -> moves=27  battery=52  still dirty=0
utility-based (cheapest route) -> moves=31  battery=41  still dirty=0
      from 4,0 -> 0,0 via 8 moves: 4,0 4,1 4,2 3,2 2,2 1,2 0,2 0,1 0,0

Quatro movimentos extras, onze unidades de bateria a menos: vinte e um por cento mais barato. Mesmo objetivo, mesmo mapa, mesmo código exceto por um termo. Os dois agents diferem apenas no que estão tentando fazer bem, e tomam rotas diferentes para casa.

Este também é o primeiro ponto em que o agent precisa de algo que não consegue produzir. Alguém precisa decidir quanto uma unidade de bateria vale em relação a um movimento. Utilidade é a medida de desempenho escrita em uma forma com a qual o agent consegue computar, e escrevê-la é trabalho do designer. Quando as pessoas dizem que um agent “otimizou a coisa errada”, quase nunca querem dizer um bug. Querem dizer que esta linha foi escrita sem cuidado.

Agora deixe a sujeira voltar. Quatro cômodos ficam sujos de novo em quatro ritmos diferentes, e o agent nunca é informado deles. Ele visita um cômodo por tick e vê apenas aquele cômodo. A medida de desempenho são cômodo-ticks passados sujos ao longo de 4.000 ticks — quanto menor, melhor.

Um learning agent, na decomposição do livro-texto, é qualquer um dos anteriores mais três partes: um elemento de aprendizagem que muda o agent, um crítico que lhe diz como o agent está se saindo contra um padrão de desempenho fixo, e um gerador de problemas que propõe ações que valem a pena tentar pelo que ensinariam.¹ Três políticas no mesmo ambiente. A primeira não aprende; a segunda e a terceira aprendem a mesma coisa e a usam de formas diferentes.

As taxas ocultas eram 0,35 para a cozinha, 0,05 para o corredor, 0,02 para o escritório e 0,01 para o sótão — e o aprendiz A as encontrou. Ele identificou corretamente a cozinha como o cômodo mais sujo da casa, depois foi para a cozinha em todo tick pelo resto da simulação enquanto os outros três ficavam sujos para sempre. Ele é cinco vezes pior do que não aprender nada, e não está quebrado.

A lição é a mesma da seção de utilidade. O aprendiz A maximizou “probabilidade de que o cômodo que estou prestes a visitar esteja sujo”. A medida de desempenho era “cômodo-ticks passados sujos”. Números diferentes; o segundo é o que o crítico estava pontuando, e ninguém contou isso ao agent. O aprendiz B multiplica a mesma taxa aprendida pelo tempo desde a última visita — a sujeira que espera encontrar, em vez da chance de encontrar alguma — e supera a patrulha de onde começou.

Um detalhe de implementação decidiu o resultado. Na primeira versão do aprendiz B, um cômodo onde nenhuma sujeira tinha aparecido em três visitas recebia uma taxa exatamente zero — e zero vezes qualquer coisa é zero, então ele nunca era visitado de novo e a estimativa jamais poderia ser corrigida. Suavizar a fração, sucessos mais um sobre tentativas mais dois, transformou 11.895 em 1.576. “Ainda não observado” e “medido e deu zero” são afirmações diferentes, e um sistema que as armazena no mesmo campo toma decisões que não consegue desfazer.

  1  simple reflex    percept ────────────────────────────────► rules ────► action
  2  model-based      percept ──► [state] ──────────────────► rules ────► action
  3  goal-based       percept ──► [state] ──► [goal] ──────► search ───► action
  4  utility-based    percept ──► [state] ──► [goal] ──► [U] ──► argmax ► action
  5  learning         all of the above, plus [critic] ──► changes the parts above

Cada um dos cinco está em produção hoje com outro nome.

Duas linhas são mais próximas do que uma analogia, de um jeito que custa dinheiro.

O chat é um model-based reflex agent cujo modelo não é interno. No livro-texto, o estado é uma variável dentro do programa do agent. Em um chat, é a transcrição: ela vive do seu lado, é reenviada por completo a cada chamada e é reconstruída do zero dentro do modelo a cada vez. Essa é a conta quadrática do Capítulo 16, e é o mesmo objeto que o livro-texto desenhou como uma caixa rotulada “estado”. Aqui está a diferença, medida em uma pergunta de follow-up com e sem as duas mensagens antes dela:

with the transcript      prompt=67  "The current temperature in Lisbon, Portugal is 15°C."
without the transcript   prompt=29  "Lisbon is the capital of Portugal, not a city in Portugal."

O mesmo modelo, as mesmas três palavras de entrada do usuário, e o segundo é o robô do corredor batendo na parede. Não havia tools nessa execução, então o 15 foi inventado — mas o estado é o que faz o follow-up significar alguma coisa. Você o reconstrói toda vez e paga 2,3× os input tokens por isso em uma conversa de dois turnos. O Capítulo 16 mediu até onde esse multiplicador chega no turno quarenta.

Reflexion é um learning agent que muda sua entrada em vez de seu programa. Na decomposição do livro-texto, o elemento de aprendizagem modifica o elemento de desempenho. Reflexion deixa os pesos em paz e escreve texto reflexivo em um buffer episódico que a próxima tentativa lê.³ O elemento de aprendizagem é um prompt, a memória é uma linha de banco de dados, o elemento de desempenho é um modelo congelado — e o diagrama é o do livro-texto, inalterado.

E aqui está o limite honesto do mapeamento. Os cinco tipos classificam o programa do agent. Em 2026, esse programa está dividido ao meio: parte dele é seu código, parte dele está dentro de pesos que você não treinou. Quando um modelo decide por conta própria chamar uma tool, o teste de objetivo está no seu programa ou no modelo? A taxonomia não tem resposta, porque quando foi escrita não havia outro lugar para ele estar — e essa pergunta é exatamente onde as duas definições modernas se separam.

As definições são argumentos sobre comportamento, e ficam muito mais fáceis de julgar com um trace diante de você.

O loop abaixo envia a conversa a um modelo; se a resposta contém uma tool call, ele executa a tool, anexa o resultado e envia tudo de novo. Ele roda contra um Qwen2.5-0.5B-Instruct local atrás de um endpoint no formato OpenAI nesta máquina — a emenda do Capítulo 14, então o loop nem sabe nem se importa com o que está atrás da porta.

const BASE = process.env.LLM_BASE_URL ?? "http://127.0.0.1:8799/v1";

async function loop(question: string, maxTurns = 6) {
  const messages: Msg[] = [
    { role: "system", content: SYSTEM },
    { role: "user", content: question },
  ];

  for (let turn = 1; turn <= maxTurns; turn++) {
    const reply = await call(messages, TOOLS);
    const calls = reply.choices[0].message.tool_calls ?? [];
    messages.push(reply.choices[0].message);

    if (!calls.length) return messages;                      

    for (const c of calls) {
      const out = runTool(c.function.name, JSON.parse(c.function.arguments));
      messages.push({ role: "tool", name: c.function.name, content: out });
    }
  }
  throw new Error("turn cap reached");                       
}

Duas linhas carregam a ideia inteira, e ambas estão marcadas; o resto é contabilidade. Todos os três comportamentos aparecem em uma execução. Quando recebe algo que consegue fazer sozinho, o modelo responde. Quando recebe algo que não consegue, ele chama:

=== a question the model cannot answer, one tool available
  turn 1  prompt= 187  out= 21  finish=tool_calls  CALL get_temperature({"city": "Oslo"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
  turn 2  prompt= 238  out= 12  finish=stop        TEXT "The current temperature in Oslo is 4
                                                        degrees Celsius."
  => model calls=2  prompt tokens=425  output=33  wall=6,257 ms
  => stopped by: the model produced text instead of a call

E ele para — o terceiro comportamento, e o mais fácil de perder, porque parece que nada aconteceu. O loop termina porque o turno 2 voltou sem uma tool call. Ninguém decidiu isso; o modelo decidiu, emitindo prosa. A condição de término deste programa é o sinal de uma ausência.

Mais duas execuções valem o espaço. Ao ser solicitado a comparar duas cidades, o modelo emite ambas as tool calls em um único turno, recebe as duas leituras de volta e erra a comparação:

  turn 1  prompt= 188  out= 43  finish=tool_calls  CALL get_temperature({"city": "Oslo"}),
                                                        get_temperature({"city": "Lisbon"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
          tool  get_temperature -> {"city":"Lisbon","celsius":19}
  turn 2  prompt= 284  out= 13  finish=stop        TEXT "Oslo is currently warmer than Lisbon
                                                        at 4°C."

As tools funcionaram. A chamada paralela funcionou. O loop funcionou. A resposta é falsa, com os dois números corretos na transcrição. Envolver um modelo em um loop não o faz raciocinar; dá a um modelo que está errado a capacidade de agir com base em estar errado — o que antecipa o Capítulo 30, e metade do Capítulo 29.

Agora apague o return marcado e deixe o loop rodar até seu limite. Mesma pergunta, mesmo modelo:

  turn 1  prompt= 187  out= 21  CALL get_temperature({"city": "Oslo"})
  turn 2  prompt= 238  out= 12  TEXT "The current temperature in Oslo is 4 degrees Celsius."
  turn 3  prompt= 261  out= 30  TEXT "Could you please specify the exact location you're..."
  turn 4  prompt= 302  out= 14  TEXT "Sure! Could you tell me which city you're interested in?"
  turn 5  prompt= 327  out= 35  TEXT "I'm sorry, but I need more details to provide an..."
  turn 6  prompt= 373  out= 12  TEXT "Which city would you like to know the temperature for?"
  => model calls=6  prompt tokens=1,688  output=124  wall=25,261 ms  stopped by: turn cap

Quatro vezes os input tokens, quatro vezes o tempo de relógio, e um final em que o agent esqueceu o que foi perguntado e está interrogando o usuário sobre uma pergunta que ele respondeu no primeiro turno. A resposta correta estava na tela no turno 2, e cada turno depois disso piorou a transcrição.

Então um agent não é um loop. É um loop mais uma regra para sair dele, e este tem exatamente uma regra dessas. O Capítulo 23 encontra cinco, e mostra o que quebra quando cada uma falta.

Ambas citadas em vez de parafraseadas, porque as paráfrases são onde a confusão é fabricada.

A definição um coloca a fronteira em quem controla o fluxo. Building effective agents, da Anthropic, nomeia a ambiguidade e decide sobre ela:

“Na Anthropic, categorizamos todas essas variações como sistemas agentic, mas traçamos uma distinção arquitetural importante entre workflows e agents: workflows são sistemas em que LLMs e tools são orquestrados por caminhos de código predefinidos. Agents, por outro lado, são sistemas em que LLMs direcionam dinamicamente seus próprios processos e o uso de tools, mantendo controle sobre como realizam tarefas.”⁴

O teste é uma pergunta sobre seu código-fonte: quem escolheu o próximo passo? Um switch no seu programa: workflow. O modelo: agent. O mesmo documento diz que agents “normalmente são apenas LLMs usando tools com base em feedback ambiental em um loop” — que é exatamente a listagem acima.

A definição dois coloca a fronteira na independência em relação ao usuário. A practical guide to building agents, da OpenAI, abre sua página de definição assim:

“Enquanto o software convencional permite que usuários simplifiquem e automatizem workflows, agents são capazes de executar os mesmos workflows em nome dos usuários com alto grau de independência. Agents são sistemas que realizam tarefas de forma independente em seu nome.”⁵

Duas frases depois, na mesma página, ela exclui:

“Aplicações que integram LLMs mas não os usam para controlar a execução do workflow — pense em chatbots simples, LLMs de turno único ou classificadores de sentimento — não são agents.”⁵

Leia essas citações em ordem. As frases de abertura traçam a linha na independência: isto vai embora e termina o trabalho sem mim? A quarta a traça no controle da execução, que é exatamente a linha da Anthropic. Testes diferentes, mesma página, e há sistemas reais nos quais eles discordam.

Há uma colisão de vocabulário por baixo, e ela causa discussões em reuniões reais. No primeiro documento, um workflow é uma arquitetura, e é a coisa que não é um agent. No segundo, um workflow é “uma sequência de passos que deve ser executada para cumprir o objetivo do usuário” — o trabalho em si, que todo agent tem. “Substituímos o workflow por um agent” é coerente sob a primeira definição e quase sem sentido sob a segunda.

Três sistemas que existem em 2026, sob ambas as definições.

Dois dos três mudam de lado. Isso não é uma falha de nenhum dos documentos. É um alerta sobre um tipo de reunião em que duas pessoas que concordam completamente sobre o que um sistema faz passam uma hora discordando sobre como chamá-lo.

As definições colidem porque cada uma comprime duas perguntas independentes em uma palavra. Separe-as e a discordância vira uma tabela, que é mais útil do que um veredito.

Cada definição disputa uma célula diferente, e as outras duas nem estão em disputa. Então, quando o rótulo importa — em um contrato, uma revisão de risco, um postmortem — as duas frases que vale escrever não são “é um agent?”, mas quem escolheu o próximo passo e quem estava observando. Ambas podem ser respondidas lendo o código, nenhuma precisa da definição de ninguém, e juntas carregam todas as consequências que o rótulo estava representando.

Nada disso é novo. Wooldridge e Jennings pesquisaram os sentidos concorrentes de “agent” em 1995;⁶ Franklin e Graesser fizeram a pergunta deste capítulo em 1996, reuniram as definições em circulação e descobriram que discordavam.⁷ Uma survey de 2023 ainda define agents a partir de primeiros princípios — “entidades artificiais que percebem seu ambiente, tomam decisões e realizam ações”⁸ — porque não existia nada estabelecido para citar, e CoALA descreve partes em vez de traçar uma fronteira.⁹ Trinta anos se recusando a concordar dizem que a palavra está fazendo mais de um trabalho.

Agora a consequência que chega antes da filosofia: a conta.

Toda medição aqui tem a mesma forma. A chamada única custou 39 input tokens; a mesma pergunta com uma tool custou 420 em duas chamadas; o loop sem sua regra de parada custou 1.688 em seis. O crescimento é pior que linear, porque o turno n carrega todos os turnos anteriores: a coluna de prompt dessa execução de seis turnos lê 187, 238, 261, 302, 327, 373. O Capítulo 16 derivou que o total é $\Theta(n^2)$ e ajustou a curva em uma conversa real. Um agent transforma toda tarefa nessa conversa, quer um humano a veja ou não.

Se essas contagens medidas de token tivessem ido para um endpoint comercial nas tarifas que o Capítulo 16 leu em 6 de setembro de 2026 — $2,00 por milhão de input tokens e $12,00 por milhão de output — as quatro execuções sairiam assim:

A linha dois contra a linha um é o número a guardar. Sete vezes e meia o custo, por uma resposta pior a uma pergunta que o modelo já sabia. Nada estava mal configurado: uma tool existia, então o modelo a usou — e a descoberta do Capítulo 18, de que o preço de um catálogo, e não sua precisão, é o que dói, tem aqui sua demonstração mais barata com um catálogo de uma só tool.

É por isso que a metade útil de ambos os documentos é a metade sobre não construir isso. O da Anthropic é direto: encontre a solução mais simples possível e adicione complexidade apenas quando necessário, o que “pode significar não construir sistemas agentic”, já que sistemas agentic “trocam latência e custo por melhor desempenho na tarefa” e, “para muitas aplicações, otimizar chamadas únicas de LLM com retrieval e exemplos in-context geralmente é suficiente”.⁴ Seu caso a favor de um agent é estreito: problemas em aberto em que você não consegue prever o número de passos e não consegue codificar um caminho fixo, em um ambiente em que confia, aceitando “custos mais altos e o potencial de erros compostos”.⁴ A tela da OpenAI é a imagem espelhada — julgamento complexo, conjuntos de regras impossíveis de manter, dados não estruturados — e termina do mesmo jeito: “caso contrário, uma solução determinística pode bastar”.⁵

Então, na taxonomia deste capítulo: um número fixo de passos em uma ordem fixa é um pipeline, e chamá-lo de agent não o tornará mais rápido. Se o número de passos depende do que você encontra pelo caminho, você quer um loop — e compra essa flexibilidade com N chamadas, uma transcrição quadrática e um sistema que pode estar errado N vezes em vez de uma.

Agora você tem a taxonomia, as duas definições modernas, os dois eixos que as tornam compatíveis e um loop curto que responde, chama e para.

Esse loop tem uma forma de terminar: o modelo para de pedir tools. O Capítulo 23 o quebra de propósito, sete vezes, e cada quebra adiciona uma peça. Uma tarefa impossível, e ele nunca termina — um limite de turnos. Uma noite rodando, e a conta chega — um orçamento em dólares. Uma tool que falha — um erro em que o modelo pode agir. A mesma chamada duas vezes — uma chave de idempotência. Um arquivo que não deveria ter tocado — uma aprovação humana. Um reinício no meio — persistência de sessão. Uma tool que leva três minutos em silêncio — progresso e cancelamento. O que sai disso é um harness, o arquivo em que o resto deste curso roda.

O que deixa a pergunta sobre a qual a diagonal disputada deste capítulo realmente tratava. Um loop que decide seu próprio próximo passo precisa decidir quando parar, e acabamos de ver o que acontece quando ele não consegue: seis turnos, quatro vezes a conta e um agent interrogando o usuário sobre uma pergunta que já tinha respondido. Parar não é uma condição. Quantas existem, e qual dispara primeiro?

LLM Powered Autonomous Agents, de Lilian Weng (2023), é a decomposição mais conhecida de um language agent em planejamento, memória e uso de tools, e é a próxima leitura certa ao lado dos dois documentos de fornecedores; seus três componentes são os Capítulos 23, 24 e 18 deste curso, nessa ordem.

Cada número neste capítulo foi produzido nesta máquina e nada foi estimado. O corredor, a planta, os quatro agents que andam por ela e as três políticas de patrulha são o TypeScript acima, executado no Node 22; os números do agent randomizado são médias sobre 2.000 execuções semeadas cada, e os números da patrulha são execuções únicas semeadas de 4.000 ticks. Os traces de modelo vêm de Qwen2.5-0.5B-Instruct em float32 na CPU com decoding guloso, servido via loopback por um pequeno endpoint Python local que carrega os pesos e fala no formato OpenAI chat-completions — a emenda de novo, com os tensores do lado Python e o loop do lado TypeScript — então as contagens de token são as do tokenizer desse modelo e as latências são as dessa máquina. Os únicos números tirados de outro lugar são os dois preços da tabela de custo, que são as tarifas que o Capítulo 16 leu na página de preços da OpenAI em 6 de setembro de 2026, aplicadas aqui às contagens de token medidas localmente como ilustração, não como uma fatura observada.