O que é um agente de IA? O LLM decide quando parar

Quase todo mundo chama de agente de IA qualquer coisa que tenha um LLM no meio, e é por isso que a palavra "agente" deixou de ajudar a decidir como construir um sistema. A definição que mais se sustenta é bem mais estreita: um agente é um loop de chamadas ao LLM em que o próprio modelo decide quando terminar. O que sobra, com caminho fixo escrito em código, é um workflow.

Essa distinção vem do artigo "Building Effective Agents", que a Anthropic publicou em dezembro de 2024. Nele, workflows são sistemas em que LLMs e ferramentas são orquestrados por caminhos de código predefinidos, e agentes são sistemas em que o LLM dirige dinamicamente o próprio processo e o uso de ferramentas. Na implementação, diz o artigo, um agente costuma ser só um LLM usando ferramentas com base no retorno do ambiente, em um loop. O desenvolvedor Matt Pocock voltou a essa definição em um vídeo de outubro de 2025, depois de ver o AgentKit da OpenAI chamar de agente um fluxo de passos determinísticos: um guardrail contra entradas maliciosas, uma chamada de LLM que roteia a entrada para um de três agentes, e assim por diante. Para ele, aquilo é um construtor de workflows.

O que é uma chamada ao LLM e o que ela não faz?

Uma chamada isolada a um LLM não é agente nem workflow, é só uma chamada de API. Para entrar em qualquer uma das duas categorias você precisa de várias chamadas encadeadas.

Além disso, o modelo só produz texto. Theo, do canal t3.gg, resume assim: dado um texto, o modelo gera mais texto, e nada além disso. Para que ele edite um arquivo ou rode um comando, existe o tool calling. O modelo recebe a descrição das ferramentas disponíveis (no system prompt ou, nas APIs atuais, em um campo próprio para ferramentas) e, quando quer usar uma, responde com uma chamada estruturada (nome da ferramenta e argumentos) e para de responder.

Quem executa a ferramenta é o seu código, não o modelo. Nesse ponto, aquela requisição ao modelo já terminou. O código roda a ferramenta, anexa o resultado ao histórico de mensagens e faz uma nova requisição ao mesmo modelo com tudo o que aconteceu até ali. Na descrição do Theo, o "cérebro" é pausado e reiniciado a cada tool call.

Como funciona o loop de um agente de IA?

Repetir a mesma chamada com a mesma informação não leva a lugar nenhum. O que transforma várias chamadas em um agente é que cada volta traz informação nova: o resultado da ferramenta que o modelo acabou de pedir. O ciclo é este:

1. O código envia ao modelo as mensagens acumuladas e a lista de ferramentas.
2. O modelo responde com uma ou mais tool calls, ou com uma resposta final sem nenhuma.
3. Se houve tool calls, o código as executa, anexa os resultados ao histórico e volta ao passo 1.
4. Se não houve, o loop termina.

A decisão do passo 4 é do modelo. Ele "diz" que acabou ao parar de pedir ferramentas. Veja o esqueleto em TypeScript, sem depender de nenhum SDK. O tipo Model é o que você escreveria em volta da API do provedor que usar:

type ToolCall = { id: string; name: string; args: Record<string, unknown> };

type Message =
  | { role: "user"; content: string }
  | { role: "assistant"; content: string; toolCalls: ToolCall[] }
  | { role: "tool"; toolCallId: string; content: string };

type Reply = { content: string; toolCalls: ToolCall[] };
type Model = (messages: Message[]) => Promise<Reply>;
type Tool = (args: Record<string, unknown>) => Promise<string>;

async function runAgent(
  model: Model,
  tools: Record<string, Tool>,
  task: string,
  maxSteps = 10,
): Promise<string> {
  const messages: Message[] = [{ role: "user", content: task }];

  for (let step = 0; step < maxSteps; step++) {
    const reply = await model(messages);
    messages.push({ role: "assistant", ...reply });

    // Sem tool calls: o modelo decidiu que terminou.
    if (reply.toolCalls.length === 0) return reply.content;

    for (const call of reply.toolCalls) {
      const tool = tools[call.name];
      const result = tool
        ? await tool(call.args).catch((e) => `erro: ${String(e)}`)
        : `ferramenta desconhecida: ${call.name}`;
      messages.push({ role: "tool", toolCallId: call.id, content: result });
    }
  }

  // Parada decidida pelo código, não pelo modelo.
  throw new Error(`o modelo não terminou em ${maxSteps} passos`);
}

É o mesmo mecanismo por baixo de agentes de código como o Claude Code e o Cursor. Theo chega a construir um harness mínimo em vídeo, e o resumo dele sobre o núcleo é que se trata de rodar a chamada em um loop.

Cole Medin, em outro vídeo, lista quatro componentes de um agente: o LLM, as ferramentas, o system prompt e a memória (o histórico). Ele mostra um agente funcional com menos de 50 linhas de Python, usando um framework, e insiste que sem ferramenta o que você tem é só um LLM comum. Isso bate com o código acima: o messages é a memória, tools é o que dá ao modelo algo para decidir, e o system prompt entraria dentro do Model.

E o workflow, o que muda?

Em um workflow não há loop decidido pelo modelo. Existem passos em sequência, com chamadas de LLM no meio e talvez lógica determinística entre elas, mas todos os caminhos possíveis são conhecidos de antemão e escritos em código:

type Ask = (prompt: string) => Promise<string>;

async function supportWorkflow(ask: Ask, ticket: string): Promise<string> {
  const category = (
    await ask(`Classifique em billing, bug ou outro, em uma palavra: ${ticket}`)
  )
    .trim()
    .toLowerCase();

  if (category === "billing") return ask(`Responda sobre cobrança: ${ticket}`);
  if (category === "bug") return ask(`Peça os passos de reprodução: ${ticket}`);
  return ask(`Responda de forma geral: ${ticket}`);
}

Há duas chamadas ao modelo, dois if e três saídas possíveis. O modelo influencia qual ramo é seguido, mas não decide quantos passos existem nem quando o programa acaba. Quem decide é o código. No vocabulário da Anthropic, esse formato se chama routing, um dos cinco padrões de workflow do artigo, cada um com seus trade-offs.

Segundo Matt Pocock, a pergunta que separa os dois é quem decide quando parar. No agente é o LLM, no workflow são passos predeterminados.

Quando usar um e quando usar o outro?

Agentes e workflows servem a problemas diferentes. O agente se justifica quando o caminho até a solução é incerto ou quando a mesma estrutura precisa servir a muitas tarefas distintas. Um assistente de código é o exemplo clássico: ele não sabe de antemão em que base de código vai entrar nem que bug vai receber, então precisa se adaptar a cada passo. Em contrapartida, parte da otimização fica nas mãos do modelo.

O workflow compensa quando você conhece o caminho e vai repeti-lo muitas vezes. Como o fluxo é conhecido, você pode otimizá-lo: rodar chamadas em paralelo, por exemplo, resumindo duas metades de um texto ao mesmo tempo e depois resumindo os resumos. Também fica mais fácil testar cada etapa, prever custo e limitar o que pode dar errado. Matt chega a dizer que, se tivesse de levar só um para uma ilha deserta, levaria workflows, mas ressalva que é uma preferência pessoal.

O artigo da Anthropic vai na mesma direção: recomenda procurar a solução mais simples possível e só aumentar a complexidade quando for preciso, o que às vezes significa nem construir um sistema agêntico. Workflows dão previsibilidade e consistência em tarefas bem definidas, e agentes compensam quando a flexibilidade e a decisão do modelo são necessárias. Na prática, isso vira uma regra: comece pelo workflow e só dê ao modelo o controle do loop onde a variabilidade da tarefa pedir.

Por que é um espectro e não um binário?

Quase nenhum sistema real é um agente puro. Matt aponta três situações intermediárias:

• Um agente em que só o LLM decide parar acaba rodando para sempre em algum momento. Por isso a maioria define um número máximo de passos, que é uma parada determinística em código. É o maxSteps do esqueleto acima, e o ADK, um dos frameworks citados por Matt, expõe esse parâmetro. O artigo da Anthropic também recomenda condições de parada, como um limite de iterações, para manter o controle.
• Um agente pode chamar workflows. Uma tool pode ser, por dentro, um workflow inteiro. Você ganha a generalidade do agente e, nas partes que conhece, a previsibilidade e a otimização de um fluxo fixo.
• Um workflow pode ter loop. Um fluxo que gera um texto e o avalia várias vezes para refinar a saída tem um loop, mas não é necessariamente um agente (a Anthropic chama esse padrão de evaluator-optimizer e o classifica como workflow). O critério de Matt é se o próprio LLM tem a capacidade de interromper o loop antes da hora. Se tem, o sistema tende ao lado de agente.

O código de permissões mostra o mesmo cruzamento. Theo exibe o Claude Code pedindo autorização antes de editar um arquivo, e destaca que o aviso vem de uma checagem no código do harness (o programa que executa as ferramentas), não de uma decisão do modelo. Ou seja, mesmo no agente "de verdade" há regras determinísticas ao redor do loop. Theo também cita um benchmark independente em que o mesmo modelo (Opus) foi de 77% no Claude Code para 93% no Cursor e, segundo ele, a única diferença era o harness. O vídeo não detalha o método do teste, então leia o número como sinal de quanto o código em volta do modelo pesa no resultado, não como medição controlada.

Por isso os termos valem como ferramenta de raciocínio e comunicação. Dizer "isto é um workflow com um passo agêntico" descreve melhor um sistema do que chamar tudo de agente, e deixa claro onde está o risco: sempre que o modelo decide, você abre mão de previsibilidade em troca de flexibilidade.

Como aplicar na prática

Ao desenhar um sistema com LLM, vale perguntar em cada ponto: quem decide o próximo passo e quem decide parar? Se a resposta é "o código", escreva um workflow e aproveite o que ele permite. Se é "o modelo", você tem um agente, e precisa de limite de passos, tratamento de erro nas ferramentas e permissões no nível do código. Muitos sistemas bons misturam as duas respostas em camadas diferentes.

Esse tipo de decisão de arquitetura, onde colocar o controle de fluxo e como limitá-lo, é um dos temas da formação em Inteligência Artificial da Branas.

Referências

• Pocock, Matt. Most devs don't understand what agents are. YouTube, outubro de 2025.
• t3.gg (Theo). How does Claude Code actually work?. YouTube, abril de 2026.
• Medin, Cole. Learn 90% of Building AI Agents in 30 Minutes. YouTube, outubro de 2025.
• Anthropic. Building Effective Agents. Artigo, dezembro de 2024.