Precisa de um agente de IA? Na maioria dos casos, não.

Se está a perguntar-se se precisa de um agente de IA, a resposta honesta é: provavelmente não. A maioria das funcionalidades de produto que os fundadores querem tornar "agênticas" fica melhor construída como um fluxo determinístico, um simples formulário ou um pequeno modelo de classificação — mais barato de operar, testável em CI, explicável a um cliente e livre do não-determinismo que transforma uma falha de uma terça-feira numa investigação forense. Recorra a um agente apenas naquele estreito limite onde a abertura é mesmo o requisito.

Já escrevemos um argumento semelhante sobre machine learning: a maioria dos problemas que as pessoas enquadram como ML é, na verdade, uma consulta SQL e um limiar. A mesma doença tem agora um nome novo. A cura é a mesma: defina o problema com precisão e depois escolha a ferramenta mais simples que o resolva.

Agente de IA vs automação: o que é, de facto, um agente

Um agente de IA são três coisas aparafusadas: um grande modelo de linguagem, um conjunto de ferramentas que pode invocar (pesquisa, uma base de dados, uma API, um executor de código) e um ciclo — o modelo decide o que fazer, fá-lo, lê o resultado e decide de novo, até achar que terminou. Esse ciclo é o objetivo todo. É também o problema todo.

A automação determinística, em contraste, é uma sequência fixa de passos que você escreveu. Um webhook dispara, um registo é criado, um email sai, uma linha é atualizada. Mesma entrada, mesma saída, sempre, para sempre. Pode lê-la, testá-la e raciocinar sobre cada ramo.

A diferença que importa não é inteligência. É controlo. A automação faz exatamente o que especificou. Um agente faz o que decidir, o que significa que cada execução pode diferir, e os modos de falha são abertos: pode entrar em ciclo, inventar um argumento de ferramenta, chamar a API errada ou produzir com confiança uma resposta errada que parece certa. Está a trocar determinismo por flexibilidade. A maioria das funcionalidades não precisa dessa troca.

A versão curta

• Formulário ou fluxo quando as entradas e os passos são conhecidos. É a maior parte do que está a construir.
• Modelo pequeno / ranker quando precisa de pontuar, ordenar, classificar ou recomendar sobre sinais estruturados.
• Agente apenas quando a entrada é genuinamente não-estruturada, o caminho é genuinamente aberto e uma resposta errada é barata de recuperar.

Porque "agêntico" costuma perder para um fluxo programado

Eis o padrão incómodo que vemos. Um fundador descreve uma funcionalidade — "o utilizador pede um reembolso e o sistema trata disso" — e alguém recorre a um agente porque o pedido chega como uma frase. Mas a lógica subjacente é uma tabela de decisão: foi dentro de 14 dias, o artigo foi expedido, o valor está abaixo do limiar de aprovação do gestor. São quatro ramos. Um if resolve. Está correto 100% das vezes, não custa nada por chamada e, quando um cliente contesta o resultado, pode apontar para a regra exata que disparou.

Embrulhe essa mesma lógica num agente e herda quatro novas contas:

• Latência e custo. Cada passo é uma chamada ao modelo. Um ciclo de três passos são três idas e voltas, de centenas de milissegundos a segundos cada, pagas por token, sempre — contra uma leitura de base de dados que devolve em milissegundos de um dígito, de graça.
• Não-determinismo. A mesma entrada pode produzir saídas diferentes entre execuções. É um pesadelo para o suporte, para reembolsos, para qualquer coisa que um regulador ou um cliente furioso possa examinar.
• Colapso dos testes. Não pode escrever uma asserção contra "o modelo costuma fazer a coisa certa". Acaba com suítes de avaliação e taxas de aprovação estatísticas em vez de um CI verde — e uma taxa de 96% significa que 1 em cada 25 clientes recebe a resposta errada.
• Inexplicabilidade. Quando corre mal, a resposta ao "porquê" é uma transcrição do raciocínio do modelo, que é uma história que ele contou a si próprio, não uma causa que se corrige com um patch de uma linha.

Nada disto é culpa do modelo. É do ciclo. Pegou num problema de forma conhecida e entregou-o a um sistema cuja característica definidora é inventar a forma de cada vez.

Onde os agentes ganham mesmo o seu lugar

Não somos anti-agente. Há trabalho real e valioso que só um LLM-em-ciclo faz bem, e fingir o contrário é apenas o erro oposto. Um agente justifica-se quando três condições se verificam todas:

• A entrada é genuinamente não-estruturada. Uma pilha de PDFs em formatos inconsistentes, uma caixa de suporte em texto livre, um fio de email confuso onde o pedido real está enterrado em três parágrafos de cordialidades. Quando não consegue escrever o parser, um modelo que lê vale a pena.
• O caminho é genuinamente aberto. Investigação aberta em que não sabe de antemão que fontes importam, ou um assistente de depuração que tem de olhar para o código, executá-lo, ler o erro e tentar de novo. A ramificação é real, não imaginada.
• Uma resposta errada é barata. Rascunho de baixo risco — um primeiro email, um resumo, uma sugestão de código que um humano revê antes de ir para produção. O humano no ciclo é a rede de segurança, e o agente poupa-lhe o problema da página em branco.

Repare no padrão: os agentes brilham onde de outra forma precisaria de um humano para ler, julgar e improvisar — e onde um erro custa uma repetição, não um reembolso ou um processo. Síntese de investigação, triagem de entrada não-estruturada, rascunho sob revisão. É uma categoria real e em crescimento. Só que é muito mais pequena do que o hype do "vamos torná-lo agêntico" sugere.

Uma checklist de decisão

Antes de construir qualquer coisa agêntica, percorra esta lista de cima a baixo. Pare no primeiro sim.

1. Um formulário ou um fluxo fixo resolve? As entradas e os passos são conhecidos de antemão? Construa o fluxo. Acabou.
2. É pontuar, ordenar, classificar ou recomendar sobre sinais estruturados? Construa um modelo pequeno ou um ranker baseado em regras. Explicável, rápido, testável.
3. A entrada é não-estruturada E o caminho é aberto E uma resposta errada é barata de recuperar? Agora um agente justifica-se. Mantenha poucas ferramentas, o ciclo limitado e um humano no resultado se o risco for real.
4. Ainda tentado a tornar o passo 1 ou 2 "agêntico" na mesma? Escreva o que o agente lhe traz que a opção mais barata não traz. Se a resposta honesta for "parece mais moderno", já tem a sua resposta.

O que a Amplified Creations realmente faz

Na Amplified Creations a nossa opção por defeito é automação determinística e modelos pequenos e explicáveis — e só acrescentamos um LLM no limite onde a abertura é o requisito genuíno. A nossa stack é aborrecida de propósito: PHP 8.3 em alojamento partilhado, páginas renderizadas no servidor, um Cockpit CMS com SQLite, sem passo de build. Quando um cliente precisa de comportamento "inteligente", perguntamos em qual dos três baldes cai antes de escrever uma linha de código.

Concretamente: o recomendador dentro da app de bem-estar Jofit é um pequeno ranker explicável, não um LLM em ciclo. Pontua e ordena opções sobre sinais estruturados, para que possamos testá-lo, raciocinar sobre porque trouxe à tona uma dada sugestão e colocá-lo em produção sem custos de token por pedido nem saída não-determinística. Para os sites de clientes, a "automação" é esmagadoramente lógica simples no servidor e tarefas agendadas: submissões de formulário encaminhadas pelo Resend, conteúdo puxado do CMS, JSON-LD gerado a partir dos mesmos dados — determinístico, cacheável e rápido o suficiente para manter o Lighthouse à volta de 95. Usamos LLMs onde pertencem — rascunhar e traduzir conteúdo longo sob revisão humana, o tipo de trabalho não-estruturado, de baixo risco e verificado por humanos em que os agentes são bons. Não pomos um modelo no caminho crítico de um checkout, de um reembolso ou de qualquer coisa que possa prejudicar um cliente ao falhar. Isto não é cautela por si só; é o mesmo instinto de engenharia que diz que não se implementa a própria criptografia. Use a ferramenta poderosa e imprevisível só onde o seu poder é o ponto.

O resultado é software em que os nossos clientes podem confiar e que conseguimos depurar às 2 da manhã. Um agente em produção é uma coisa que se supervisiona. Um fluxo determinístico é uma coisa de que nos esquecemos porque simplesmente funciona. Na maioria das vezes, "simplesmente funciona" é a funcionalidade.

Perguntas frequentes

Qual é a diferença entre um agente de IA e automação?

A automação corre uma sequência fixa de passos que escreveu, por isso a mesma entrada produz sempre a mesma saída. Um agente de IA é um LLM que decide os seus próprios passos num ciclo, usando ferramentas, por isso o comportamento pode variar de execução para execução. A automação troca flexibilidade por controlo; um agente troca controlo por flexibilidade.

Vale a pena um agente de IA para o meu produto?

Normalmente não, para os fluxos centrais. Os agentes valem a pena apenas quando a entrada é genuinamente não-estruturada, o caminho é aberto e uma resposta errada é barata de recuperar — como investigação, triagem de entrada confusa ou rascunho de baixo risco que um humano revê. Para entradas e passos conhecidos, um fluxo ou formulário é mais barato, mais rápido e testável.

Quando devo usar um modelo pequeno em vez de um agente LLM?

Use um modelo pequeno sempre que estiver a pontuar, ordenar, classificar ou recomendar sobre sinais estruturados. Um ranker ou classificador focado é explicável, corre em milissegundos, não custa nada por chamada e pode ser testado em CI — nada disto é verdade para um LLM-em-ciclo. Guarde o LLM para a linguagem não-estruturada que o modelo pequeno não consegue ler.

Porque é que o não-determinismo é um problema em produção?

Porque a mesma entrada pode dar saídas diferentes, o que quebra os testes, o suporte e a responsabilização. Não consegue escrever uma asserção limpa contra "normalmente correto" e, quando um cliente contesta um resultado, só lhe pode mostrar a transcrição do modelo, não uma regra para apontar e corrigir. Para reembolsos, faturação ou qualquer coisa regulada, isso é inaceitável.

A Amplified Creations é contra o uso de LLMs?

Não. Usamos LLMs onde a abertura é o requisito real — rascunhar e traduzir conteúdo sob revisão humana. A nossa objeção é a pôr um modelo não-determinístico no caminho crítico de funcionalidades que um fluxo determinístico ou um pequeno ranker tratariam de forma mais barata, mais fiável e mais explicável.