Desenvolvimento de agentes de IA que sobrevivem à produção

Desenvolver agentes de IA é construir software em que um modelo de linguagem decide que passo dar, chama ferramentas reais para o dar, lê o resultado e decide de novo — até cumprir um objetivo ou até um limite o travar. O produto não é o modelo: é o ciclo à sua volta. É aí que vive a engenharia: o que o agente pode invocar, como os erros lhe regressam, como o estado passa entre passos, o que acontece quando sai da rota e como sabe depois se o trabalho foi feito. Um chatbot responde. Um agente age — e é essa ação que torna isto um projeto de software e não um prompt.

Um protótipo funcional para uma tarefa estreita costuma levar de uma a três semanas. Levar esse protótipo a um estado que mostraria a clientes demora bastante mais — normalmente de dois a quatro meses — e quase nada desse tempo vai para prompts. Vai para integrações que falham de formas que o modelo tem de absorver, para um conjunto de avaliação que apanha regressões, para permissões, para registos que permitam depurar e para o caminho de passagem a uma pessoa nos casos que o agente não deve decidir sozinho. As equipas que orçamentam a demonstração e não a segunda fase são aquelas cujo agente nunca sai do piloto.

Comece pelo mais leve que resolva a tarefa. Para um único agente com meia dúzia de ferramentas, o SDK do fornecedor do modelo e um ciclo escrito por si costumam ser todo o trabalho, e deixam-no capaz de depurar cada passo. Recorra a uma framework de orquestração quando precisar mesmo de estado durável, controlo de fluxo com ramos, novas tentativas em passos longos ou vários agentes coordenados. O custo de uma framework não é a API: é que as peças que mais precisa de inspecionar num dia mau ficam dentro da abstração de outra pessoa. Escolha o que escolher, mantenha prompts, definições de ferramentas e conjunto de avaliação fora da framework: mudar custará um dia, não uma reescrita.

Há dois custos e as equipas planeiam regularmente o errado. Custo de construção: um agente interno estreito situa-se tipicamente entre 8000 e 30 000 $ de engenharia; um agente virado ao cliente, com integrações reais, avaliação e monitorização, fica mais vezes entre 30 000 e 120 000 $. Custo de operação: a despesa em tokens costuma ser a rubrica menor e a mais fácil de reduzir — encaminhar passos simples para um modelo mais barato, usar cache e podar o contexto cortam-na frequentemente a metade. A rubrica esquecida é a manutenção: modelos são descontinuados, APIs mudam, o conjunto de avaliação tem de correr de novo. Conte com cerca de 15–25% do custo de construção por ano.

Limitando o que ele pode fazer em vez de esperar que se comporte. Na prática: ancore as respostas em documentos recuperados e faça-o citar a fonte usada; dê às ferramentas argumentos estritos e tipados, validados antes da execução; deixe uma ferramenta devolver um honesto «não encontrado» e ensine ao agente que não devolver nada é um resultado aceitável; limite o número de passos e a despesa por execução; e coloque uma aprovação humana à frente de tudo o que é irreversível — pagamentos, eliminações, mensagens enviadas a clientes. Depois meça. Um conjunto de avaliação com cinquenta casos reais, incluindo os incómodos, diz mais sobre fiabilidade do que qualquer afinação de prompts.

Use uma plataforma no-code quando a tarefa é padrão, o volume moderado e o custo de uma resposta errada é baixo — encaminhar FAQ interna, triagem de contactos, redigir primeiras respostas. Levam mesmo mais depressa a um resultado e ensinam-lhe o que a tarefa exige. Construa à medida quando o agente tiver de tocar nos seus sistemas com permissões reais, quando latência ou custo unitário pesarem ao seu volume, quando precisar de avaliação e rasto de auditoria próprios, ou quando o agente fizer parte do produto que vende. O percurso habitual faz sentido: prove o fluxo numa plataforma e depois reconstrua as partes que o mereceram.