O vídeo dura 30 segundos. Um agente de iA planeja uma viagem, reserva o voo, redige o e-mail e envia tudo ao cliente. O post viraliza, acumula milhares de curtidas e gera uma onda de comentários entusiasmados. No dia seguinte, alguém tenta reproduzir o mesmo código em produção. O agente entra em loop, alucina um voo que não existe e trava sem aviso. A distância entre a demo e o software confiável é o primeiro sintoma de uma fratura que define, em 2026, dois mundos radicalmente distintos na construção de agentes de iA.
De um lado, os meninos: engenheiros e entusiastas que tratam LLMs como varinhas mágicas, empacotam tudo em um prompt e celebram quando funciona duas vezes seguidas. Do outro, os homens: profissionais que entendem que agente de iA é engenharia de sistemas, não truque de linguagem. Quem você impressiona revela de que lado está. E a diferença, como veremos, não é de talento. É de método.
A ilusão do prompt único
Ujjwal Chadha, engenheiro de iA com mais de uma década em software escalável, cunhou um nome para o erro mais comum dos iniciantes: o “God Prompt.” É aquele bloco de texto onde o desenvolvedor despeja todas as instruções de uma vez: “Você é um assistente útil. Planeje a viagem, pesquise hotéis, consulte o clima, calcule o orçamento e envie o itinerário.” Parece razoável. Mas LLMs degradam conforme a complexidade aumenta. Um prompt que tenta cobrir cinco tarefas executa cada uma delas com metade da atenção que dedicaria se recebesse uma por vez.
A solução é modularidade. Não um agente que faz tudo, mas uma cadeia de trabalhadores especializados. O Worker A extrai datas e destino. O Worker B pesquisa hotéis com base na saída de A. O Worker C redige o e-mail a partir do resultado de B. Se a etapa do e-mail falha, não é preciso refazer a pesquisa de hotéis. Confiabilidade nasce de decomposição, não de ambição acumulada num único prompt.
Essa primeira linha de fratura revela algo mais profundo: os meninos pensam em agentes como conversas. Os homens pensam em agentes como arquitetura.
Arquitetura como decisão estratégica
A diferença entre um agente de demonstração e um agente de produção começa na separação de responsabilidades. Em sistemas maduros, o planejador não é o executor. Existe memória de longo prazo. Existe máquina de estados com checkpointing, o que significa que o sistema sabe em que ponto parou e pode retomar sem recomeçar do zero. Existe retry com circuit breaker (mecanismo que impede que uma falha cascateie pelo sistema inteiro) e human-in-the-loop escalonado, no qual o humano só é chamado quando o risco justifica a intervenção.
A maioria dos agentes que circulam em redes sociais opera com um LLM, um prompt extenso e algumas ferramentas conectadas sem critério. Funciona na demonstração porque o cenário é controlado. Quando o cenário muda (e em produção ele sempre muda), o sistema colapsa. Não porque o modelo seja ruim, mas porque não existe estrutura ao redor dele. Um motor potente montado numa carroceria frágil não completa a corrida.
Modularidade resolve a concepção. Mas não garante que o sistema sobreviva ao mundo real.
Confiabilidade: o tribunal da produção
Chadha faz uma observação que deveria estar estampada no monitor de todo engenheiro de iA: “Vibes are not a unit of measurement.” Dizer que o agente “parece mais rápido” ou “ficou mais esperto” não constitui métrica. Testar o agente manualmente, conversando com ele, funciona no primeiro dia. No centésimo dia, é negligência.
Agentes confiáveis operam com saída estruturada obrigatória. Se o modelo precisa decidir qual ferramenta acionar, a resposta deve ser JSON estrito. Se o LLM retorna texto livre quando se esperava um objeto, o código deve rejeitar imediatamente e tentar de novo. Não interpretar. Não adivinhar. Tratar o LLM como uma função tipada: se o tipo de retorno está errado, a chamada falhou.
E como medir se o sistema funciona de fato? Com um Golden Dataset. Um conjunto de 50 a 100 entradas difíceis, cada uma com sua saída correta documentada. A cada mudança de prompt, o dataset roda automaticamente e rastreia métricas específicas: correspondência exata do JSON, taxa de alucinação (quantas vezes o agente citou uma URL que retorna 404), precisão na seleção de ferramentas. Sem testes automatizados contra um dataset de referência, o deploy é cego.
Funcionar em condições controladas é engenharia de demonstração. Funcionar sob pressão, com dados reais, edge cases e falhas de API, é engenharia de fato.
O salto para sistemas multi-agente
Um agente confiável resolve uma tarefa. Um time de agentes resolve um processo. A diferença de escopo entre meninos e homens aparece com nitidez quando a complexidade aumenta.
O agente dos meninos faz pesquisa de mercado e escreve um relatório. Morre em 30% dos casos por paywall, link quebrado ou alucinação grave. O agente dos homens opera de outro modo: pesquisa em múltiplas fontes, cruza resultados com dados internos via RAG e banco de dados proprietário, valida fatos com triangulação, gera relatório com slide deck e recomendações indicando nível de confiança por afirmação, e solicita aprovação humana apenas nos 15% mais sensíveis.
Outro exemplo, mais próximo do cotidiano comercial. O agente dos meninos faz cold email. Dispara mensagens genéricas e torce para que alguma converta. O agente dos homens é, na verdade, um time de cinco agentes coordenados: um pesquisador de persona, um copywriter, um otimizador de timing, um verificador de compliance e um testador A/B. O time roda a campanha inteira, aprende com taxas de abertura, clique e resposta, e ajusta sozinho. Humanos definem guardrails e orçamento. O resto é execução autônoma com governança.
A coordenação entre agentes exige protocolos reais (como A2A ou padrões inspirados em MCP), hierarquia dinâmica ou swarm, e papéis definidos: researcher, planner, executor, critic. Sem essa orquestração, adicionar agentes ao sistema é adicionar caos.
O que não se mede não se governa
Observabilidade é o que transforma um protótipo numa plataforma. Agentes maduros produzem telemetria completa: trace de decisão (por que o agente escolheu a ferramenta X e não Y), custo por agente, latência por etapa, taxa de sucesso por ferramenta e detecção de drift (quando o comportamento do agente começa a se desviar do esperado sem que ninguém tenha mudado nada).
Os meninos olham o console. Os homens operam dashboards com alertas, auditoria e rollback. A diferença parece burocrática até o dia em que um agente gera uma resposta que viola a LGPD, envia um e-mail com informação incorreta a um cliente ou consome o orçamento de API de um mês em duas horas.
Governança significa guardrails reais. Permission boundary: o agente só acessa o que precisa, com least-privilege. Validação de saída: cada resposta passa por verificação antes de chegar ao usuário final. Canary rollout: mudanças no comportamento do agente são testadas com uma fração do tráfego antes de atingir todos. Escalation policy: quando o agente não sabe o que fazer, escala para um humano em vez de inventar. Compliance com SOC2, GDPR e audit trail completo.
“Não vai dar ruim” não é política de segurança. É esperança. E esperança, como dizem os engenheiros de software, não escala.
A evolução que separa sistemas de brinquedos
Chadha descreve o padrão Reflexion como uma das marcas de maturidade em agentes de iA. A versão 1 de qualquer agente segue o fluxo Input, Think, Act, Output. Mas o que acontece quando a ação falha? Quando a API retorna erro 400?
Agentes maduros olham para os próprios erros. Se a chamada a uma ferramenta falha, a mensagem de erro volta para o contexto e o agente tenta novamente com uma abordagem diferente. O agente tenta buscar na tabela “users”. O sistema responde que a tabela não existe. O agente reflete: precisa primeiro listar as tabelas disponíveis para encontrar o nome correto. Essa capacidade de autocorreção não é sofisticação. É o mínimo para operar no mundo real, onde as coisas raramente funcionam na primeira tentativa.
Além do Reflexion, a evolução contínua dos agentes que realmente entregam valor segue um loop disciplinado. O agente gera dados operacionais. Esses dados são avaliados. As avaliações alimentam ajustes finos, seja via fine-tuning leve, RLHF (aprendizado por reforço com feedback humano) ou RLAIF (com feedback de outro modelo). Prompt engineering corresponde a 90% do trabalho nos agentes dos meninos. Nos agentes dos homens, é só o ponto de partida.
Outra prática que distingue maturidade: Dynamic Few-Shotting. Iniciantes colocam dois ou três exemplos fixos no prompt. Profissionais armazenam centenas de exemplos em banco vetorial e, para cada nova requisição, recuperam os três mais similares e os injetam no prompt. Se o usuário pergunta sobre lógica de datas, o agente recebe exemplos de manipulação de datas. Se a pergunta é sobre parsing de texto, recebe exemplos de regex. Alinhamento específico sem poluir o contexto com ruído irrelevante.
E talvez a regra mais contraintuitiva de todas: código supera prompts para lógica determinística. Não peça ao LLM para calcular custo com imposto. Ele erra matemática básica em dias ruins. Use o LLM para raciocínio e roteamento. Use Python para execução. O “cérebro” fica com o modelo. O “músculo” fica com o código. Quem confunde os dois constrói agentes que impressionam em demos e erram em planilhas.
Quem você impressiona
A métrica final que separa os dois mundos não é técnica. É econômica. Os meninos medem sucesso por “ficou bonito na demo” e pelo número de curtidas no post. Os homens medem por redução de custo, tempo economizado em processos reais, ROI mensurável e SLA cumprido.
Os meninos impressionam quem não entende. Os homens impressionam o CFO, o compliance officer e o cliente que paga a conta todo mês.
O gap entre esses dois grupos não é de acesso a modelos melhores. GPT-4, Claude, Gemini estão disponíveis para todos. O gap é de engenharia. De disciplina. De entender que o LLM é apenas o motor de raciocínio dentro de um sistema maior, e que em muitos casos nem é o componente mais relevante.
Construir agentes de iA que funcionam exige o mesmo rigor de qualquer software de produção: testes automatizados, observabilidade, governança, evolução contínua. A diferença é que o componente central é probabilístico, não determinístico, o que torna todas essas práticas ainda mais necessárias, não menos.
A pergunta que resta é direta: de que lado da fratura você está construindo?
Referências:
Ujjwal Chadha, “How to Build Top Notch AI Agents: AI Engineer’s Perspective”, 2026. – https://x.com/ujjwalscript/status/2017972854709768205
ousadia criativa. precisão estratégica. – por kim.