a pista da semana

O melhor jeito de entender o MCP é esquecer o hype por um minuto. Ele não deixa o modelo “mais inteligente”. Ele deixa a arquitetura menos gambiarra. E isso, honestamente, já seria suficiente.

Hoje, boa parte dos projetos de IA corporativa sofre do mesmo mal: cada novo contexto externo vira uma integração quase artesanal. Um conector aqui, um wrapper em Apex ali, uma camada de autenticação improvisada, e logo você tem um espaguete elegante o bastante para passar na demo — e frágil o bastante para quebrar no primeiro caso fora da curva. O MCP entra justamente aí: como um contrato comum para expor ferramentas, dados e contexto a agentes.

Em projeto real, o gargalo raramente é o modelo. É o caminho até a informação certa, com permissão certa, no momento certo, com rastreabilidade. Se o Agentforce abraça MCP de verdade, o trabalho do arquiteto sobe um nível: sai o foco em integração ponto a ponto e entra o foco em governança de contexto. Quais capacidades eu exponho? Com que escopo? Com que observabilidade? Essa é a conversa adulta.

Tem um detalhe importante: protocolo não resolve bagunça semântica. Se seu CRM diz uma coisa, o ERP entende outra e o catálogo comercial tem cinco verdades concorrentes, o MCP não faz milagre. Ele organiza o encanamento. A água suja continua sendo problema seu.

Esse post é quase um banho de água fria — e eu digo isso como elogio. A Salesforce basicamente admitiu em voz alta algo que muita equipe aprende tarde: deixar o modelo “se virar” é o caminho mais rápido para criar um agente impressionante por 15 minutos e perigoso por 15 meses.

Os padrões apresentados apontam para um desenho bem mais pragmático: trilhos determinísticos, uso criterioso de ferramentas, grounding, estado controlado e mecanismos de validação antes da ação. Em outras palavras, o agente confiável se parece menos com um chatbot mágico e mais com um sistema distribuído com boas regras de trânsito.

Na prática de projeto, é exatamente isso. O POC costuma sobreviver no happy path. O problema começa quando entram exceção fiscal, dado incompleto, permissão inconsistente, catálogo mal versionado, timeout em API externa e aquele processo interno que “ninguém usa muito”, até alguém importante usar. É nesse momento que arquitetura vence prompt engineering.

Se eu tivesse que resumir a lição em uma frase: LLM bom não substitui desenho ruim. O arquiteto que separar bem decisão, execução e fallback vai entregar algo menos cinematográfico — e muito mais útil.

Quem trabalha com Revenue Cloud sabe: vender assinatura é uma coisa; vender uso medido em alta escala, com tarifação variável, crédito, excedente e reconciliação séria, é outro esporte. E por muito tempo a Salesforce parecia jogar esse segundo jogo olhando do banco.

A aquisição da m3ter importa porque ataca um ponto estrutural. Na economia de IA, software está cada vez mais sendo precificado por consumo, evento, token, chamada, volume processado, capacidade ativa. Se a plataforma quer ser relevante no desenho comercial dessa nova fase, ela precisa tratar metering e rating como núcleo — não como apêndice bonito em cima do quote.

Em cliente real, o drama nunca termina na geração da fatura. Ele passa por captura confiável de eventos, versionamento de regra tarifária, auditoria, disputa de consumo, integração com ERP, impacto em reconhecimento de receita e experiência do cliente quando a conta não bate. Então, sim, a compra é muito boa notícia. Mas não vamos romantizar: adquirir a peça não é o mesmo que ter a arquitetura fim a fim pronta no produto.

Ainda assim, o movimento é forte porque resolve uma dúvida antiga do mercado: a Salesforce entendeu que a monetização da era de IA não cabe só em CPQ clássico. E isso muda o peso estratégico do Revenue Cloud para os próximos ciclos.