"Empresas so conseguem escalar agentes tao rapido quanto conseguem mante-los precisos e dentro do orcamento." A frase e de Andrew Comstock, SVP/GM de MuleSoft e Agent Fabric na Salesforce, e resume o anuncio que a empresa fez em 28/10. Mais do que um lancamento de produto, ela entrega um diagnostico que vale para qualquer stack: o diferencial de agentes em producao migrou do modelo para a camada de avaliacao e governanca na integracao.
O que a Salesforce anunciou
O Agent Fabric — o control plane de agentes construido sobre o MuleSoft — ganhou um conjunto de capacidades voltadas a confiabilidade e custo:
Agent Evals: cria e roda testes automaticamente, antes e durante o deploy, batendo agente, LLM e servidores MCP contra benchmarks de qualidade. Quando um agente nao passa, um Agent Kill Switch pode interrompe-lo por politica.
API Evals: testa as APIs das quais o agente depende para pegar breaking change antes que ele chegue a producao — o tipo de falha que derruba um agente sem que o modelo tenha errado nada.
Controles de custo: um FinOps Dashboard com visao consolidada de gasto e um Model Wallet com teto rigido de uso. Com caching semantico e response trimming, a Salesforce afirma ter cortado ate 75% dos tokens em teste.
Somam-se a isso o Custom Agent Scanner (descobre e cataloga agentes, modelos e APIs internos e de terceiros) e as Open Policies for Federated API Gateways (aplicam politica em varios API gateways). Os numeros do anuncio dao a escala: o Agent Fabric processa 1,2 bilhao de requisicoes por dia.
O movimento nao esta isolado. Na mesma semana, ServiceNow e OpenAI aprofundaram a integracao de IA no operacional corporativo, e Oracle e Google articularam hardware dedicado a inferencia agentic. O padrao e claro: as grandes plataformas estao correndo para oferecer, alem do modelo, a camada que torna o agente confiavel, governavel e com custo previsivel em producao. Ou seja, o mercado inteiro esta reconhecendo que o modelo virou commodity e que o diferencial passou a ser o control plane — avaliacao, politica, catalogo e teto de custo em torno do agente.
O recado real: menos da metade avalia em trafego real
O dado mais revelador do anuncio nao e de produto: menos da metade das empresas que ja rodam agentes avalia o desempenho deles em trafego real. Ou seja, a maioria coloca agente em producao sem medir, de forma continua, se ele continua preciso diante do que os usuarios de verdade pedem. Isso e um risco silencioso — o agente degrada, muda de comportamento quando uma API a montante muda, e ninguem percebe ate o cliente reclamar.
A resposta da Salesforce — avaliar antes e durante o deploy, com kill switch e teto de custo — reconhece que agente confiavel e economico nao e um "modelo melhor", e sim uma camada de avaliacao e governanca que cerca o agente.
Vale entender por que "avaliar em trafego real" e tao diferente de "testar antes do deploy". Um agente aprovado em benchmark no laboratorio pode degradar silenciosamente em producao por mil razoes que o teste nao antecipa: uma mudanca sutil no formato de resposta de uma API a montante, uma distribuicao de perguntas diferente da esperada, um sistema que passou a responder mais devagar e empurrou o agente para caminhos de fallback. Sem avaliacao continua em producao, nada disso dispara alarme — o agente simplesmente comeca a errar mais, a custar mais ou a responder fora de politica, e a primeira pessoa a perceber costuma ser o cliente. Por isso o Agent Evals roda durante o deploy, e nao apenas antes, e por isso o kill switch existe: e o reconhecimento de que a confiabilidade de um agente nao e um estado permanente, mas algo que precisa ser medido o tempo todo.
Por que isso e camada de integracao, nao modelo
O que quebra um agente em producao raramente e "o modelo errou". E uma API que mudou o contrato sem aviso, um sistema a montante que passou a devolver um campo diferente, um custo que subiu sem teto. Todos esses sao problemas de integracao e governanca de API — exatamente onde vivem o API Evals (pegar breaking change antes da producao), as politicas federadas de gateway e o catalogo de agentes e APIs.
E por isso que o Agent Fabric foi construido sobre o MuleSoft: a avaliacao de agente so e util se estiver ancorada na camada de API-led que conhece cada dependencia do agente. Avaliar o agente sem avaliar as APIs das quais ele depende e medir metade do problema.
Entra aqui tambem a malha de servidores MCP (Model Context Protocol), por onde o agente acessa ferramentas e dados. Cada servidor MCP e, na pratica, mais uma dependencia que pode mudar, falhar ou custar caro — e que precisa ser catalogada, avaliada e governada como qualquer API. O Custom Agent Scanner existe justamente para dar visibilidade a esse inventario: nao da para governar o que nao se conhece, e muitas organizacoes descobriram ter dezenas de agentes, modelos e conexoes MCP espalhados, sem um registro central. Catalogo, politica federada de gateway e avaliacao de API formam, juntos, o que se poderia chamar de higiene basica de uma operacao de agentes — e nada disso vive no modelo.
A fronteira que o Agent Fabric nao cobre
Aqui esta o ponto fino para quem nao vive 100% dentro do mundo Salesforce. O Agent Fabric cobre, com excelencia, o que esta dentro do universo Salesforce/MuleSoft. Mas o seu agente provavelmente tambem fala com e-commerce, OMS, sistema fiscal/NF-e, CRM e legado nao-Salesforce. E e justamente nessa fronteira — onde o agente cruza para fora da plataforma — que avaliar o comportamento, testar a API antes que ela quebre e medir o custo deixa de ser automatico e vira projeto.
A tese do Agent Fabric ("agente em producao exige camada de eval + governanca + custo") e transferivel para qualquer stack que exponha agentes, servidores MCP e APIs. O que muda e quem constroi e opera essa camada na sua fronteira especifica.
No contexto brasileiro isso e ainda mais concreto. Um agente que processa pedidos precisa conversar com o OMS, com a plataforma de e-commerce e com o sistema fiscal que emite a NF-e — frequentemente nenhum deles dentro do mundo Salesforce. Se a API do emissor fiscal muda um campo, ou se o OMS passa a devolver o estoque em outro formato, o agente quebra em producao sem que o modelo tenha errado nada. Avaliar essa API antes da mudanca chegar, aplicar politica de gateway sobre ela e medir o custo de cada chamada e trabalho de integracao que o Agent Fabric, sozinho, nao faz do lado de fora do ecossistema Salesforce. A tese e dele; a execucao na fronteira e de quem conhece esses sistemas.
Como a CCX faz
A CCX constroi exatamente essa camada e a estende para alem do mundo Salesforce.
Com Integracoes & APIs Enterprise e MuleSoft, a CCX implementa a camada de API-led onde se aplica o eval de API (pegar breaking change antes da producao), a politica federada de gateway e o registro/catalogo de agentes e APIs — inclusive os que conversam com sistemas nao-Salesforce.
Com Observabilidade 360°, a CCX avalia o agente em trafego real: benchmark continuo, deteccao de desvio e kill switch quando o comportamento foge do esperado — fechando a lacuna de "menos da metade avalia em trafego real".
E com Data & BI, a CCX entrega o lado FinOps: visao consolidada de gasto e teto de custo por modelo, o equivalente ao Model Wallet, mas abrangendo toda a malha de agentes e APIs da operacao.
O ponto de partida pratico costuma ser um inventario: mapear quais agentes existem, de quais APIs e servidores MCP eles dependem e onde estao os pontos cegos de avaliacao e custo. A partir desse mapa, define-se o que avaliar em trafego real, quais APIs precisam de eval antes da producao e onde aplicar teto de gasto. E um projeto incremental — comeca pela fronteira de maior risco (tipicamente a integracao com e-commerce, OMS e fiscal) e se expande. O resultado e uma operacao de agentes que o time consegue defender diante tanto da area de risco quanto do financeiro.
O Agent Fabric mostrou o que agente em producao exige: avaliar antes e durante o deploy, pegar breaking change de API antes da producao e por teto de custo. A CCX constroi essa camada de API-led + observabilidade sobre MuleSoft e estende a avaliacao para a fronteira nao-Salesforce. Fale com a CCX sobre projetos Salesforce e integracoes.
Perguntas frequentes
O que e o Agent Fabric? E o control plane de agentes da Salesforce, construido sobre o MuleSoft, que descobre, cataloga, avalia e governa agentes, LLMs, servidores MCP e APIs. Em 28/10 recebeu Agent Evals, API Evals, FinOps Dashboard, Model Wallet, kill switch e Custom Agent Scanner.
Como avaliar um agente de IA em producao? Rodando benchmarks continuos contra o agente em trafego real (nao so antes do deploy), medindo precisao, custo e latencia por transacao, e tendo uma politica de interrupcao (kill switch) para quando o agente foge do esperado. Menos da metade das empresas faz isso hoje.
Como evitar que uma mudanca de API quebre meu agente? Testando as APIs das quais o agente depende antes da producao (API eval), para pegar breaking change cedo, e aplicando politica federada nos gateways. E um problema de camada de integracao, nao de modelo.
Isso so vale para quem usa Salesforce? Nao. A tese — agente em producao exige camada de avaliacao, governanca e teto de custo — vale para qualquer stack. O Agent Fabric cobre o mundo Salesforce/MuleSoft; na fronteira com e-commerce, OMS, fiscal e legado, essa camada precisa ser construida e operada, e e ai que a CCX entra.
Qual a diferenca entre Agent Evals e API Evals? Agent Evals testa o comportamento do proprio agente (e do LLM e dos servidores MCP que ele usa) contra benchmarks de qualidade, antes e durante o deploy, com kill switch quando falha. API Evals testa as APIs das quais o agente depende, para pegar breaking change antes que ele chegue a producao. Um cuida do raciocinio do agente; o outro, das dependencias de integracao que podem derruba-lo sem que o modelo tenha errado.