MCP e arquitetura headless: o que acontece quando o agente escolhe a ferramenta errada
Sem dependency graph e telemetria real, agentes autônomos fabricam dívida técnica em velocidade de máquina
Com MCP e arquitetura headless, o agente passa a decidir sozinho qual ferramenta usar, sem humano no meio validando a escolha. O risco maior não é o agente errar, é ele nunca ter contexto suficiente da org para perceber que errou.
Semana passada eu estava numa call de arquitetura discutindo governança de metadata para um cliente que está começando a plugar Agentforce em processos internos, e caiu uma pergunta que me travou por uns segundos: "quando o agente decide sozinho qual ferramenta usar, quem responde se ele escolher a errada?". Não tinha resposta pronta. E é exatamente esse o problema que fica evidente quando você para pra pensar no MCP (Model Context Protocol) combinado com arquitetura headless.
Até pouco tempo, todo fluxo de decisão de ferramenta passava por um humano. Você comparava opções, lia review, escolhia o skill ou a integração que fazia sentido pro caso de uso. Com MCP padronizando a forma como agentes descobrem e chamam ferramentas, e com a Salesforce empurrando forte para arquitetura headless (onde não existe necessariamente uma tela nem uma pessoa no teclado), esse humano no meio saiu da equação em boa parte dos cenários. Quem decide qual capability entra em ação agora é o orquestrador. E ele decide baseado em uma coisa só: o que funciona de verdade, testado na hora, sem paciência para descrição bonita que não entrega.
Isso muda a régua de qualidade de tudo que a gente constrói. Um agente não lê a documentação de uma ferramenta e fica encantado com o markdown bem formatado. Ele testa a promessa contra o resultado, imediatamente, toda vez que chama aquele skill ou aquele MCP server. Se a descrição promete uma coisa e a ferramenta entrega outra, ou entrega pela metade, o agente aprende e desvia da rota na próxima chamada. Não tem relacionamento a preservar, não tem call de sucesso pra segurar cliente insatisfeito. É o processo de procurement mais literal que já existi na plataforma.
O risco real não é o agente escolher errado, é ele nunca saber que errou
O ponto que mais me interessa como arquiteto não é o glamour de "agente autônomo escolhendo ferramenta". É o que acontece quando esse agente não conhece de verdade a sua org. Eu já vi caso de Flow que resolvia rápido e virava dívida técnica em três meses porque ninguém documentou o porquê daquela decisão. Agora imagina isso em velocidade de máquina, sem o intervalo humano que às vezes salva a arquitetura por pura demora.
Um agente que só enxerga nomes de API, sem dependency graph, sem histórico de mudança, sem telemetria de uso real do campo, comete erro estrutural com total confiança. Ele vê um campo chamado Legacy_Discount__c que foi reaproveitado três reorganizações atrás e assume que o nome ainda reflete a função. Ele vê um campo vazio e conclui "não usado", quando na real pode estar vazio por proposital: regra de negócio condicional, integração que só popula em certo cenário, campo que serve de flag para um processo trimestral. Eu já perdi tempo de sobra em projeto de Revenue Cloud explicando pro time por que um campo do Pricing Procedure parecia "morto" mas sustentava uma regra de exceção comercial que só disparava em renovação.
Sem visibilidade de dependência entre metadata, o agente não constrói com cuidado ao redor da sua arquitetura: ele duplica o que já existe, ou reaproveita algo que nunca devia ser reaproveitado, convicto de que está certo. Velocidade sem disciplina de SDLC (requisito, arquitetura, design, build, teste) não reduz dívida técnica. Ela fabrica dívida técnica em velocidade de máquina.
O que realmente separa um agente bem instruído de um perigoso
A diferença não está em qual modelo de linguagem está por trás. Está em três coisas concretas: a descrição da ferramenta precisa ser verdadeira agora, não "verdadeira no roadmap"; a ferramenta precisa resolver o passo inteiro do workflow, não 60% dele; e o resultado esperado, os guardrails e o processo precisam estar explícitos, porque agente que faz goal-seeking sem essa definição entrega a versão que tecnicamente satisfaz a instrução e nada além disso.
Isso importa porque muda o critério de aceite de tudo que a gente documenta e configura na org. Se um agente vai decidir sozinho qual skill, qual Flow, qual integração ou qual MCP server chamar para completar uma tarefa, a qualidade da descrição de cada peça deixa de ser cosmético e vira o principal fator de risco arquitetural. Para arquiteto e admin, isso é praticamente forçar uma disciplina de documentação de metadata que a maioria das orgs nunca teve.
Para quem lidera projeto de Agentforce, o recado é direto: velocidade sem governança de dados, sem mapeamento de dependência e sem definição clara de "feito corretamente" (não só "feito") não acelera entrega, acelera acúmulo de dívida técnica. E dívida técnica em velocidade de agente autônomo é diferente de dívida técnica manual: ela se propaga antes de alguém perceber.
O que me chama atenção aqui não é a tecnologia em si, é o quanto isso expõe orgs que já vivem de gambiarra documentada de boca em boca. A gente sempre soube que metadata mal documentada é risco; agora esse risco ganha um agente autônomo capaz de agir sobre ele em segundos, sem o freio humano que, goste ou não, sempre comprou tempo para a gente perceber o erro antes que ele se espalhasse.
- Antes de expor qualquer Flow, Apex action ou integração como tool para um agente, revise a descrição como se fosse contrato: ela precisa refletir o comportamento atual, não o que está no roadmap.
- Mapeie dependência entre metadata antes de liberar capability para orquestração autônoma. Se você não sabe o que quebra três camadas abaixo quando um campo muda, o agente também não vai saber.
- Trate campo vazio, nome de API legado e metadata reaproveitada como sinal de alerta, não como dado confiável por padrão. Isso vale tanto para revisão manual quanto para qualquer camada de "org intelligence" que você conectar ao agente.
- Defina explicitamente o que é "feito corretamente" em cada processo automatizado, com guardrail declarado, não implícito. Regra de negócio que só existe na cabeça de quem configurou não sobrevive a um agente fazendo goal-seeking.
- Cuidado com o discurso de "org intelligence" genérica: muita ferramenta promete visão de dependência e histórico de mudança, mas não resolve isso com rigor, só superficialmente.
- Não trate número de adoção ou estatística de "X em cada Y agentes escolheram tal ferramenta" como validação técnica. É o tipo de dado que qualquer agente bem instruído descartaria, e você deveria fazer o mesmo.
- Headless architecture remove a tela, mas não remove a sua responsabilidade de arquitetura. Se ninguém está desenhando o SDLC por trás da automação agêntica, alguém vai descobrir isso tarde, com produção quebrada.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.