Construindo Agentes de IA Confiáveis: 5 Padrões de Engenharia da Salesforce
Por que escrever prompts maiores não resolve problemas em produção e como a engenharia da Salesforce precisou mudar o foco para a arquitetura.
A equipe de engenharia da Salesforce descobriu da pior forma: tentar resolver tudo via LLM é o caminho mais rápido para a frustração. Entenda os 5 padrões reais usados em produção no Hyperforce.
Se você acompanhou o último World Tour São Paulo ou está ativo nas discussões da Trailblazer Community, sabe que o assunto não sai da pauta: agentes de Inteligência Artificial. Todo mundo quer colocar algo em produção. Mas quem já operou projetos reais no mercado brasileiro conhece o abismo entre uma demo bem roteirizada no palco do Dreamforce e um sistema rodando sob carga numa grande empresa.
Recentemente, o time de engenharia da própria Salesforce publicou um relato honesto — e raro — sobre como tentaram construir um agente de IA para otimizar alocação de CPU nos servidores do Hyperforce. O objetivo era economizar milhões em infraestrutura. O resultado inicial foi uma série de falhas. Tentaram o caminho que a maioria tenta primeiro: prompts maiores, depois múltiplos agentes conversando entre si. Nenhuma dessas abordagens trouxe a confiabilidade que um ambiente de produção exige.
A virada aconteceu quando pararam de tratar o LLM como um sistema onisciente e voltaram aos fundamentos de arquitetura de software. O que eles documentaram são cinco padrões estruturais — não truques de prompt — que merecem atenção de qualquer arquiteto trabalhando com Agentforce hoje.
Os 5 padrões de engenharia
1. Separe raciocínio de computação
Modelos de linguagem são eficazes para lidar com ambiguidade, interpretar contexto e estruturar dados não normalizados. São péssimos em matemática exata e lógica determinística. Se o seu fluxo depende de um cálculo preciso ou de uma resposta binária confiável, delegue isso para código — Apex, uma função externa, qualquer coisa que não alucine com confiança estatística.
2. Use sistemas determinísticos para problemas determinísticos
No caso do Hyperforce, o desafio era otimizar recursos de infraestrutura. A solução não foi pedir para a IA "descobrir" o melhor cenário. Foi usar o modelo apenas para interpretar o estado da infraestrutura e alimentar um algoritmo matemático exato com esses dados estruturados. O LLM como leitor e tradutor de contexto; o algoritmo como executor da decisão. Papéis bem definidos.
3. O contexto dita a confiabilidade
Jogar tudo na janela de contexto é o erro mais recorrente que encontro em projetos por aqui. Quanto mais regras, exceções e casos de borda você empilha no prompt, maior a probabilidade de o modelo se contradizer ou ignorar instruções anteriores. A abordagem correta é criar ferramentas isoladas e ativar capacidades específicas apenas quando o fluxo de execução as exigir — não preventivamente.
4. Validação baseada em arquitetura, não em outro agente
Um LLM é capaz de produzir respostas incorretas com alto grau de aparente coerência. Usar um segundo agente para revisar o trabalho do primeiro não resolve esse problema em sistemas críticos — apenas adiciona latência e uma segunda fonte de erro não determinístico. Validação precisa ser feita por ferramentas com comportamento previsível: scripts, pipelines de CI/CD, testes automatizados com asserções explícitas.
5. Melhore o entorno, não apenas o prompt
Quando um agente falha repetidamente, o instinto imediato é reescrever o texto do prompt. A experiência de engenharia mostra outra direção: olhe para as ferramentas ao redor do modelo. O problema quase sempre está nas integrações mal definidas, em limites de responsabilidade imprecisos ou em dados de entrada inconsistentes — não na formulação da instrução inicial.
O que isso muda na prática
Para quem está começando
Não caia na ilusão de que Prompt Engineering é a habilidade central daqui para frente. Saber escrever um bom prompt é útil, mas entender como sistemas se integram, como uma API falha sob carga e como validar dados continua sendo o fundamento que sustenta qualquer projeto em produção. Acompanhe o que profissionais sênior estão construindo de verdade — não o que está sendo apresentado em keynotes.
Para quem já é sênior ou arquiteto
Seu papel nunca foi tão estratégico — e nunca exigiu tanto rigor. Com a chegada do Agentforce como componente real de arquitetura, o mercado vai precisar de profissionais que saibam traçar a linha exata entre o que o agente deve resolver, o que o Apex deve executar e o que o Flow deve orquestrar. A arquitetura clássica não foi substituída. Ela ganhou um componente novo, probabilístico e com comportamento emergente que precisa ser contido por fronteiras de design bem definidas.
O maior risco não é o agente errar. É o arquiteto não ter definido o que acontece quando ele erra.
O post original da engenharia da Salesforce vale a leitura completa — especialmente para quem está desenhando soluções com Agentforce em ambientes que não tolerem falhas silenciosas.
O mercado brasileiro está gastando tempo e dinheiro tentando forçar LLMs a fazerem contas e lógicas exatas. Entender que IA resolve ambiguidade enquanto o código resolve precisão é o que separa um projeto que vai para produção de um que morre na prova de conceito.
Esse post do time de engenharia da Salesforce é um dos mais honestos que li sobre o tema. Não é material de marketing — é um relato de quem foi para produção, quebrou coisas e precisou repensar abordagens. O que mais me chamou atenção foi justamente a admissão implícita de que a tentação de resolver tudo no prompt é real, e que até quem construiu o Hyperforce passou por isso. Isso valida o que venho defendendo com clientes: agente de IA em produção não é problema de prompt, é problema de arquitetura. Observabilidade, isolamento de falhas, design de orquestração — esses são os vetores que determinam se um agente vai ou não sobreviver fora de um ambiente controlado. O fato de a Salesforce Engineering documentar esses padrões publicamente me parece um movimento importante: começa a estabelecer um vocabulário arquitetural comum para quem está construindo sobre Agentforce de forma séria. Minha recomendação: leia com atenção técnica, não como conteúdo de adoção.
Ao desenhar uma solução com Agentforce, delegue para a IA apenas a extração de intenção do usuário ou a formatação de texto. Deixe qualquer cálculo, atualização de banco de dados e regras de negócio complexas encapsuladas em Invocable Methods (Apex) ou Autolaunched Flows. Chame essas ferramentas a partir do agente.
Cuidado extremo com a ideia de usar um LLM para revisar o que outro LLM fez em processos críticos de negócio. Explicações bonitas não substituem validação real e testes unitários. Se a saída vai alterar dados de produção, valide com Apex ou regras de validação nativas.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.