Agente ou automação? A pergunta que economiza meio projeto

Existe uma pergunta que, feita na primeira reunião, costuma economizar metade do orçamento de um projeto: isto aqui precisa mesmo de um agente, ou é uma automação? As duas palavras viraram sinônimo no mercado e não são. Escolher agente onde uma automação resolveria significa pagar por incerteza que você não precisava ter. Escolher automação onde o problema exige julgamento significa construir um fluxo que quebra no primeiro caso fora do roteiro. Este artigo é a régua que usamos para separar os dois.

A diferença em uma frase

Automação é um fluxo em que você decidiu antes o que acontece em cada situação: se o valor for maior que mil, faça isto; se o campo estiver vazio, faça aquilo. Agente é um sistema em que o caminho é decidido durante a execução, por um modelo, a partir do objetivo e do que ele observa. Uma repete a sua decisão. O outro toma decisões novas.

Disso decorre tudo o mais. Automação é determinística: a mesma entrada produz a mesma saída, hoje e daqui a seis meses. Agente não é: a mesma entrada pode produzir saídas diferentes, e essa variação é justamente a capacidade que você está comprando quando escolhe agente.

Uma confusão frequente vale desfazer logo: usar um modelo de linguagem em algum ponto do fluxo não transforma o fluxo em agente. Se o modelo apenas classifica ou extrai um campo e o resto continua sendo condição escrita por você, aquilo é uma automação com uma etapa inteligente. A distinção importa porque o custo, o teste e a governança seguem o desenho geral, não a presença do modelo.

Por que a confusão custa caro

Os dois erros custam, e custam de formas diferentes. Vale conhecer os dois padrões, porque cada um aparece em uma fase distinta do projeto.

Agente onde bastava automação. O sintoma é um projeto que fica pronto rápido, impressiona na demonstração e nunca chega a produção. O motivo é que ninguém consegue garantir o comportamento: a cada rodada de teste aparece uma saída diferente, o time gasta semanas escrevendo instruções cada vez mais longas para forçar um comportamento que uma condição de três linhas garantiria, e o custo por execução fica dez vezes maior do que precisava.

Automação onde era preciso agente. O sintoma é oposto: entra em produção rápido, funciona bem por um mês e depois vira uma lista crescente de exceções. Cada caso fora do roteiro gera uma condição nova, o fluxo passa de doze para oitenta ramificações, e chega ao ponto em que ninguém entende mais o que ele faz. O custo aqui não aparece no orçamento, aparece na manutenção.

Existe um terceiro erro, mais raro e mais caro: escolher agente para uma tarefa que exige exatidão absoluta, como cálculo fiscal ou conciliação financeira. Modelo de linguagem é bom em interpretar e ruim em garantir. Cálculo é trabalho de código, e sempre foi.

Os dois lado a lado

Dimensão	Automação	Agente
Quem decide o caminho	Você, antes	O modelo, durante
Mesma entrada, mesma saída	Sim	Não necessariamente
Entrada típica	Estruturada: formulário, evento, registro	Aberta: texto livre, documento, conversa
Custo por execução	Praticamente zero	Proporcional ao uso do modelo
Latência	Milissegundos a segundos	Segundos
Teste	Caso de teste tradicional	Conjunto de avaliação com critério e amostra
Falha típica	Caso não previsto para o fluxo	Resposta plausível e errada
Explicar o que aconteceu	Ler o fluxo	Ler a trilha de decisão
Prazo típico do primeiro fluxo	Dias	Semanas

Cinco perguntas que decidem

Estas cinco perguntas resolvem a escolha na maioria dos casos, e todas podem ser respondidas por quem conhece o processo, sem precisar de arquiteto na sala.

1. A entrada é estruturada ou aberta? Formulário, evento de sistema e registro de banco puxam para automação. Texto livre, áudio e documento sem padrão puxam para agente.
2. Você consegue enumerar os casos? Se a lista de situações possíveis cabe numa página e é estável, automação resolve. Se toda semana aparece um caso novo, é sinal de julgamento.
3. Qual é o custo de uma saída errada? Alto e irreversível pede determinismo, ou pede agente com aprovação humana antes do efeito.
4. Qual é o volume? Milhões de execuções mudam a conta de custo por execução de detalhe para fator decisivo.
5. Alguém precisa explicar essa decisão depois? Se sim, e para um auditor, a exigência de trilha e de aprovação sobe muito, e isso encarece o desenho com agente.

Quando automação é a resposta

Automação é a escolha certa quando o processo tem entrada previsível e regra estável. Nesses casos, ela entrega em dias o que um agente entregaria em semanas, com custo por execução próximo de zero e comportamento que não muda sozinho.

Os casos clássicos são conhecidos e continuam sendo a maior parte do que as empresas precisam. Sincronizar cadastro entre dois sistemas. Emitir documento quando um pedido muda de situação. Avisar um responsável quando um limite é ultrapassado. Consolidar planilhas em um relatório diário. Enfileirar cobrança conforme o vencimento. Nenhum desses exige julgamento, e colocar um modelo no meio deles só acrescenta custo e incerteza.

Vale um alerta contra a moda. Muita empresa está reescrevendo automações que funcionavam bem para “colocar IA”, e o resultado costuma ser um sistema mais caro, mais lento e menos confiável do que o anterior. Se a automação atual resolve, o trabalho de IA que faz sentido é outro: encontrar o processo vizinho que ainda é manual porque ninguém conseguia enumerar as regras dele.

Quando agente é a resposta

Agente se justifica quando a entrada é aberta e a variedade de casos é maior do que qualquer lista de condições conseguiria cobrir. É a capacidade de lidar com o caso número mil e um, aquele que ninguém previu, que você está pagando.

Quatro famílias de problema caem naturalmente aqui. Conversa com cliente em linguagem livre, onde a mesma intenção é escrita de cinquenta formas diferentes. Leitura de documento sem padrão, como nota de fornecedor que muda de layout a cada emissor. Triagem que exige interpretar contexto, e não apenas conferir campo. E tarefas em que o caminho depende do que se descobre no meio, como investigar por que um pedido travou.

O que muda no desenho é a exigência de guarda. Um agente em produção precisa de permissão por ação, limite de custo, trilha de auditoria e regra de repasse para o humano. Essas quatro peças não são acessório: são o que permite que a variação de comportamento seja aceitável, porque ela fica contida dentro de limites que você definiu.

Você não compra a capacidade de decidir. Compra a capacidade de decidir dentro de limites que você escreveu. Sem os limites, o que se comprou foi imprevisibilidade.

O terceiro caminho

Na prática, a maioria dos projetos reais não é nem um nem outro: é uma automação determinística com um ou dois pontos de julgamento isolados. Esse desenho é o que mais entrega e o que menos aparece nas apresentações, porque é menos vendável do que a palavra agente.

O padrão é simples. O fluxo é escrito por você, com todas as ramificações explícitas. Em um ponto específico, onde a entrada é aberta, um modelo faz uma tarefa fechada e devolve um valor estruturado: a intenção classificada entre sete opções, os campos extraídos de um documento, o resumo do que o cliente pediu. Desse ponto em diante, o fluxo volta a ser condição escrita por você.

• O comportamento continua auditável. Só um passo é não determinístico, e ele devolve um valor de uma lista conhecida.
• O teste continua viável. O fluxo se testa como sempre. Só o passo do modelo precisa de conjunto de avaliação.
• O custo fica controlado. Uma chamada de modelo por execução, não dez.
• A falha é localizável. Quando o resultado sai errado, você sabe se foi a classificação ou a regra.
• A evolução é gradual. Se aquele ponto virar insuficiente, ele cresce para agente sem tocar no resto.

Custo e previsibilidade

A diferença de custo entre os dois desenhos não está no desenvolvimento, está na operação. Uma automação custa infraestrutura, e infraestrutura é barata e previsível. Um agente custa infraestrutura mais consumo de modelo por execução, e consumo por execução varia com o tamanho da entrada, com o número de passos e com o comportamento do próprio modelo.

Números de referência para projetos do tipo. O seu caso é medido no diagnóstico, e a variável que mais move a conta é o tamanho médio da entrada, não o número de execuções.

O ponto que costuma pegar as equipes de surpresa não é o valor médio, é a cauda. Uma pequena fração de execuções patológicas, com entrada enorme ou com muitas idas e voltas, pode responder por uma parte desproporcional da fatura. Por isso o teto por execução, além do teto por período, é uma exigência de desenho e não uma otimização posterior.

O que muda no teste

Testar automação é conhecido: entrada, saída esperada, comparação exata. Testar agente exige outra disciplina, e times que tentam aplicar a primeira à segunda concluem que o sistema está quebrado quando ele está apenas variando dentro do esperado.

O que funciona é um conjunto de avaliação: uma coleção de casos reais, com o critério de acerto escrito para cada um, executada a cada mudança de instrução, de modelo ou de fluxo. O critério raramente é igualdade de texto. Costuma ser algo como “a resposta cita o prazo correto”, “a ação escolhida foi a esperada” ou “nenhuma informação foi inventada”.

Duas práticas fazem esse conjunto valer o esforço. A primeira é alimentá-lo com casos reais de produção, especialmente os que deram errado, para que ele reflita a realidade e não a imaginação de quem escreveu. A segunda é medir também o custo e a latência junto do acerto, porque uma mudança que melhora a qualidade em dois por cento e dobra a conta não é uma melhoria.

O que muda na governança

Automação tem governança simples porque o comportamento está no código: para saber o que o sistema faz, lê-se o fluxo. Com agente, o comportamento é emergente, e a única forma de saber o que aconteceu é registrar o que aconteceu.

Exigência	Automação	Agente
Trilha de auditoria	Recomendada	Obrigatória, por ação
Permissão por ação	Implícita no fluxo	Explícita e configurável
Aprovação humana	Onde o processo pedir	Em toda ação sensível ou irreversível
Limite de custo	Não se aplica	Por execução e por período
Versionamento	Do código	Do código, da instrução e do modelo
Avaliação contínua	Testes de regressão	Conjunto de avaliação com amostra revisada

Como migrar sem refazer

Uma boa notícia para quem já tem automações rodando: começar por elas costuma ser o caminho mais barato para chegar a agentes, e não o oposto. A automação existente já resolveu a parte difícil, que é o acesso aos sistemas.

1. Encontre a exceção que mais dói. Aquela ramificação que já tem dezoito condições e continua deixando caso escapar. É ali que o julgamento está escondido.
2. Isole aquele ponto. Transforme a decisão numa etapa que recebe a entrada aberta e devolve um valor estruturado de uma lista fechada.
3. Rode em paralelo, sem efeito. Por duas semanas, o modelo decide e o resultado é apenas registrado, enquanto as condições antigas continuam mandando.
4. Compare as duas decisões. Onde divergiram, alguém revisa e diz quem estava certo. Esse é o seu conjunto de avaliação nascendo de graça.
5. Troque quando o número justificar. E mantenha a condição antiga como caminho de emergência por mais um ciclo.
6. Só então expanda. Um ponto de julgamento por vez, com a trilha ligada desde o primeiro dia.

Onde isso roda

A escolha entre agente e automação não determina a plataforma, mas influencia o que ela precisa oferecer. Nos dois casos, existe um orquestrador: a peça que dispara o fluxo, guarda o estado entre passos, trata falha e permite ver o que aconteceu. Sem essa peça, o que existe é um script, e script não sobrevive ao segundo mês de produção.

Para automação, o orquestrador precisa de três coisas: agendamento e gatilho por evento, repetição controlada quando um serviço externo falha, e visibilidade de cada execução. Isso é território conhecido e resolvido há tempo, seja com uma ferramenta de fluxo, seja com código próprio.

Para agente, somam-se quatro exigências. O catálogo de ações que ele pode chamar, com permissão declarada por ação. O registro do que foi decidido e por quê. O teto de custo aplicado antes da chamada, não depois. E um caminho de repasse para uma pessoa quando a regra mandar. Uma plataforma que atende só as três primeiras exigências entrega um piloto que não passa da revisão de risco.

Três casos reais, três desenhos

Vale ver a régua funcionando em casos concretos, porque a diferença entre os três fica clara na comparação e não na definição.

Caso 1, cobrança de boletos vencidos. Entrada estruturada, vinda do banco. Regra estável: vencido há tantos dias, envia tal mensagem; passou de tantos, escala para o financeiro. Nenhum ponto de julgamento. É automação, entrega em dias e custa quase nada por execução. Colocar um modelo aqui só acrescentaria variação onde ninguém queria variação.

Caso 2, triagem de mensagens no WhatsApp. Entrada aberta, escrita de cinquenta formas diferentes. O fluxo em si é conhecido: identificar, classificar, consultar, responder ou repassar. Um ponto de julgamento, na classificação da intenção, que devolve um valor de uma lista fechada. É o terceiro caminho, e é o desenho que mais entregamos.

Caso 3, conferência de nota fiscal de fornecedor. Cada emissor manda um layout diferente, os campos aparecem em posições distintas, e o que fazer com uma divergência depende do valor, do fornecedor e do histórico. Vários pontos de julgamento, espalhados. É agente, com aprovação humana obrigatória antes de qualquer lançamento, e com o cálculo feito por código depois que os campos foram extraídos.

Erros comuns

• Escolher agente pelo nome. A palavra vende melhor internamente, e essa é a pior razão possível para uma decisão de arquitetura.
• Delegar cálculo ao modelo. Soma, imposto e conciliação são trabalho de código. Modelo interpreta, código calcula.
• Reescrever automação que funciona. Troca previsibilidade por incerteza sem ganho correspondente.
• Empilhar condição por meses. Fluxo com oitenta ramificações está pedindo um ponto de julgamento há muito tempo.
• Deixar governança para depois. Trilha, permissão e teto de custo são baratos no desenho e caros no retrofit.
• Começar pelo atendimento na porta da frente. É o mais visível e o mais arriscado. Backoffice com erro reversível ensina o time sem expor a marca.

Decidir em uma reunião

Com as pessoas certas na sala, a decisão leva uma hora. As pessoas certas são quem executa o processo hoje, quem responde por ele e quem vai construir.

1. Descreva o processo em voz alta, do começo ao fim. Quem executa hoje conta, sem interrupção. As exceções aparecem sozinhas nessa narrativa.
2. Desenhe o fluxograma no quadro. Marque com um círculo cada ponto em que alguém disser “depende”.
3. Conte os círculos. Nenhum significa automação. Um ou dois significam o terceiro caminho. Muitos e espalhados significam agente.
4. Responda as cinco perguntas. Entrada, enumeração, custo do erro, volume e necessidade de explicar depois.
5. Liste as ações irreversíveis. Elas definem onde entra aprovação humana, independentemente do desenho escolhido.
6. Escreva o critério de sucesso. Um número, medido de um jeito específico, antes de começar a construir.

Perguntas frequentes

Usar um modelo de IA já faz do meu fluxo um agente?

Não. Se o modelo só classifica ou extrai um campo e o resto do caminho continua sendo condição que você escreveu, aquilo é uma automação com uma etapa inteligente. Vira agente quando o modelo passa a escolher qual ação executar, e não apenas a interpretar a entrada.

Agente é sempre mais caro que automação?

Por execução, sim, porque há consumo de modelo. No total, depende do que está sendo comparado: se o agente substitui trabalho manual que hoje consome horas de pessoas, a conta costuma fechar com folga mesmo com custo por execução mais alto.

Dá para começar com automação e virar agente depois?

Dá, e é o caminho que recomendamos. A automação já resolve o acesso aos sistemas, que é a parte difícil. Depois, o ponto de decisão que mais gera exceção é isolado, rodado em paralelo sem efeito, comparado e trocado quando o número justificar.

Como garantir que o agente não faça besteira?

Com quatro peças que precisam existir desde o desenho: permissão por ação, aprovação humana em operação sensível, teto de custo por execução e por período, e trilha de auditoria de tudo que ele fez. A garantia não vem do modelo, vem dos limites em volta dele.

Qual é o melhor primeiro projeto?

Um processo interno de backoffice com volume alto, regra razoavelmente clara e erro reversível. Ele prova o fluxo, treina o time na governança e gera o dado que justifica o passo seguinte, sem expor a marca durante o aprendizado.

Preciso ter os dados organizados antes de começar?

Não para o primeiro fluxo. Você precisa de acesso ao dado, não de dado organizado. Organizar tudo antes é a justificativa mais comum para nunca começar, e o primeiro fluxo é justamente o que revela quais partes precisam mesmo ser organizadas.

Quanto tempo leva até o primeiro resultado?

Para automação com acesso já concedido, dias. Para o terceiro caminho, de duas a quatro semanas até um piloto em produção. Para um agente com governança completa, algumas semanas a mais, e o que domina o prazo costuma ser a definição das regras, não o desenvolvimento.

Próximo passo

Pegue o processo que mais consome tempo do seu time e tente desenhar o fluxograma completo dele em quinze minutos. Onde você travar, circule. O número e a posição dos círculos respondem a pergunta do título, e respondem melhor do que qualquer comparativo de ferramenta.

Continuando pelo blog: Quanto custa esperar mostra como calcular o retorno antes de decidir, e Trilha de auditoria em Postgres traz a governança que a coluna da direita exige.