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

O exemplo mais antigo da área é um aspirador num mundo de dois quadrados, A e B, cada um limpo ou sujo.¹ Sobrevive em todos os manuais porque é o mundo mais pequeno 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";   

Execute-o 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

Isto é um simple reflex agent: age apenas sobre o percepto atual, sem memória de nada anterior. Não é uma categoria de brinquedo — um termóstato é um, e uma única chamada a um modelo de linguagem sem conversa anexada também.

Agora parta-o como a realidade faz. Um aspirador robô real tem um sensor de sujidade e um para-choques, não um quadrado etiquetado A debaixo da carpete. Retire 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 acaba em três passos; a partir de outro bate na parede da direita quinhentas vezes e continuaria até a bateria morrer. Não consegue perceber a diferença entre as duas situações, por isso não consegue agir de forma diferente nelas. Russell e Norvig enunciam o resultado geral numa linha: loops infinitos são muitas vezes inevitáveis para simple reflex agents em ambientes parcialmente observáveis.¹

Há uma correção que custa uma linha e nenhuma memória, que vale a pena medir antes de recorrermos a algo mais inteligente.

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 seeded do princípio ao fim:

A aleatorização remove completamente o loop. Também tem um custo: oito divisões precisam de quinze movimentos se souber o que está a fazer, e este agent faz em média 68,7 e chegou a demorar 306. Esse é o capítulo inteiro em miniatura. Cada capacidade que adicionamos compra correção num caso que o agent anterior não conseguia tratar, e cobra por isso numa moeda que tem primeiro de nomear.

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

Racionalidade é a palavra que a maioria dos artigos usa mal, e acertar nela torna o resto 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 de perceptos possível, seleciona a ação que se espera maximizar a sua medida de desempenho, dadas as evidências dessa sequência e qualquer conhecimento incorporado que tenha.¹ A medida de desempenho não está dentro do agent: pertence ao designer, e a racionalidade só é definida relativamente a ela.

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

Repare em qual é a linha fora do comum. Quase todas as equipas que constroem agents em 2026 escrevem E, A e S — os schemas das tools, as integrações, o formato das mensagens — porque o código não corre sem isso. Quase ninguém escreve P. Sem isso, "o nosso agent está a portar-se bem" não tem significado que alguém possa verificar, e "racional" não se pode aplicar ao sistema de todo, apenas a uma demonstração. O Capítulo 29 é sobre transformar P num número, e é por isso que 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

Os ambientes de tarefa são ainda classificados ao longo de sete eixos, cinco dos quais determinam a maior parte da dificuldade aqui: total ou parcialmente observáveis, determinísticos ou não, episódicos ou sequenciais, estáticos ou dinâmicos, conhecidos ou desconhecidos.¹ Um agent que fala com tools reais através de uma rede real está no canto difícil dos cinco — não determinístico mesmo a temperature zero (Capítulo 17) e, o ponto subestimado, desconhecido, porque não tem um modelo fiável do que as 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 planeamento.

Chãos reais não são unidimensionais, por isso eleve o mundo a uma planta. Cardinales são paredes, asteriscos são sujidade, 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  * . . # . . *

A melhoria óbvia é memória. O agent mantém um mapa: cada quadrado onde esteve e cada quadrado onde o para-choques disparou. A sua regra é entrar num quadrado adjacente que ainda não visitou — direita, depois baixo, depois esquerda, depois cima — e recuar quando tudo à volta já é conhecido. Isto é um model-based reflex agent: mantém estado interno a partir do histórico de perceptos, para poder agir sobre o que não consegue ver neste momento.

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

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

Cinco mil movimentos, metade do chão 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 lado: as suas regras só respondem a "em qual dos meus quatro vizinhos devo pisar", por isso, quando fica sem quadrados não visitados ao lado, não tem forma de expressar o pensamento há um quadrado não visitado a oito movimentos de distância e eu gostava de estar em cima dele. Sabe onde está. Não sabe onde quer estar.

Um goal-based agent mantém, por cima do seu modelo do mundo, uma descrição da situação que quer provocar, e escolhe ações procurando em sequências delas até encontrar uma que acabe aí. Objetivos transformam a seleção de ações de uma consulta numa pesquisa.

O objetivo é "não resta nenhum quadrado sujo". A pesquisa é uma exploração em largura até ao quadrado sujo mais próximo, e o caminho que devolve é 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, chão limpo. Mas olhe para a coluna da bateria e para a última perna do plano. A coluna 0 tem carpete: atravessar um quadrado com carpete custa seis unidades de bateria, um quadrado com mosaico custa uma. O agent voltou a casa pela coluna 0 porque são quatro movimentos em vez de oito, e esses quatro movimentos na carpete custaram 24 quando o desvio de oito movimentos teria custado 13.

Não consegue fazer de outra forma. Um objetivo é um teste binário: o chão está limpo ou não está. Todos os planos que acabam com um chão limpo o satisfazem igualmente, por isso, quando vários têm sucesso, o agent não tem nada para escolher entre eles. Preferir um sucesso a outro precisa de um número sobre resultados, e esse número é uma função de utilidade. Um agent que a maximiza é um utility-based agent.

A alteração ao código é um termo dentro da pesquisa. A pesquisa em largura conta movimentos; faça-a contar custo e 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

Mais quatro movimentos, menos onze unidades de bateria: 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 a tentar 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 tem de decidir quanto vale uma unidade de bateria relativamente a um movimento. A utilidade é a medida de desempenho escrita numa forma com que o agent consegue calcular, 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 sujidade voltar. Quatro divisões voltam a sujar-se a quatro ritmos diferentes, e o agent nunca os recebe. Visita uma divisão por tick e vê apenas essa divisão. A medida de desempenho são room-ticks passados sujos ao longo de 4.000 ticks — mais baixo é melhor.

Um learning agent, na decomposição do manual, é qualquer um dos anteriores mais três partes: um elemento de aprendizagem que altera o agent, um crítico que lhe diz como o agent se está a sair face a um padrão de desempenho fixo, e um gerador de problemas que propõe ações que vale 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 usam-na de forma diferente.

As taxas escondidas 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 learner A descobriu-as. Identificou corretamente a cozinha como a divisão mais suja da casa, depois foi à cozinha em todos os ticks durante o resto da simulação enquanto as outras três ficavam sujas para sempre. É cinco vezes pior do que não aprender de todo, e não está avariado.

A lição é a da secção da utilidade. O learner A maximizou "probabilidade de a divisão que estou prestes a visitar estar suja". A medida de desempenho era "room-ticks passados sujos". Números diferentes; o segundo é o que o crítico estava a pontuar, e ninguém o disse ao agent. O learner B multiplica a mesma taxa aprendida pelo tempo desde a última visita — a sujidade que espera encontrar em vez da hipótese de encontrar alguma — e bate a ronda de onde partiu.

Um detalhe de implementação decidiu o resultado. Na primeira versão do learner B, uma divisão onde não tinha aparecido sujidade em três visitas recebeu uma taxa exatamente zero — e zero vezes qualquer coisa é zero, por isso nunca mais foi visitada e a estimativa nunca pôde 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 guarda 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

Todos os cinco estão hoje em produção com outro nome.

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

O chat é um model-based reflex agent cujo modelo não é interno. No manual, o estado é uma variável dentro do programa do agent. Num chat, é a transcrição: vive do seu lado, é reenviada por completo em cada chamada e é reconstruída do zero dentro do modelo de cada vez. Essa é a fatura quadrática do Capítulo 16, e é o mesmo objeto que o manual desenhou como uma caixa etiquetada "estado". Aqui está a diferença, medida numa pergunta de seguimento com e sem as duas mensagens anteriores:

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 input do utilizador, e a segunda é o robô do corredor a bater na parede. Não havia tools nessa execução, por isso o 15 é inventado — mas o estado é o que faz a pergunta de seguimento significar alguma coisa. Reconstrói-o de cada vez e paga 2,3× os input tokens por isso numa conversa de dois turnos. O Capítulo 16 mediu até onde esse multiplicador chega no turno quarenta.

Reflexion é um learning agent que altera o input em vez do programa. Na decomposição do manual, o elemento de aprendizagem modifica o elemento de desempenho. Reflexion deixa os pesos em paz e escreve texto reflexivo num buffer episódico que a tentativa seguinte lê.³ O elemento de aprendizagem é um prompt, a memória é uma linha de base de dados, o elemento de desempenho é um modelo congelado — e o diagrama é o do manual, sem alterações.

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 é o seu código, parte está dentro de pesos que não treinou. Quando um modelo decide sozinho 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 sítio onde pudesse estar — e essa pergunta é exatamente o ponto em que as duas definições modernas se separam.

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

O loop abaixo envia a conversa para um modelo; se a resposta contiver uma chamada de tool, executa a tool, acrescenta o resultado e envia tudo outra vez. Corre contra um Qwen2.5-0.5B-Instruct local atrás de um endpoint com formato OpenAI nesta máquina — a costura do Capítulo 14, por isso o loop não sabe nem quer saber 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 transportam a ideia inteira, e ambas estão assinaladas; o resto é contabilidade. Os três comportamentos são visíveis numa só execução. Quando lhe perguntam algo que consegue fazer sozinho, o modelo responde. Quando lhe perguntam algo que não consegue, 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 para — o terceiro comportamento, e o mais fácil de ignorar, porque parece que nada aconteceu. O loop termina porque o turno 2 voltou sem chamada de tool. Ninguém decidiu isso; o modelo decidiu, ao emitir prosa. A condição de terminação deste programa é o sinal de uma ausência.

Mais duas execuções merecem o espaço. Ao pedir-lhe para comparar duas cidades, o modelo emite ambas as chamadas de tool num só 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 num loop não o faz raciocinar; dá a um modelo que está errado a capacidade de agir com base no seu erro — o que antecipa o Capítulo 30, e metade do Capítulo 29.

Agora apague o return assinalado e deixe o loop correr até ao 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 fim em que o agent se esqueceu do que lhe perguntaram e está a interrogar o utilizador sobre uma pergunta que este respondeu no turno um. A resposta correta estava no ecrã no turno 2, e todos os turnos depois disso pioraram a transcrição.

Portanto, 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 se parte quando cada uma falta.

Ambas citadas em vez de parafraseadas, porque é nas paráfrases que a confusão é fabricada.

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

"Na Anthropic, categorizamos todas estas variações como agentic systems, mas traçamos uma distinção arquitetural importante entre workflows e agents: workflows são sistemas em que LLMs e tools são orquestrados através de caminhos de código predefinidos. Agents, por outro lado, são sistemas em que LLMs dirigem dinamicamente os seus próprios processos e uso de tools, mantendo controlo sobre a forma como realizam tarefas."⁴

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

A segunda definição coloca a fronteira na independência face ao utilizador. A practical guide to building agents, da OpenAI, abre a página definicional assim:

"Enquanto o software convencional permite aos utilizadores simplificar e automatizar workflows, agents conseguem executar os mesmos workflows em nome dos utilizadores com um elevado grau de independência. Agents são sistemas que realizam tarefas de forma independente em seu nome."⁵

Duas frases depois, na mesma página, 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 por ordem. As frases iniciais traçam a linha na independência: isto vai embora e acaba o trabalho sem mim? A quarta traça-a no controlo da execução, que é exatamente a linha da Anthropic. Testes diferentes, mesma página, e há sistemas reais em que discordam.

Por baixo há uma colisão de vocabulário, e ela causa discussões em reuniões reais. No primeiro documento, um workflow é uma arquitetura, e é aquilo que não é um agent. No segundo, um workflow é "uma sequência de passos que tem de ser executada para cumprir o objetivo do utilizador" — o trabalho em si, que todos os agents têm. "Substituímos o workflow por um agent" é coerente na primeira definição e quase sem sentido na segunda.

Três sistemas que existem em 2026, nas duas definições.

Dois dos três mudam de lado. Isso não é uma falha de nenhum dos documentos. É um aviso sobre um tipo de reunião em que duas pessoas que concordam completamente sobre o que um sistema faz passam uma hora a discordar sobre como lhe chamar.

As definições colidem porque cada uma comprime duas perguntas independentes numa só palavra. Separe-as e o desacordo torna-se uma tabela, que é mais útil do que um veredito.

Cada definição disputa uma célula diferente, e as outras duas não estão em disputa. Por isso, quando o rótulo importa — num contrato, numa revisão de risco, num postmortem — as duas frases que vale a pena escrever não são "é um agent", mas quem escolheu o passo seguinte e quem estava a observar. Ambas se respondem lendo código, nenhuma precisa da definição de ninguém, e juntas carregam todas as consequências que o rótulo estava a representar.

Nada disto é novo. Wooldridge e Jennings passaram em revista os sentidos concorrentes de "agent" em 1995;⁶ Franklin e Graesser fizeram a pergunta deste capítulo em 1996, reuniram as definições então em circulação e descobriram que discordavam.⁷ Um survey de 2023 ainda define agents a partir de primeiros princípios — "entidades artificiais que sentem o seu ambiente, tomam decisões e realizam ações"⁸ — porque não existia nada assente para citar, e CoALA descreve partes em vez de traçar uma fronteira.⁹ Trinta anos a recusar chegar a acordo dizem que a palavra faz mais do que um trabalho.

Agora a consequência que chega antes da filosofia, que é a fatura.

Todas as medições aqui têm a mesma forma. A chamada única custou 39 input tokens; a mesma pergunta com uma tool custou 420 ao longo de duas chamadas; o loop sem a sua regra de paragem custou 1.688 ao longo de seis. O crescimento é pior do que linear, porque o turno n transporta 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 numa conversa real. Um agent transforma cada tarefa nessa conversa, quer um humano a veja ou não.

Se essas contagens medidas de tokens tivessem ido para um endpoint comercial às 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 tokens — as quatro execuções teriam este preço:

A linha dois contra a linha um é o número a reter. Sete vezes e meia o custo, por uma resposta pior a uma pergunta que o modelo já sabia responder. Nada estava mal configurado: existia uma tool, por isso o modelo usou-a — e a conclusão do Capítulo 18, de que o que dói é o preço de um catálogo e não a sua precisão, tem aqui a 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 isto. O da Anthropic é direto: encontre a solução mais simples possível e acrescente complexidade apenas quando necessário, o que "pode significar não construir agentic systems de todo", já que agentic systems "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 é normalmente suficiente".⁴ O caso a favor de um agent é estreito: problemas em aberto em que não se consegue prever o número de passos e não se consegue hardcode um caminho, num ambiente em que confia, aceitando "custos mais elevados e o potencial de erros compostos".⁴ O ecrã da OpenAI é a imagem espelhada — julgamento complexo, conjuntos de regras impossíveis de manter, dados não estruturados — e acaba da mesma forma: "caso contrário, uma solução determinística pode ser suficiente".⁵

Portanto, na taxonomia deste capítulo: um número fixo de passos numa ordem fixa é um pipeline, e chamar-lhe agent não o tornará mais rápido. Se o número de passos depender do que encontrar pelo caminho, 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 tem a taxonomia, ambas as 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 deixa de pedir tools. O Capítulo 23 parte-o de propósito, sete vezes, e cada falha acrescenta uma peça. Uma tarefa impossível, e nunca acaba — um limite de turnos. Uma noite a correr, e a fatura chega — um orçamento em dólares. Uma tool que falha — um erro sobre o qual o modelo pode agir. A mesma chamada duas vezes — uma chave de idempotência. Um ficheiro em que não devia ter tocado — uma aprovação humana. Um reinício a meio — persistência de sessão. Uma tool que demora três minutos em silêncio — progresso e cancelamento. O que sai daí é um harness, o ficheiro sobre o qual o resto deste curso corre.

Isso deixa a pergunta de que a diagonal disputada deste capítulo tratava realmente. Um loop que decide o seu próprio passo seguinte tem de decidir quando parar, e acabámos de ver o que acontece quando não consegue: seis turnos, quatro vezes a fatura, e um agent a interrogar o utilizador sobre uma pergunta que já tinha respondido. Parar não é uma condição. Quantas são, e qual dispara primeiro?

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

Todos os números deste capítulo foram produzidos nesta máquina e nada foi estimado. O corredor, a planta, os quatro agents que a percorrem e as três políticas de ronda são o TypeScript acima, corrido em Node 22; os números do agent aleatorizado são médias de 2.000 execuções seeded cada, e os números da ronda são execuções únicas seeded de 4.000 ticks. Os traces do modelo vêm de Qwen2.5-0.5B-Instruct em float32 em CPU com greedy decoding, servido por loopback por um pequeno endpoint Python local que carrega os pesos e fala no formato OpenAI chat-completions — a costura outra vez, com os tensores do lado Python e o loop do lado TypeScript — por isso as contagens de tokens são as do tokenizer desse modelo e as latências são as dessa máquina. Os únicos números retirados de outro sítio são os dois preços da tabela de custos, 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 a contagens de tokens medidas localmente como ilustração e não como fatura observada.