Um bom modelo não basta: por que o verdadeiro desafio dos agentes de IA é engenharia de sistemas

Existe uma tendência de tratar agentes de IA como se fossem apenas uma evolução dos grandes modelos de linguagem. A lógica parece simples: quanto melhor o modelo, melhor será o agente. Essa relação existe, mas está longe de ser suficiente.

Um modelo mais capaz pode compreender melhor instruções, raciocinar sobre problemas mais complexos e utilizar ferramentas com maior eficácia. Mas, quando um agente entra em produção e passa a consultar bancos de dados, chamar APIs, manipular arquivos, executar código, acessar sistemas corporativos ou tomar ações com consequências reais, o LLM deixa de ser o sistema inteiro. Ele passa a ser um componente dentro de um sistema muito maior.

É nesse ponto que o problema deixa de ser predominantemente engenharia de prompts e passa a ser, sobretudo, engenharia de sistemas.

Uma forma útil, embora não seja uma taxonomia universal da indústria, de analisar essa arquitetura é separá-la em três dimensões: Harness Engineering, Loop Engineering e Graph Engineering.

Na verdade queremos responder: O agente consegue operar? Consegue verificar e corrigir seu trabalho? E o processo permanece sob controle?

Comecemos pela Harness Engineering. Um agente não trabalha sozinho. Ele depende de ferramentas, APIs, memória, estado, contexto, permissões, credenciais, limites de execução, mecanismos de aprovação, logs e observabilidade. Esse conjunto forma o que vem sendo chamado de harness: a infraestrutura operacional que conecta o modelo ao mundo real.

Duas equipes podem utilizar exatamente o mesmo LLM e obter resultados radicalmente diferentes. Uma pode fornecer ferramentas bem definidas, contexto estruturado, permissões mínimas e rastreabilidade. Outra pode oferecer dezenas de ferramentas ambíguas, privilégios excessivos e pouca capacidade de monitoramento. O modelo é o mesmo. O sistema não.

Quando um agente não consegue acessar uma API, utiliza uma ferramenta inadequada, perde estado ou possui permissões maiores do que deveria, trocar o modelo pode não resolver o problema. Um bom harness não é aquele que oferece o maior número de ferramentas. É aquele que oferece as ferramentas necessárias, com escopo limitado, interfaces claras e controles adequados ao risco.

E agora vamos ao Loop Engineering. Mesmo com um bom ambiente, existe outro problema: como determinar se uma tarefa foi realmente concluída?

É aqui que entram os loops de execução e verificação. Um agente pode produzir uma resposta, avaliar que ela está boa e continuar tentando melhorá-la. Sem critérios objetivos de encerramento, isso pode gerar ciclos improdutivos, aumento de latência, consumo de tokens e custos sem ganho proporcional de qualidade. O princípio deveria ser simples: não iterar apenas com base em confiança; iterar com base em evidências.

Em programação, por exemplo, o processo pode ser: escrever → testar → analisar falhas → corrigir → testar novamente.

O critério de parada não é o agente declarar que o código está perfeito. É uma combinação de evidências: testes aprovados, validações concluídas, orçamento de tentativas atingido ou necessidade de intervenção humana.

O mesmo raciocínio pode ser aplicado a outros processos: validação de esquema, políticas de segurança, conferência de dados, aprovação humana ou verificação de fontes. O loop não torna o agente automaticamente mais inteligente. Ele cria um processo controlado para detectar erros, tentar correções e decidir quando parar.

E, finalmente, a Graph Engineering. Há situações em que um único agente e um loop bem desenhado não são suficientes.

Um processo corporativo pode envolver pesquisa, análise, execução, validação, aprovação e tratamento de exceções. Algumas etapas podem ocorrer em paralelo; outras exigem aprovação humana; determinadas falhas podem exigir retorno a uma etapa anterior. Nesse cenário, representar o processo como um grafo pode ser útil.

Os nós representam etapas. As transições representam caminhos possíveis. Ramificações, paralelismo, aprovações, retries e condições de encerramento tornam-se explícitos.

Imagine: Planejamento → Execução → Testes → Segurança → Aprovação → Produção

Uma falha de segurança pode devolver o processo para a etapa de execução. Uma determinada ação pode exigir aprovação humana. Duas verificações podem ocorrer simultaneamente.

O grafo não torna o sistema automaticamente confiável. Seu valor está em tornar explícitas as regras de coordenação e reduzir a dependência de uma sequência implícita de decisões do modelo.

E existe uma ressalva importante: nem todo agente precisa de um grafo complexo. Construir uma arquitetura multiagente para uma tarefa simples pode apenas adicionar pontos de falha e aumentar custos.

A complexidade da orquestração deve ser proporcional à complexidade do problema. Essa distinção ajuda a diagnosticar problemas.

Se o agente não consegue operar uma ferramenta, perde contexto ou possui privilégios inadequados, provavelmente existe um problema no ambiente.

Se executa indefinidamente, não possui critérios de sucesso ou repete ações sem evidência de melhoria, o problema está no ciclo de execução. Se múltiplos agentes precisam coordenar decisões, aprovações, exceções e caminhos alternativos, o desafio passa a incluir a arquitetura do fluxo.

Isso não significa que o modelo seja irrelevante. Pelo contrário. Um modelo inadequado pode gerar erros de raciocínio, interpretar mal instruções, utilizar ferramentas incorretamente ou produzir resultados de baixa qualidade. Em determinadas aplicações, a escolha do modelo continuará sendo decisiva.

O ponto é outro: um excelente modelo dentro de uma arquitetura ruim continua produzindo um sistema ruim. Durante anos, a engenharia de software evoluiu concentrando-se não apenas em algoritmos, mas também em arquitetura, sistemas distribuídos, segurança, observabilidade, testes, resiliência e governança.

Os agentes acrescentam uma nova variável: componentes probabilísticos capazes de tomar decisões intermediárias e interagir com sistemas externos.

Isso muda a natureza da engenharia. Não estamos simplesmente construindo uma aplicação que chama uma API de IA. Estamos começando a construir sistemas nos quais humanos, software determinístico e componentes probabilísticos precisam trabalhar juntos, cada um com responsabilidades e limites diferentes.

E isso cria uma pergunta muito mais importante do que “qual é o melhor modelo?”. Como construir um sistema no qual um modelo probabilístico possa executar trabalho real sem transformar a organização em um experimento permanente?

No meu entender esse é o verdadeiro desafio da Engenharia Agêntica. O diferencial competitivo não estará apenas em ter acesso ao modelo mais poderoso. Estará em saber projetar o ambiente, controlar os ciclos, estruturar os fluxos, limitar a autonomia, validar resultados e governar o sistema inteiro.

Afinal, colocar um agente para trabalhar é relativamente fácil. O difícil é construir uma organização capaz de confiar no trabalho que ele realiza.