O comparativo que a maioria das empresas faz antes de assinar contrato de plataforma de agente olha preço por conversa, limite de mensagens e SLA de resposta. Nenhuma dessas linhas mede o que decide o custo real da escolha nos próximos cinco anos: quanto custa sair. Em abril de 2026, o analista Kai Waehner publicou o mapeamento mais completo até agora sobre esse ponto cego — cruzando confiança do fornecedor com grau de aprisionamento — e a conclusão incomoda quem já assinou: os fornecedores mais confiáveis não são, necessariamente, os mais fáceis de deixar.
A pergunta que toda proposta comercial de plataforma de agente evita responder é simples: se a empresa quiser trocar de fornecedor daqui a três anos, quanto isso custa — em dinheiro, em tempo, em contexto reconstruído do zero? A resposta nunca está na tabela de pricing. Está espalhada em quatro camadas diferentes, e cada uma prende de um jeito distinto.
O mapa que separa confiança de aprisionamento
O framework de Waehner cruza dois eixos que o mercado costuma tratar como a mesma coisa: confiança — governança de segurança do modelo, tratamento de dado, postura regulatória — e lock-in — dependência técnica que aumenta o custo de trocar. São eixos independentes. Segundo a classificação dele, fornecedores como Microsoft, Salesforce, AWS e SAP caem no quadrante de confiança mais baixa e aprisionamento mais alto — não porque o modelo seja pior, mas porque a integração com o resto do ecossistema (nuvem, CRM, suíte de produtividade) empurra o custo de saída pra cima, independente da qualidade técnica do agente.
Confiar num fornecedor de agente e ficar preso a ele são decisões diferentes — tratá-las como a mesma escolha é o erro que sai caro só depois de três anos de contrato.
Do lado oposto do mapa, opções tecnicamente mais abertas carregam dúvida maior sobre governança e soberania de dado. Não existe fornecedor que resolva os dois eixos de graça — existe fornecedor que esconde melhor em qual quadrante está, geralmente atrás de um discurso de integração que soa como conveniência e funciona como cadeado.
Os quatro vetores que prendem, não o fornecedor que promete
O mapeamento identifica quatro mecanismos de aprisionamento que valem pra qualquer plataforma de agente, independente da marca no contrato:
- Dependência de API. A arquitetura do agente se molda às escolhas de design do fornecedor — formato de chamada, limites de contexto, comportamento de retry — e cada decisão técnica tomada em volta disso vira reescrita quando o fornecedor muda.
- Captura de framework. A camada de orquestração proprietária — como o agente decide qual ferramenta chamar, em que ordem, com que guardrail — composta ao longo do tempo, sem exportação simples pra outro motor.
- Gravidade de dado. Contexto acumulado, histórico de conversa, ajuste fino feito em cima do agente: quanto mais a empresa investe em deixar o agente "calibrado", mais caro fica reconstruir esse aprendizado em outro lugar.
- Entrelaçamento de ecossistema. Integração nativa do agente com nuvem, CRM, ERP ou suíte de produtividade — trocar o agente deixa de ser um projeto isolado e vira renegociação de tudo que está em volta.
São os mesmos quatro vetores, adaptados pro mundo de agentes, que já mapeamos entre Databricks, Snowflake e BigQuery no mundo dos data warehouses — a lógica de aprisionamento se repete, só muda a camada onde ela mora.
O modelo virou commodity — o lock-in subiu de andar
Um dado de mercado confirma que pelo menos um vetor está, de fato, enfraquecendo: segundo levantamento da Menlo Ventures, a fatia da OpenAI no gasto empresarial com API de LLM caiu de cerca de 50% em 2023 para 27% no final de 2025, enquanto a Anthropic subiu para perto de 40% no mesmo período. Empresa troca de modelo com uma frequência que seria impensável há dois anos — o modelo, isoladamente, virou item de configuração.
O problema é que o lock-in não caiu junto — ele subiu de andar. Em fevereiro de 2026, o termo "harness engineering" entrou no vocabulário comum do setor, popularizado por Mitchell Hashimoto e pela fórmula que a LangChain ajudou a espalhar: agente é igual a modelo mais harness. Harness é tudo que fica entre a chamada ao modelo e o resultado de negócio — conexão com ferramenta, memória de contexto, lógica do loop do agente, guardrails, infraestrutura de execução. Depois de dezoito meses de operação, o modelo virou uma linha de configuração; o harness virou a arquitetura de verdade — e é ali que mora a camada mais difícil de arrancar, a memória de contexto acumulada.
Um servidor MCP bem desenhado é hoje a força que devolve alguma portabilidade à conexão entre agente e ferramenta — a única camada do harness que caminha pra padrão aberto em vez de formato proprietário. O resto — loop de decisão, guardrail, memória — continua proprietário por design, e é aí que cada fornecedor de plataforma de agente aposta a retenção do cliente.
Quatro perguntas antes de assinar contrato de agente
Antes de fechar contrato anual de plataforma de agente, quatro perguntas separam decisão informada de aposta:
- Quanto do harness é exportável sem reescrita? Orquestração, guardrail e lógica de loop proprietários viram refatoração completa quando o fornecedor muda — pedir essa estimativa antes de assinar, não depois.
- Quanto de contexto acumulado fica preso ao formato do fornecedor? Histórico de conversa, embeddings e ajuste fino feitos dentro da plataforma raramente exportam em formato que outro motor lê.
- Quantas integrações nativas com o resto da stack dependem desse agente especificamente? Se o agente está entrelaçado com CRM, ERP ou suíte de produtividade da mesma empresa, trocar o agente é trocar o entorno inteiro.
- Qual o prazo real de uma migração completa — incluindo o sistema em volta, não só o agente? Proposta comercial mede tempo de implantação; raramente mede tempo de saída.
No caso do Agentforce, os seis modelos de pricing que não se misturam entre si já funcionam, por si, como um vetor de aprisionamento adicional — trocar de plataforma de agente ali significa também reconstruir a lógica inteira de orçamento, não só a integração técnica.
O aprisionamento que ninguém está precificando
O custo de saída raramente é abstrato — costuma vir embutido em outro projeto que a empresa nem chamaria de "trocar de agente". Deixar o Agentforce, por exemplo, implica avaliar uma migração simultânea de CRM — projeto que roda tipicamente entre 18 e 36 meses, segundo análise de switching cost publicada em 2026. Do outro lado, a penetração do Copilot ficou em cerca de 3,3% das licenças corporativas do Microsoft 365 no terceiro trimestre fiscal de 2026 — número lido, à primeira vista, como adoção travada. Na prática, mascara dependência de fluxo de trabalho que se acumula independente do volume de uso: cada automação construída em cima do Copilot Studio, cada dado corporativo indexado, aprofunda o vetor de ecossistema mesmo com adoção formal baixa.
O pico de exposição a lock-in raramente é geral — é específico da conta, e ninguém dentro da empresa é formalmente dono de somar isso antes que o contrato seja renovado.
Boa parte dos pilotos de agente nem chega a esse ponto: pesquisa do MIT encontrada em 2025 aponta que 95% dos pilotos empresariais de IA falham em escalar, com apenas 5% entregando impacto de lucro mensurável. O detalhe que passa batido é que os 5% que escalam raramente auditaram lock-in antes de assinar — sucesso técnico faz a exposição crescer junto com o uso, não diminuir. Consultoria especializada, sem incentivo de revenda de nenhum dos lados, é quem consegue fazer essa auditoria olhando pros quatro vetores — não pro discurso comercial do fornecedor que está do outro lado da mesa.
Perguntas que sempre voltam
Fechando, as dúvidas mais comuns sobre lock-in em plataforma de agentes de IA.
O que é lock-in em plataforma de agentes de IA?
Lock-in em plataforma de agentes é a dependência técnica e operacional acumulada em quatro vetores — dependência de API, captura de framework de orquestração, gravidade de dado de contexto e entrelaçamento com o resto do ecossistema — que torna trocar de fornecedor mais caro do que o contrato original sugere. Não é uma cláusula única no contrato; é a soma de decisões técnicas tomadas ao longo do tempo de uso.
Confiança no fornecedor garante menos lock-in?
Não. Um mapeamento de abril de 2026 cruzou os dois eixos e mostrou que andam de forma independente: fornecedores com governança de segurança e postura regulatória sólidas — alta confiança — podem carregar aprisionamento igualmente alto, quando a integração deles com nuvem, CRM ou suíte de produtividade é profunda. O inverso também vale: opções tecnicamente mais flexíveis costumam levantar dúvida maior sobre governança. Avaliar só um dos dois eixos deixa a decisão incompleta.
Como medir o lock-in antes de assinar contrato de agente?
Com quatro perguntas objetivas: quanto do harness (orquestração, guardrail, lógica de loop) é exportável sem reescrita; quanto do contexto acumulado — histórico, embeddings, ajuste fino — fica preso ao formato do fornecedor; quantas integrações nativas com o resto da stack dependem especificamente desse agente; e qual o prazo real de uma migração completa, incluindo o sistema em volta, não só o agente isolado. Fornecedor que não sabe responder a quarta pergunta, ou desvia dela, é sinal de alerta.