Agente de IA sem teto de gasto: o que a Salesforce pôs no Agent Fabric

O botão de desligar o agente existe e está vendido. O que decide quando apertar o botão chega, pelo calendário da Salesforce, em janeiro de 2027. Essa é a leitura mais útil do anúncio que a Salesforce publicou em 27 de outubro de 2026 sobre o Agent Fabric, a camada da MuleSoft que a empresa chama de plano de controle de agentes de IA. Do pacote anunciado, três coisas estão em disponibilidade geral agora: um limite rígido de gasto por agente e por provedor de modelo, um painel de custo e o desligamento de um agente específico sem derrubar os outros. A avaliação contínua em produção, que detecta o agente respondendo errado e pede aprovação para tirá-lo do ar quando a política da equipe exigir, está prevista para beta em novembro, segundo o anúncio.

Para quem toca uma empresa brasileira com agente de IA no atendimento, no backoffice ou no código, o anúncio interessa menos pelo produto e mais pela lista. A Salesforce escreveu, com data, o que ela acha que falta em quem roda agente em produção: alguém que corte a requisição quando o orçamento acaba, alguém que teste o agente depois do deploy, e alguém com o botão. As três coisas existem sem MuleSoft. O que o anúncio faz é dar nome e data a cada uma.

O botão existe; a decisão de apertar chega em janeiro

O release separa o que está no ar do que está prometido, e a separação importa mais que a lista de nomes. A tabela abaixo é a seção de disponibilidade do anúncio, traduzida.

Seção "Availability" do anúncio da Salesforce de 27/10/2026. O próprio texto avisa que pode citar recursos ainda em desenvolvimento e que a decisão de compra deve se basear no que está liberado.

Lido assim, o anúncio tem duas metades. A metade que impede o dano (teto de gasto, botão) está pronta. A metade que detecta o dano (avaliação em produção) está prometida para o mês que vem, e a ligação entre as duas, o botão apertado sozinho quando a avaliação reprova, para daqui a dois ou três meses. Até lá, quem aperta o botão é uma pessoa, depois que alguém percebeu o problema. A Salesforce chama isso de sair da "IA de dedos cruzados" para o controle contínuo. Hoje o que está vendido é a parte dos dedos.

Teto de gasto na porta do modelo, não na fatura

O Model Wallet é a peça do pacote que mais vale a pena entender, porque ela resolve um problema que não é da Salesforce, é de qualquer um que paga API de IA. A documentação da MuleSoft descreve o mecanismo em uma frase: o wallet limita o gasto em tokens ou dólares de um chamador contra um provedor, e o proxy bloqueia as requisições quando o orçamento acaba. A palavra que importa é bloqueia. O corte acontece na requisição, antes de ela chegar ao modelo.

Isso é diferente do que os provedores de API oferecem por padrão. OpenAI, Anthropic e Google deixam configurar teto de gasto, e contamos onde fica o botão de cada um quando chaves salvas no painel do OpenCode produziram, nos relatos reunidos pela TechCrunch, alertas de gasto durante a madrugada e cobranças de centenas de dólares para a maioria dos atingidos. O teto do provedor funciona, mas ele vale para a soma de todos os agentes daquela conta ou daquele projeto. Um teto na porta do modelo, por agente e por equipe, é a mesma ideia com granularidade: o agente de cobrança tem o orçamento dele, o de atendimento tem outro, e nenhum dos dois consome o do outro.

Esse desenho não é novidade de produto. É a prática que descrevemos em março, no guia de redução de custo de IA generativa: budget por tenant, limite de tokens por requisição, bloqueio de loop e retry silencioso. O que a Salesforce fez foi empacotar a prática dentro do gateway que o cliente dela já tem e cobrar por ela. Nos projetos, colocamos o modelo atrás de um proxy próprio com limite por usuário ou por tenant; a diferença entre fazer e comprar está na seção da conta, mais abaixo.

Sobre as políticas de otimização, o release diz que elas cortam o uso de tokens em até 75% por cache semântico, compressão de payload e corte de resposta, e acrescenta, entre parênteses, que o número vem de cenários de teste. É o teto de um teste do próprio fornecedor, sem método publicado. Não entra na conta de ninguém até a empresa medir no tráfego dela.

Avaliar em produção: menos da metade faz

O release afirma que menos da metade das organizações com agentes os avalia em tráfego real, e aponta para a pesquisa State of Agent Engineering, do LangChain. Fomos ao relatório. Entre os 1.340 respondentes, colhidos entre 18 de novembro e 2 de dezembro de 2025, 37,3% rodam avaliação online, em tráfego real; entre os que têm agente em produção, 44,8%. Avaliação offline, em conjunto de teste, chega a 52,4%. E 89% dizem ter alguma forma de observabilidade. A frase da Salesforce fecha com o número, e o número diz algo mais preciso do que a frase: quase todo mundo olha o agente, metade testa antes de subir, menos da metade testa depois.

A diferença entre olhar e testar é o que o Agent Evals promete cobrir. O cenário que o release usa para explicar é hipotético, e o próprio texto diz isso: um varejista troca o modelo do agente de pedidos por um mais barato para cortar custo; os testes agendados detectam que o agente passou a dar informação errada sobre pedido atrasado; a ferramenta pede aprovação para colocar o agente em quarentena; a equipe ajusta as instruções, roda a avaliação de novo no modelo barato e só então devolve o agente à produção. Não é um caso de cliente. É a sequência que a Salesforce quer que o cliente imagine, e ela é razoável: a troca de modelo para economizar é o tipo de mudança que se faz num campo de configuração, sem passar por teste.

Há um custo nessa vigilância que o release não menciona e a documentação menciona. A detecção de agente rebelde, que já está na documentação, checa cada prompt contra as regras configuradas usando chamadas extras de inferência, e isso aumenta o uso de tokens; sem regra configurada, a política encaminha tudo e não detecta nada. É razoável esperar o mesmo do Agent Evals, e a Salesforce não diz quanto. Vigilância é mais inferência. Quem compra teto de gasto para controlar token precisa saber que o detector também gasta token.

O botão só desliga o que passa pelo gateway

O botão de desligar, que a Salesforce vende como Agent Kill Switch, está em disponibilidade geral desde setembro, e o press release daquele mês descreve o escopo: a intervenção pode ser limitada a uma requisição, uma sessão, uma instância de agente ou um tenant inteiro; o bloqueio é aplicado no model proxy, em todos os proxies de uma vez; a restauração devolve o agente ao estado anterior; e cada ação fica num log encadeado por hash. O exemplo do release é conter um agente problemático sem desligar os doze que rodam corretamente ao lado.

A documentação da MuleSoft explica como o botão sabe quem desligar. Rogue Agent Detection e Agent Kill Switch são políticas aplicadas em cada model proxy; elas identificam o agente pelos claims de um JWT validado, e o agente em quarentena fica bloqueado em todo proxy que tenha a política. Os pré-requisitos listados são concretos: Omni Gateway na versão 1.13.5 ou superior, agentes registrados e ligados aos proxies, cada agente cadastrado como identidade de serviço no provedor de identidade da empresa, com o identificador do agente e o do usuário dentro do token, e a validação de JWT ativa em cada proxy protegido.

Essa lista é a cerca do produto. O botão desliga o que passa pelo gateway com um token válido. Um agente que chama o provedor de modelo direto, com uma chave de API no código, não passa pelo proxy e não tem o que ser bloqueado ali. Andrew Comstock, que dirige MuleSoft e Agent Fabric na Salesforce, admitiu ao VentureBeat que bloquear o acesso pelo gateway não necessariamente para todo processo rodando numa plataforma externa. É honesto e é a limitação central: o controle vale para o tráfego que a empresa conseguiu colocar atrás da porta. Para o resto, continua valendo a cerca de rede, que é outro mecanismo e que tratamos quando a NVIDIA abriu o OpenShell.

Comstock também disse que o Agent Fabric não é específico da Salesforce e que o cliente não precisa do Agentforce para usá-lo, e que a necessidade depende mais de quantos frameworks e provedores a empresa usa do que do tamanho dela. É alegação de executivo, não medida. Mas o argumento tem lógica: quem tem um agente numa plataforma só já tem o painel dessa plataforma; quem tem cinco agentes em três plataformas não tem painel nenhum.

A conta em reais da porta de entrada

O release não traz preço. A página de preços da MuleSoft, consultada em 29/10/2026, diz que o portfólio começa em US$ 2 mil por mês, cobrado anualmente, com Mule Credits como unidade de consumo; a modalidade de compromisso tem mínimo de US$ 50 mil por ano; e a opção sem limite tem preço sob consulta. A página não diz se Agent Fabric, Agent Evals, Model Wallet ou Omni Gateway têm preço próprio, e a oferta de gestão de agentes manda falar com vendas. O VentureBeat registrou que não existe preço público separado para as avaliações.

Pela nossa conta, com a PTAX de venda de 28/10/2026 (5,3420), a porta de entrada do portfólio dá R$ 10.684 por mês, ou R$ 128.208 por ano, antes de IOF, spread de cartão e tributos. O mínimo da modalidade de compromisso dá R$ 267.100 por ano. É o ingresso do portfólio MuleSoft, não o preço do Agent Fabric, que pode ficar acima disso ou dentro disso dependendo do pacote. O que a conta diz é a ordem de grandeza: se o Agent Fabric exigir o pacote mínimo do portfólio, o controle de agente comprado da Salesforce é um contrato de seis dígitos em reais por ano, e a Salesforce não publica se exige. É essa ordem de grandeza que define quem é o comprador.

A lista de custo total, preenchida com o que o caso publica:

Lista preenchida só com o que o anúncio, a documentação e a página de preço publicam. As lacunas ficam como SEM DADO.

Para quem isto não vale

Para a empresa com um agente numa plataforma só. O painel dessa plataforma já mostra o gasto, e o teto do provedor de API, mesmo grosseiro, já segura a madrugada, se alguém o configurou. Um plano de controle entre plataformas resolve um problema que essa empresa ainda não tem.

Para quem não consegue colocar o tráfego atrás do gateway. Agente embarcado em produto de terceiro, chamada direta ao provedor com chave no código, ferramenta de código rodando na máquina do desenvolvedor: nada disso passa pelo proxy a menos que seja apontado para ele, e o botão não alcança o que não passa. A pergunta antes de comprar não é "quantos agentes eu tenho", é "quantos dos meus agentes eu consigo fazer passar por uma porta".

Para quem precisa da avaliação contínua hoje. O anúncio a coloca em beta em novembro e em disponibilidade geral em janeiro, e o botão disparado por ela também só em janeiro. Quem compra agora compra teto de gasto e botão manual, e o próprio release pede que a decisão se baseie no que está liberado.

E para quem está abaixo da porta de entrada. Um portfólio cuja porta de entrada é R$ 128 mil por ano antes de tributos faz sentido para a operação que já gasta mais que isso em inferência ou que já tem MuleSoft por outros motivos. Para a empresa média brasileira com dois ou três agentes, o mesmo controle cabe num proxy próprio, e é disso que trata a seção seguinte.

O que copiar sem comprar nada

O anúncio é útil como lista de requisitos, e a lista cabe em três perguntas por agente: quem é o dono, qual é o teto de gasto, quem tem o botão. O que vemos nos projetos é que as duas primeiras perguntas chegam no segundo mês de contrato: quem compra assento ou crédito de IA em quantidade pergunta o que o gasto comprou e como dividir o orçamento entre áreas, e o pedido de gerenciamento de créditos aparece até em lead de plataforma de agente. O custo unitário decide a compra: já vimos uma escolha de plataforma de atendimento por IA ser feita pelo custo por minuto, comparado entre cinco fornecedores, antes de qualquer conversa sobre qualidade.

Sem MuleSoft, os três mecanismos do anúncio têm equivalente, e nenhum exige contrato com a MuleSoft:

• teto na porta do modelo: um proxy próprio na frente do provedor, com orçamento por agente ou por tenant e corte da requisição quando o orçamento acaba, somado ao teto da conta no próprio provedor como segunda linha. É o desenho do guia de redução de custo, e é o que o Model Wallet faz por dentro;
• avaliação em produção: uma amostra diária das conversas reais de cada agente, julgada por critério escrito, por pessoa, por modelo ou pelos dois, com o resultado num lugar que alguém olha;
• botão por agente: cada agente com identidade própria no provedor de identidade e credencial própria no proxy, para que revogar uma credencial desligue um agente e não todos. O que a MuleSoft exige como pré-requisito é, na prática, o que torna o botão possível em qualquer arquitetura: agente sem identidade própria não tem como ser desligado sozinho no gateway.

A decisão desta semana cabe numa planilha de uma página: cada agente que roda hoje na empresa, em que plataforma, quem responde por ele, qual é o teto de gasto dele e quem tem a credencial para desligá-lo. A linha que ficar vazia é o risco que a Salesforce está vendendo para cobrir. Se um agente seu começar a responder errado às duas da manhã, quanto ele gasta e com quantos clientes ele fala até alguém perceber?

Fontes, datas e classes

A leitura de que a parte que impede o dano está pronta e a parte que o detecta está prometida é nossa.