agente que aprende

Esse é o tipo de comparação que devia estar em todo kickoff de projeto de Agentforce, e quase nunca está. A gente discute modelo, discute latência, discute custo por token — e esquece de perguntar a pergunta que separa projeto que escala de projeto que emperra: existe um loop de melhoria contínua rodando, ou alguém vai precisar abrir chamado toda vez que o agente erra?

O que ficou claro nos dois casos é que o diferencial não estava na sofisticação do prompt inicial. Estava em ter um mecanismo — automatizado ou não — que capturasse o erro, identificasse o padrão e ajustasse a instrução sem esperar reunião de sprint review. Isso é arquitetura, não é prompt engineering. É decidir, desde o desenho, onde fica o sensor que detecta desvio e quem (ou o quê) tem autoridade pra corrigir.

Na prática, isso significa instrumentar o agente com telemetria de qualidade desde o dia um: taxa de fallback pra humano, tempo de resolução, satisfação por intenção. Sem esse instrumento, você não tem loop, você tem torcida. E confiar em torcida pra sustentar um agente em produção é o motivo pelo qual tanto projeto de IA generativa perde tração depois do hype inicial.

O paralelo com o que a engenharia interna da Salesforce fez — minerar comentário de PR pra reescrever instrução de IA automaticamente — é direto. Eles não construíram um agente mais inteligente. Construíram um sistema que sabe quando parar de mudar, porque já não há mais sinal de erro. Isso é maturidade operacional, não é feature de LLM.

Vejo esse debate se repetir em quase todo projeto de conectividade de agente, e a armadilha é sempre a mesma: tratar MCP e API REST/SOAP como se fossem escolha binária, tipo linguagem de programação. Não são. MCP resolve um problema específico — dar ao agente uma camada de descoberta e execução de ferramentas em tempo de conversa, com contexto dinâmico. API resolve outro — integração determinística, testável, versionada, com contrato fechado.

O erro comum é arquitetar pensando em qual tecnologia é 'mais moderna' em vez de qual requisito de negócio está na mesa. Se o agente precisa decidir em tempo real qual ferramenta invocar com base em linguagem natural ambígua, MCP ganha. Se o fluxo é determinístico, auditável, e já vive dentro de um pipeline de integração maduro, forçar MCP ali é gambiarra com nome bonito.

O que muda com o MCP Server hospedado pela Salesforce saindo de beta é que agora essa escolha fica mais barata de testar dos dois lados. Dá pra plugar Claude direto no org, consultar registro, montar relatório, disparar Flow — tudo em linguagem natural — e comparar lado a lado com a integração API tradicional que você já tem rodando. Isso muda o cálculo de custo de experimentação, não muda o princípio de arquitetura.

Minha regra prática: comece perguntando quem toma a decisão de qual sistema chamar — humano com prompt, agente com autonomia, ou pipeline fixo. Essa resposta aponta pra MCP, API, ou híbrido, muito antes de qualquer discussão de performance ou custo.

Toda vez que a Salesforce mostra um caso de uso interno, a tentação é copiar o caso de uso. Aqui o valor está em outro lugar: no agent manager, um cargo novo criado especificamente pra cuidar do ciclo de vida do agente depois que ele vai pra produção. Não é admin, não é analista de dados, não é o dono do processo de negócio. É alguém cujo trabalho é monitorar deriva de comportamento, validar respostas, decidir quando o agente precisa de retreinamento e servir de ponto de escalonamento quando o agente erra feio.

Isso preenche um buraco que quase nenhum projeto de Agentforce que vejo por aí resolveu ainda: quem é o dono operacional do agente depois do go-live? Em CPQ, todo mundo sabe quem é o admin de pricing. Em Agentforce, a resposta costuma ser 'a gente vê depois' — e depois vira nunca, e o agente vira uma caixa preta que ninguém quer tocar.

O detalhe interessante é que foi o jurídico — área historicamente conservadora, avessa a risco, obcecada com auditoria — que topou ser Customer Zero. Isso é sinal de que o caso de negócio pra Agentforce em área de risco alto já passou o ponto de prova de conceito. A questão que sobra é de governança operacional, não de viabilidade técnica.

Se você está desenhando arquitetura de Agentforce agora, essa é a peça que falta no seu blueprint: não é só data model, não é só topic e action. É quem senta na cadeira de agent manager quando o agente sair do sandbox.

Fico desconfiado de estreia perfeita. Não porque duvide da posição — a Salesforce tem escala, tem distribuição, tem ecossistema de parceiro que pesa muito nos critérios de 'completeness of vision' do Gartner. Mas Magic Quadrant mede capacidade de mercado e visão de produto, não mede se o agente que você vai implementar mês que vem vai funcionar bem com o seu data model bagunçado e sua governança de dados capenga.

O risco prático é o efeito manada que isso gera dentro de comitê de decisão executivo: 'a Gartner disse que é Leader, então bora comprar mais licença de Agentforce sem repensar arquitetura de dados'. Isso é o oposto do que deveria acontecer. Posição de Leader é motivo pra você aprofundar due diligence técnica, não pra pular ela.

O que sustenta a posição, no relatório, é orquestração multi-agente, integração nativa com CRM e a profundidade do Data Cloud como camada de contexto. Isso é real e é diferencial de fato. Mas nenhum desses pontos resolve o problema mais comum que vejo em projeto real: dado sujo, processo de negócio mal definido antes de virar prompt, e ausência de métrica de sucesso além de 'o agente respondeu algo coerente'.

Use o selo como munição pra conversa com stakeholder que ainda duvida se vale investir em Agentforce. Não use como desculpa pra pular a parte difícil do projeto, que é sempre a mesma: dado, processo, governança.