O que é um agente de IA: a linha entre workflow, automação e decisão real

Pumpkin ExplicaSérieEnsaio Nº 11

O que é um
agente de IA

Pumpkin Labs

Pumpkin Explica · #11

pumpkinlabs.io

ensaio nº 11 · 2026

O espectro de autonomia · esquemático

Fig. 11

01.

Workflow

caminho fixo

02.

Automação

decisão controlada

03.

Agente

loop de decisão

chamar workflow de agente → 3× custo · o erro mais caro

S01 · E11

A palavra "agente" foi tomada pelo marketing. Hoje, qualquer integração de API com um LLM é vendida como "agente de IA", e o mercado inteiro perdeu a capacidade de distinguir entre um if/else glorificado e um sistema que de fato decide sozinho. É um problema prático, não semântico. Quando um time acredita que está construindo um agente, mas na verdade montou um workflow, ele espera autonomia onde não existe, subdimensiona a depuração e subestima o custo. O resultado são sistemas que quebram em silêncio, ou que custam o triplo do necessário.

Este post faz uma coisa só: traça a linha que separa workflow, automação e agente, e dá um teste de três perguntas pra você classificar qualquer sistema que aparecer na sua frente. O exemplo do reembolso vai nos acompanhar do começo ao fim, e cada seção vai mostrar como a mesma entrada muda de tratamento conforme o tipo de sistema.

O que um "agente de IA" faz, na definição mais aceita da indústria? A OpenAI descreve como um sistema com três componentes: um acionador, um processo que pode incluir habilidades especializadas e ferramentas ou sistemas aos quais ele pode se conectar. A Microsoft complementa: as etapas que um agente executa são dinâmicas e determinadas pelo LLM com base no contexto da conversa e nas ferramentas disponíveis. Em comum, as duas definições colocam o modelo no centro, decidindo o próximo passo.

O problema é que quase nenhum produto que se vende como agente hoje atende a essa definição. Uma chamada única de LLM com um prompt caprichado é um wrapper, útil mas não é agente. Um pipeline de RAG que busca dados, injeta no contexto e responde é um workflow de caminho fixo, o modelo não decide quando nem o que buscar. A palavra "agente" virou um guarda-chuva que abriga desde um script de três linhas até sistemas que de fato tomam decisões em loop, e a falta de distinção custa caro.

Pense num espectro. Numa ponta está o workflow puro: um script determinístico que segue etapas fixas. Na outra, um agente completo, onde o LLM decide cada passo com base em contexto e ferramentas. Entre eles, um território híbrido que a gente chama de automação inteligente, roteiros com alguns pontos de decisão controlados.

O exemplo do reembolso deixa o espectro claro. Um workflow fixo teria uma sequência pré-programada: receber a mensagem, extrair o número do pedido, consultar o status no sistema de entrega, e se o status for "extraviado", acionar o reembolso automaticamente. Cada etapa é definida no código, e o caminho é sempre o mesmo para a mesma entrada. Isso é rápido, barato e previsível. Um agente, por outro lado, receberia a mensagem, consultaria o sistema de pedidos para entender o status, e a partir dali decidiria: precisa de mais informações? O prazo de entrega ainda não venceu? Melhor perguntar ao usuário antes de reembolsar? O modelo orquestra o fluxo em tempo real.

A OpenAI deixa isso claro: os fluxos tradicionais costumam ser determinísticos, cada etapa explicitamente definida, e o sistema segue o mesmo caminho todas as vezes a menos que você mude a lógica. Os agentes são mais probabilísticos. A diferença fundamental é quem decide o próximo passo: o código ou o modelo.

A fronteira tem um nome técnico: agency, a capacidade de tomar ações consequentes no mundo. A distinção é direta: em workflow, o caminho é predefinido no código, você é dono do encanamento. Em agente, o modelo dirige o próprio processo, o modelo é dono do encanamento. Os dois são válidos, mas só o segundo é, tecnicamente, um agente.

No nosso exemplo, um workflow de reembolso pode ser perfeito: rápido, barato, testável. Mas ele quebra sempre que a situação foge do script. Se o status do pedido for "entregue" mas o cliente afirma que não recebeu, o workflow não sabe lidar com a contradição. Um agente, em contraste, pode decidir abrir uma exceção, escalar para um humano ou pedir uma foto da nota fiscal. A diferença não é de inteligência, é de quem controla o encadeamento.

A Microsoft reforça essa visão no seu Agent Framework: as etapas que um agente executa são dinâmicas e determinadas pela LLM com base no contexto da conversa e nas ferramentas disponíveis. Se as etapas são fixas no código, não é agente. É workflow. E isso não é um problema, desde que você saiba o que está construindo.

A literatura oferece alguns critérios práticos, mas nenhum deles é numérico. A regra de bolso é simples: se a tarefa tem um caminho previsível, é um workflow. A distinção chave é agency, a capacidade de tomar ações no mundo. A partir daí, dá para montar um teste de três perguntas que resolve 90% dos casos.

Primeira pergunta: o modelo decide qual ferramenta chamar e em que ordem, ou a ordem é fixa no código? No workflow de reembolso, a ordem é fixa: primeiro consulta o pedido, depois o status, depois responde. No agente, o modelo pode decidir consultar o sistema de logística antes do pedido, ou pular direto para o reembolso se reconhecer um padrão de fraude. Segunda pergunta: o sistema pode mudar de estratégia sem intervenção humana? Um workflow não muda sozinho; um agente pode, por exemplo, tentar um canal de contato diferente se o primeiro falhar. Terceira pergunta: existe um loop de feedback entre a ação e a próxima decisão? O agente executa uma ação, observa o resultado e decide o próximo passo; o workflow apenas avança na fila.

Se as três respostas forem "sim", é um agente. Se ao menos uma for "não", é workflow ou automação. O teste é simples, e ele revela que a maioria dos sistemas chamados de agentes hoje é, na verdade, workflow com um LLM no meio.

Se o modelo não decide qual ferramenta chamar, em que ordem e quando parar, não é um agente. É um workflow com um LLM no meio.

O caso mais comum é o wrapper: uma chamada única de LLM com um prompt elaborado. Muito útil para resumir, classificar ou extrair informações, mas o modelo não decide nada além da próxima palavra. Não tem ferramentas, não tem loop, não tem agency. Isso não é agente, é um wrapper.

Outro caso frequente é RAG puro (recuperação de informação seguida de geração). O pipeline é fixo: busca chunks num banco vetorial, injeta no contexto, o modelo responde. O modelo não decide quando buscar nem o que buscar; o fluxo é pré-programado. Vira agente quando o modelo decide sozinho quando e o que buscar, em loop, em vez de seguir um pipeline predefinido. A diferença é sutil mas crucial, e a maioria das implementações de RAG hoje está no lado workflow.

Tem também os workflows determinísticos com pontos de decisão controlados, como um sistema que pergunta "você confirma?" e depende de resposta sim/não. Ainda assim, o encadeamento é fixo: a decisão do usuário apenas escolhe entre dois ramos predefinidos. O modelo não decide criar um novo ramo, não decide pular etapas, não decide mudar de estratégia. É automação inteligente, não agente.

O erro de chamar um workflow de agente não é só semântico: ele tem consequências mensuráveis. Definir agente direito serve principalmente pra você não construir um quando não precisa: sistemas agênticos trocam latência e custo por performance na tarefa, e nem sempre o trade compensa. Agentes altamente autônomos são mais difíceis de testar, prever e restringir, e usar um agente quando uma solução mais simples existe acrescenta custo, latência e imprevisibilidade.

No exemplo do reembolso, um workflow bem feito resolve 90% dos casos com uma fração do custo e da latência de um agente. O agente só compensa nos 10% restantes, onde o imprevisto exige decisão em tempo real. Montar um agente para todos os casos é jogar dinheiro e complexidade onde não precisa. O risco real é outro: times que acreditam estar construindo um agente esperam autonomia onde não há, subdimensionam monitoramento e depuração, e descobrem tarde demais que o sistema quebra em modos de falha imprevisíveis.

A lição é simples: escolha a ferramenta pela tarefa, não pelo hype. Workflow é ótimo para processos previsíveis. Agente é caro e poderoso para processos imprevisíveis. Saber qual é qual é o primeiro passo para construir sistemas que funcionam de verdade.

Na Pumpkin, a gente não vende um framework. A gente constrói o harness em torno dos LLMs que decide, para cada tarefa, qual tipo de sistema roda. O conhecimento do negócio, as ferramentas disponíveis, o custo aceitável e a latência tolerável: tudo isso entra na equação que define se aquele passo específico merece um workflow rápido e barato, um LLM simples com prompt bem desenhado, ou um agente com loop de decisão.

No fim, a escolha entre workflow e agente é uma decisão de engenharia, não de branding. Saber a diferença é o que separa um sistema que custa o esperado e funciona como previsto de um que promete autonomia mas entrega um script disfarçado.

• OpenAI. What are agents? OpenAI Academy, 2026.
• Microsoft. Workflows in Agent Framework. Microsoft Learn, 2026.