Claude para o Salesforce Service Cloud: todas as rotas de conexão em 2026

Resumo

A Salesforce e a Anthropic anunciaram em 14 de outubro de 2025 que o Claude seria um modelo fundacional preferido no Agentforce para setores regulados. Quase todo mundo entendeu isso como «o Service Cloud agora roda no Claude». Não roda. A própria página de configuração da Salesforce lista três opções de modelo e ainda recomenda a que roda o GPT-4.1, e a opção Claude hoje entrega o Haiku 4.5, não o Opus.

A rota que realmente melhorou em 2026 é a direção oposta. Os servidores MCP hospedados chegaram à disponibilidade geral em 29 de abril de 2026, a Salesforce publicou um guia de configuração do Claude passo a passo cinco semanas depois, e agora é possível fazer o Claude ler, consultar e atualizar casos em uma org de produção, com suas próprias permissões aplicadas a cada chamada.

O que nenhuma rota faz é enviar a resposta. Não existe ferramenta sendEmail, postCaseComment ou replyToCase em nenhum lugar do catálogo. Todo caminho para em «redigido, registrado, pronto» e devolve o envio para um humano ou para código Apex personalizado que você mesmo escreve. Essa lacuna é exatamente o motivo pelo qual construí a integração da eesel com o Salesforce do jeito que construí: ela se junta ao Service Cloud, treina nos seus casos fechados e consegue de fato apertar o botão de enviar por 0,40 $ por caso atendido.

Por que isso me importa mais do que à maioria

Eu construo agentes de IA na eesel, e o Salesforce foi a integração que me pediram antes mesmo de eu lançá-la. Duas das derrotas mais claras da nossa história de vendas foram equipes de suporte de médio porte que gostavam do produto e mesmo assim foram embora, porque na época não conseguíamos nos conectar à org de Service Cloud delas. Uma delas rodava cerca de 900 casos por mês e nos disse claramente que a falta de suporte nativo à Salesforce era um motivo de ruptura. Você não esquece os negócios que perde por causa de um conector que falta.

Então, quando digo que as rotas abaixo param antes de enviar uma resposta, isso não é uma alfinetada competitiva. É a mesma parede em que passei meses. Fazer uma IA ler o Salesforce é trivial. Fazer com que ela feche o ciclo de um e-mail voltado ao cliente, dentro do sistema de tickets do Salesforce e seus limites de governança, é a parte difícil, e é a parte que quase todo artigo de «conecte o Claude ao seu CRM» pula.

Primeiro, o que nenhuma dessas rotas faz

Comece por aqui, porque isso reenquadra tudo o que vem a seguir.

O catálogo MCP hospedado da Salesforce é bem construído. O servidor SObject Reads traz seis ferramentas, o servidor SObject All traz onze, e os casos estão explicitamente dentro do escopo: os próprios prompts de exemplo da Salesforce incluem «Me dê um resumo de todos os casos abertos nos últimos 7 dias para contas do setor de serviços financeiros».

Procure nesse catálogo, porém, uma forma de responder ao cliente, e você não encontra nada construído especificamente para isso. Nenhum sendEmail. Nenhum postCaseComment. Nenhum replyToCase. O que existe é o genérico createSobjectRecord, que aceita qualquer nome de objeto e um pacote de valores de campo. Então o caminho de resposta é: criar um registro CaseComment ou EmailMessage, e torcer para que a automação da própria org o capture e realmente despache algo.

Na maioria das vezes não vai, e o motivo é uma peculiaridade do objeto EmailMessage que constantemente pega as pessoas de surpresa.

Criar um EmailMessage registra que um e-mail existe. Não envia nenhum. O campo Status é somente leitura, exceto na transição de New para Read, então você não pode simplesmente mudá-lo para «enviado» e considerar concluído. O envio de fato é uma segunda chamada separada: a ação padrão emailSimple via REST, ou Messaging.SingleEmailMessage em Apex. Duas chamadas, dois modos de falha, e logEmailOnSend vem como false por padrão, então o que você acabou de enviar pode nem aparecer no caso.

Toda rota abaixo para do lado esquerdo dessa lacuna. Só o Apex personalizado ou um Flow que você mesmo escreve a cruza.

As cinco rotas, lado a lado

Nenhuma dessas é um produto «Claude para Service Cloud», porque a Salesforce nunca lançou um. O Claude chega aos seus casos por uma dessas cinco portas, e escolher a errada custa um trimestre. Se você ainda está decidindo se vale usar o stack nativo, nosso panorama sobre a melhor IA para o Service Cloud cobre as opções fora da Salesforce ao lado dessas aqui.

Rota 1: mudar o Agentforce para o Claude

Essa é a que as pessoas querem dizer quando falam «estamos rodando Claude no Salesforce», e é uma única configuração para toda a org.

Você a encontra em Setup, no Quick Find de Audit, Analytics, and Monitoring, depois Einstein Audit, Analytics, and Monitoring Setup, depois «Select the Model for Agentforce». A página da Salesforce Select Agentforce Model Option lista exatamente três opções:

• Salesforce Default, que a Salesforce recomenda, rodando o GPT-4.1 para agentes criados no novo Agentforce Builder e o GPT-4o para os antigos
• AWS-Hosted, que é o Anthropic Claude Haiku 4.5 na Amazon Bedrock
• Google Gemini, que é o Gemini 3.5 Flash na Vertex AI

Vale a pena parar em três coisas dessa lista. O Claude é uma opção, não o padrão, e a própria recomendação da Salesforce continua sendo a apoiada pela OpenAI. A escolha é para toda a org, então se aplica a todos os seus agentes do Agentforce, de Service e outros, a menos que você a substitua por agente no Agent Script. E o modelo por trás desse alternador é o pequeno: a opção AWS-Hosted mudou do Claude Sonnet 4 para o Haiku 4.5 na semana de 18 de maio de 2026.

A Salesforce é refrescantemente direta sobre o custo de migração ao trocar. Da mesma página: «Compared to OpenAI, Anthropic tends to be more sensitive to the nuances in the input payload. Anthropic returns more accurate and reliable responses if the prompts are clear, concise, and thorough.» Ela até aponta para a documentação de engenharia de prompts da Anthropic. Leia isso como o que é: seus templates de prompt existentes vão precisar ser retestados, e uma troca de modelo não é uma mudança de configuração que se faz numa sexta-feira qualquer.

Mais um alerta do próprio texto da Salesforce, que importa se você está trocando por motivos de conformidade: mesmo depois de escolher uma opção de modelo, tarefas específicas como classificação de subagentes ou citações ainda podem usar modelos próprios da Salesforce. O alternador não é uma vedação hermética, e essa é uma das limitações de IA do Service Cloud que vale mais a pena levantar em uma revisão de segurança do que descobrir depois.

O que você realmente ganha

O argumento honesto a favor dessa rota não é a qualidade do modelo, é o limite de confiança. A Anthropic afirma ser o primeiro provedor de LLM totalmente integrado dentro do limite de confiança da Salesforce, e a própria documentação da Salesforce respalda isso: na página Supported Models, só os modelos da Anthropic e da Amazon Nova carregam essa marcação. Nenhum modelo OpenAI ou Google da lista carrega.

Concretamente, a Salesforce afirma que o tráfego permanece dentro da própria nuvem privada virtual, é criptografado com no mínimo TLS 1.2, se conecta à Bedrock via AWS PrivateLink, e que os provedores de modelo não conseguem acessar dados do cliente e nada é armazenado na Bedrock. Se a sua revisão de segurança é o motivo de a IA estar travada na sua org, esse parágrafo é o motivo para olhar para o Claude. É um argumento muito mais forte do que qualquer benchmark, e faz mais por uma aprovação de governança de IA do que qualquer ranking de modelos jamais fará.

E o que isso custa

Orgs de Government Cloud devem parar de ler aqui: a tabela de disponibilidade do Government Cloud lista o Claude Haiku 4.5 e o Claude Opus 4.5 como indisponíveis.

Rota 2: escolher um modelo Claude específico no Prompt Builder, Apex ou na Models API

O alternador do Agentforce te dá um modelo. Essa rota te dá oito, e é a que se usa quando uma tarefa específica de atendimento de caso merece um cérebro maior do que o Haiku.

A nota da Salesforce na página de configuração descreve a saída de emergência: embora o Agentforce fique limitado a poucas opções de modelo, uma ação personalizada usando um template de prompt, Apex ou a Models API pode referenciar qualquer modelo gerenciado pela Salesforce ou trazido por você.

Então um template no Prompt Builder pode rodar o Opus enquanto o próprio agente roda o Haiku. Essa é a forma sensata de gastar com um modelo maior: no punhado de tarefas em que a qualidade do raciocínio aparece no resultado, em vez de em cada turno de cada conversa. Escrever resumos de casos é o candidato óbvio.

Três nomes antigos foram redirecionados em vez de removidos. Claude3Haiku agora cai no Haiku 4.5, Claude37Sonnet no Sonnet 4.5 desde 26 de fevereiro de 2026, e Claude4Sonnet no Sonnet 4.6. Se você fixou um nome de API há um ano, hoje está rodando silenciosamente um modelo diferente.

Também existe um caminho de trazer seu próprio modelo, disponível no Enterprise, Performance ou Unlimited com um complemento Einstein for Sales, Platform ou Service. Ele suporta exatamente quatro provedores: Amazon Bedrock, Azure OpenAI, OpenAI e Vertex AI. Não existe um conector direto da Anthropic, então trazer seu próprio Claude significa trazer sua própria conta Bedrock. O incentivo para isso é real: segundo a Salesforce, modelos BYO consomem 30% menos Einstein Requests do que os gerenciados.

O limite que pega todo mundo

Aqui está a única coisa que eu colaria num post-it antes de qualquer pessoa na sua org prometer um resumidor de casos com Claude.

Com o mascaramento de dados ativado no Einstein Trust Layer, cada modelo fica limitado a 65.536 tokens de contexto. A janela de um milhão de tokens do Opus 4.8 encolhe para cerca de seis por cento de si mesma. Para recuperar a janela completa, é preciso desligar o mascaramento, que é exatamente o recurso pelo qual você ligou o Claude em primeiro lugar.

Para uma carga de trabalho de suporte, isso é uma mordida real. Um caso escalado longo, com uma dúzia de trocas de e-mail, histórico citado e alguns anexos, vai passar dos 65 mil tokens, e o modelo verá silenciosamente menos do thread do que você imagina. Os limites de taxa por modelo também valem a pena conferir: o Haiku 4.5 é o mais apertado, com 250 solicitações por minuto, enquanto os Sonnets e o Opus 4.6 em diante recebem 1.000. Para a gama completa de modelos e o custo de cada nível fora da Salesforce, veja nosso detalhamento de preços do Claude.

Rota 3: servidores MCP hospedados, a rota para a qual a Salesforce escreveu um guia de Claude

Essa é a rota mais nova, e a que eu de fato começaria, porque a Salesforce fez o trabalho de integração por você e depois escreveu as instruções.

Os servidores MCP hospedados chegaram ao GA em 29 de abril de 2026, disponíveis para orgs Developer, Enterprise, Performance e Unlimited. O enquadramento do post de GA cita o Claude diretamente: «Whether your users live in Slack, Claude, ChatGPT, or something else entirely, MCP means they can work with Salesforce without switching contexts.» Cinco semanas depois, a Salesforce publicou seu próprio guia de configuração do Claude, um passo a passo de verdade para Claude Desktop e Claude Code.

Existem quatro servidores padrão de SObject, todos desativados por padrão, e um admin precisa ligar um deles:

As ferramentas do servidor de leitura são getObjectSchema, soqlQuery, find, getUserInfo, listRecentSobjectRecords e getRelatedRecords. O servidor de mutações adiciona createSobjectRecord, updateSobjectRecord e updateRelatedRecord. O próprio conselho da Salesforce, que eu seguiria, é começar pelo servidor somente leitura em um sandbox: «It's read-only, risk-free, and immediately useful.»

Esse servidor somente leitura já é o suficiente para fazer trabalho útil. Peça ao Claude quais contas têm mais casos abertos nesta semana, faça-o puxar os contatos e oportunidades relacionados, identificar o padrão por trás de um pico. É o mesmo tipo de valor de uma integração do Claude com qualquer outro sistema de registro, exceto que o modelo de permissões é o próprio da Salesforce.

O modelo de segurança é a melhor parte

Toda transação roda como o usuário autenticado, sem contas de serviço anônimas. CRUD, segurança em nível de campo e regras de compartilhamento se aplicam, e como o post de GA coloca, se o agente atualiza um registro, o nome dessa pessoa aparece na trilha de auditoria. Existe um escopo de OAuth dedicado, mcp_api, que concede acesso MCP sem conceder as APIs REST existentes.

A Salesforce também é honesta sobre onde as barreiras terminam. As ferramentas da plataforma trazem anotações readOnlyHint e destructiveHint, mas a página de melhores práticas diz claramente: «Annotations are hints, not enforcement. Not all clients read or respect them.» Ferramentas personalizadas de Flow e Apex são potencialmente destrutivas por padrão, a menos que você mesmo defina as anotações. Esse é o tipo de ressalva que a maioria dos fornecedores esconde, e eu aprecio que ela esteja na documentação.

Configurando

A lista completa, do guia Configure Claude da Salesforce:

1. Ative o servidor. Setup, pesquise MCP Servers, aba Salesforce Servers, escolha um servidor, Activate. Copie o nome de API e a URL do servidor.
2. Crie um External Client App. A Salesforce é direta aqui: «Connected Apps aren't supported.» Isso pega de surpresa quem constrói na plataforma há uma década.
3. Defina a URL de callback como https://claude.ai/api/mcp/auth_callback para Claude web e Desktop, ou http://localhost:38000/callback para Claude Code.
4. Defina os escopos de OAuth como mcp_api mais refresh_token ou offline_access. O escopo genérico api é o errado.
5. Marque Require PKCE e «Issue JWT-based access tokens for named users». Desmarque as duas caixas de «require secret».
6. Espere até 30 minutos para o app se propagar. Isso é documentado e real.

Sandbox e produção diferem apenas por um segmento de URL, /v1/<server> versus /v1/sandbox/<server>.

No lado do Claude, não há um cartão de primeira parte da Salesforce no diretório de conectores para clicar. A Salesforce aparece lá só dentro de agregadores de terceiros, então o caminho documentado é Adicionar conector personalizado, colar a URL do servidor, colar a chave de consumidor do External Client App em OAuth Client ID nas Advanced settings, conectar. O Slack, em contraste, tem um cartão de primeira parte, o que diz algo sobre em que ponto do ciclo de vida cada integração está. O lado do aplicativo desktop disso é abordado no nosso post integração do Claude Cowork com o Salesforce.

Espere um pouco de atrito na primeira tentativa. Um issue aberto no repositório MCP da Anthropic acompanha uma falha em que o OAuth se completa, a Salesforce confirma que o token foi emitido, e a primeira chamada de ferramenta mesmo assim retorna «Authorization with the MCP server failed». Vários comentaristas reproduzem isso contra orgs Enterprise de produção. A correção da comunidade é reduzir a seção de segurança do External Client App a apenas PKCE mais JWT para usuários nomeados, e verificar se o servidor realmente estava Activated no API Catalog, e não apenas presente. Como um comentarista coloca: «not a bug, it's a missing setting.»

Agentes do Agentforce como ferramentas do Claude

Existe um passo adicional que a Salesforce documenta: expor agentes do Agentforce como ferramentas MCP, para que o Claude consiga delegar a um agente que já conhece sua org. O próprio exemplo do documento é um agente de triagem de suporte que analisa uma descrição de caso, determina a gravidade, sugere passos de resolução de problemas e identifica a equipe de roteamento. É um encaixe muito bom para o trabalho de triagem de tickets, e está próximo do que o roteamento de bots nativo já tenta fazer.

Duas coisas moderam meu entusiasmo. Só agentes construídos com o novo Agent Script Builder são suportados, então agentes antigos primeiro precisam ser atualizados, o que é um projeto à parte além da sua implementação do Agentforce. E o tempo verbal é inconsistente entre as próprias páginas da Salesforce: o post de GA de abril diz «soon, you'll be able to open up even more possibilities by invoking Agentforce agents via MCP», enquanto o documento da ferramenta se lê como se já estivesse ao vivo. Trate essa rota como mais nova e mais instável do que os servidores SObject.

Rota 4: o servidor MCP do DX, que não é a que você quer

Procure por «Salesforce MCP server» e você vai cair primeiro no @salesforce/mcp no GitHub, porque é mais antigo e tem estrelas. Não é a rota para um projeto de Service Cloud.

Ele roda localmente via stdio contra orgs que você já autorizou no seu laptop, traz mais de 60 ferramentas, e o Claude Code é um cliente de primeira classe documentado com um bloco de configuração para copiar e colar no README. Tudo bem até aqui. O problema é o que essas 60 ferramentas são.

O conjunto de ferramentas data inteiro é uma única ferramenta, run_soql_query, e é somente leitura. Não existe ferramenta de criar registro, nenhuma de atualizar registro, nenhuma ferramenta de Case em lugar nenhum. O resto é implantar e recuperar metadados, rodar testes de Apex, atribuir conjuntos de permissões, doze ferramentas do DevOps Center, e uma longa cauda de ferramentas de orientação de LWC, Aura e mobile que retornam documentação em vez de dados da org.

Então o servidor DX consegue ler dados de produção com SOQL se você apontar --orgs para produção, e esse é o teto. Ele não consegue criar um caso, postar um comentário ou enviar nada. É uma ferramenta de desenvolvedor que por acaso fala MCP, e ainda está marcada como Beta. Uma aresta cortante que vale conhecer se mesmo assim usá-la: DEFAULT_TARGET_ORG é resolvido a cada chamada de ferramenta, em vez de fixado na inicialização, então trocar sua org padrão muda silenciosamente qual org o servidor consegue tocar.

Rota 5: construir você mesmo na API

Se nada do que foi dito se encaixa, você escreve. Essa é a única rota que cruza a linha de envio, e vale a pena entender a forma da parede antes de dedicar um engenheiro a ela.

O padrão é: assinar novos casos, ler o caso, chamar o Claude, escrever a resposta, enviar. Quatro desses cinco passos têm um limite associado.

Leitura e disparo. Leituras de caso contam contra sua alocação diária de API. O Enterprise recebe 100.000 chamadas mais 1.000 por licença, então o próprio exemplo calculado da Salesforce, de uma org Enterprise com 15 licenças, chega a 115.000 por dia. Unlimited e Performance recebem 5.000 por licença em vez disso. Para o disparo, Platform Events e Change Data Capture compartilham um único pool de entrega: 25.000 eventos por 24 horas no Enterprise, 50.000 no Unlimited.

E o Change Data Capture te limita a cinco entidades selecionáveis para toda a org. Case, EmailMessage, CaseComment, Contact e Account são toda a alocação, sem nada sobrando para qualquer outra coisa que sua empresa queira transmitir. Se você também estivesse planejando automação de casos sobre o mesmo stream de eventos, esse orçamento já está gasto.

Chamar o Claude. No Apex você tem 100 callouts por transação e um orçamento acumulado de callout de 120 segundos, aditivo em cada chamada dentro da transação. Raciocínio agêntico de múltiplos passos não cabe em uma transação síncrona, então você vai imediatamente para métodos queueable ou future.

A regra que morde mais forte é a de ordenação. Você não pode fazer um callout depois de uma operação DML pendente. O design óbvio, marcar o caso como em andamento, chamar o Claude, escrever a resposta, é ilegal em Apex. Você reestrutura em torno disso, mas só depois de esbarrar nele.

Envio. De volta ao problema das duas chamadas do início deste post. Criar o EmailMessage para o registro, depois disparar o emailSimple para enviar de fato, limitado a 150 destinatários e 4.000 bytes por campo de destinatário. O threading é opcional via addThreadingTokenToSubject e addThreadingTokenToBody, e sem isso, a resposta do cliente abre um caso totalmente novo em vez de continuar o antigo. Esse é um bug de moral da equipe de suporte, não técnico.

Existe uma versão sem código. Flow HTTP Callout mais External Services mais um Named Credential permite que um admin chame a API do Claude sem Apex, e funciona. O teto dela é que callbacks assíncronos são exclusivos do Apex, então qualquer coisa de longa duração te devolve para o código.

O que isso realmente custa

O Claude não tem um item de custo separado na Salesforce, porque é cobrado através do medidor do Agentforce. E o medidor do Agentforce tem duas configurações que estão longe uma da outra.

A Salesforce publica ambas: 2 $ por conversa, fixo independentemente da complexidade, ou Flex Credits a 20 créditos por ação, o que dá 0,10 $ por ação, vendidos em pacotes de 100.000 créditos por 500 $. A própria tabela comparativa da Salesforce coloca uma interação de gestão de caso em três ações.

Leia essa tabela com atenção, porque ela é a própria Salesforce argumentando contra sua cobrança por conversa. Uma troca de gestão de caso custa 2,00 $ em um medidor e 0,30 $ no outro. Se você está na cobrança por conversa para trabalho de suporte, está pagando cerca de sete vezes o que o mesmo trabalho custa em créditos.

Coloque seus números reais:

Dois números que o widget assume e que você deveria testar contra o seu próprio contrato. Ações por caso é o cerne da questão, e três é o exemplo ilustrativo da Salesforce, não uma promessa sobre sua org. E os 2,5 milhões de Flex Credits inclusos no Agentforce 1 Service a 550 $ por usuário ao mês dão 125.000 ações por ano, o que, com 1.200 casos por mês e três ações cada um, é um pouco menos de três anos de fôlego. Com seis ações cada um, é menos de um ano e meio.

Se você está construindo o business case e não só a integração, nosso detalhamento de preços do Agentforce e o texto mais longo sobre se o Agentforce vale o custo vão mais fundo na conta de assento mais consumo do que eu farei aqui.

Preços de assento estão por baixo de tudo isso

Toda linha traz o aviso «preço inicial, taxas de transação se aplicam», e tudo a partir do Pro Suite é cobrado anualmente. A opção Claude exige Enterprise ou superior com Foundations ou Agentforce 1, então o ponto de entrada real mais barato para o Claude no Agentforce é 175 $ por usuário ao mês antes de sequer uma ação de IA ser medida. A escada completa de edições está no nosso post sobre preços da Salesforce, e o lado da configuração em custo de configuração do Agentforce.

No que os operadores realmente esbarram

A documentação te diz o que é possível. Os fóruns te dizem o que acontece.

Sobre o preço, a reação à cobrança por conversa tem sido constante desde o lançamento:

«I just cannot stomach the pricing model. Sure, $2.40 for agent might beat $15 for a human interaction, but it's much, much more expensive than the $.05 - $.10 you'd pay to make the API calls to OpenAI to do the same thing.»

u/Exotic-Sale-3003, Reddit

Esse comentário é anterior à mudança para os Flex Credits, e os créditos são a resposta da Salesforce a exatamente essa objeção. Mas os créditos trouxeram seu próprio problema, que é o consumo não ter teto:

«There are currently no native hard caps, circuit breakers, or real-time consumption alerts to automatically halt credit drain. The system prioritizes operational continuity for their servers, leaving the customer exposed to un-capped financial liability.»

Agentforce & Digital Wallet lack hard caps for async loops, Reddit

Vale a pena conhecer a mecânica antes de assinar: um comentarista com experiência de produção explica que «1 action = 20 flex credits in production. Sandboxes are 80% consumption, so in sandboxes, 1 action = 16 flex credits», um bom detalhe para quem estiver orçando a partir de um piloto em sandbox.

Sobre confiabilidade, o thread mais afiado que encontrei é um em que um agente do Agentforce em uma fila ao vivo fez a coisa errada com toda a confiança:

«The Agent accessed a internal only knowledge article and shared internal instructions on how to cancel the service. Instead of passing to a real human agent to attempt to resolve the issue, and prevent churn.»

u/Interesting_Button60, Reddit

A causa raiz foi um template de prompt usando o retriever padrão com acesso a todo artigo de Knowledge. Isso não é um problema do Claude nem da OpenAI, é um problema de escopo de conhecimento, e é de longe a forma mais comum de um rollout de IA de suporte dar errado. É também por isso que eu nunca lançaria um agente para uma fila ao vivo sem antes rodá-lo a seco contra casos históricos reais, a mesma disciplina que torna segura a automação de classificação de tickets.

O custo de construção também aparece nas avaliações, e é justo, não demolidor:

«The learning curve is definitely real. It's a powerful platform, but getting a new agent or admin fully comfortable takes time, and the deeper configuration really benefits from someone who already knows the system well. Licensing costs can climb quickly once you start layering on additional features.»

Parth S., Senior Software Engineer, Small-Business, G2

E de um desenvolvedor que passou cinco anos no ecossistema, sobre as restrições de plataforma que tornam a Rota 5 dolorosa: «platform limits are silly in 2025 - 6 meg max heap size for a backend transaction?????» (zdware, Hacker News). Ele está descrevendo os mesmos limites de governança que tornam um callout de IA de vários passos incômodo dentro do Apex.

Como eu de fato decidiria

Quatro situações, quatro respostas.

Você já tem licenças do Agentforce e quer o Claude por motivos de conformidade. Ative o alternador AWS-Hosted e reteste seus templates de prompt. A alegação do limite de confiança é real e específica, e é o argumento mais forte de toda a parceria. Reserve um sprint para retestar prompts, não uma tarde.

Você quer que o Claude ajude sua equipe a trabalhar os casos, não a responder clientes. Servidores MCP hospedados, platform/sobject-reads, em um sandbox. Menos de 30 minutos de configuração, sem ações medidas, e toda chamada carrega as permissões do próprio usuário. Esse é o maior valor por hora de qualquer rota aqui, e o que eu experimentaria primeiro numa sexta à tarde. Ele também vai te contar mais sobre o mix real de intenções da sua fila do que um painel jamais diria.

Você quer um agente autônomo que feche casos de nível um do início ao fim. Nenhuma dessas rotas te leva lá sozinha, porque nenhuma envia a resposta. Ou você constrói Apex personalizado atrás de uma ferramenta MCP, ou compra algo que já cruzou essa parede. O artigo sobre alternativas ao Agentforce é o panorama honesto dessa segunda opção, a nossa incluída.

Você é uma org de Government Cloud. O Claude Haiku 4.5 e o Opus 4.5 não estão disponíveis para você. Planeje em torno da opção Salesforce Default, ou veja o que a superfície nativa do chatbot da Salesforce já cobre.

Um padrão em que eu insistiria independentemente da rota: comece no modo rascunho. Nas chamadas de demonstração em que participo, as equipes que dão certo são quase sempre as que deixam a IA rodar como copiloto, escrevendo respostas sugeridas por algumas semanas, observam o que ela erra, e só então avançam para a automação completa depois de confiarem nela. As que ligam tudo de uma vez são as que acabam em um thread do Reddit sobre um agente que colou instruções internas de cancelamento para um cliente.

eesel AI para o Salesforce Service Cloud

Vou ser direto sobre por que essa seção existe. A eesel costumava perder negócios de Service Cloud pelo motivo mais simples possível, que é o de não conseguirmos nos conectar. Construir a integração com o Salesforce foi a correção, e foi construída especificamente para cruzar a parede da qual trata todo esse post.

A eesel se junta ao Service Cloud, lê casos, contatos e contas, treina no histórico de casos fechados e artigos de conhecimento, e então faz o que nenhuma ferramenta MCP padrão faz: redige e envia a resposta voltada ao cliente, adiciona notas internas, atualiza status e prioridade, e roteia para a fila certa. A configuração é feita em menos de 30 minutos, e não há licença de Agentforce na cadeia. É o mesmo trabalho de IA no Service Cloud, sem a contagem de ações medida.

Duas diferenças que importam frente aos medidores acima. A cobrança é de 0,40 $ por caso atendido, e um caso é um caso: cada resposta, cada acompanhamento, cada pergunta de esclarecimento está dentro dessa única cobrança, então uma conversa difícil não custa mais do que uma fácil. E todo rollout começa simulando contra seus próprios casos históricos, então você vê o que o agente teria dito em tickets reais antes de um cliente ver. Comece grátis com 50 $ de uso e sem cartão, em preços da eesel.

Se você já está bem inserido no Agentforce e satisfeito, continue assim. Se está olhando para um assento de 175 $, uma contagem de ações medida e um caminho de resposta que ainda precisa escrever você mesmo em Apex, esse é o momento em que a eesel vale vinte minutos da sua tarde.