Com modelos intercambiáveis, o lock-in migrou para o harness do agente

O deslocamento do lock-in

O texto argumenta que, à medida que modelos de IA se tornam intercambiáveis, o lock-in de fornecedor deixou de estar na camada do modelo e passou para o harness do agente. Harness é tudo que fica entre a API do modelo e o resultado de negócio: conexões com ferramentas, contexto e memória, loop do agente, guardrails e runtime. O termo circula em uso especializado desde o fim de 2024; em fevereiro de 2026, Mitchell Hashimoto nomeou a prática de “harness engineering” e a LangChain popularizou a fórmula “Agente = Modelo + Harness”. O modelo raciocina; o harness torna o raciocínio útil.

A maioria do conteúdo sobre harness é material de engenharia para quem constrói. A orquestração multi-modelo respondeu qual camada escolhe o modelo; a questão aqui é onde está o custo de troca. Para compradores e arquitetos corporativos, o harness não é detalhe de engenharia: é para onde o lock-in migrou depois que o modelo se tornou permutável.

Evidência e mecanismo

O “Trusted Agentic AI Landscape Q3 2026” documentou uma mudança no mercado corporativo de IA: o lock-in subiu a pilha. O lock-in na camada de modelo morreu como estratégia de fornecedor. Modelos se commoditizam em meses, clientes exigem portabilidade e toda plataforma séria anuncia escolha de modelo. Os fornecedores não ficaram generosos; moveram o lock-in um nível acima, para a camada que não se commoditiza.

Essa camada é o harness. Modelos mudam a cada ciclo, enquanto o harness acumula definições de agentes, integrações de ferramentas, contexto sobre como o negócio funciona e conhecimento operacional sobre o que falha e por quê. Depois de dezoito meses, o modelo é um ajuste de configuração e o harness é a arquitetura. O custo de troca se inverteu, e a maioria dos processos de compra ainda não percebeu.

As cinco camadas e as três formas

Cinco camadas envolvem o modelo, cada uma com um perfil de lock-in. Conectividade de ferramentas e dados é como o agente alcança sistemas; o Model Context Protocol é a força estabilizadora, e construir sobre ele preserva interoperabilidade. Uma ressalva: um padrão aberto com um único implementador dominante é mais aberto que um protocolo proprietário e menos aberto que um padrão com muitos.

Contexto e memória é a camada mais pegajosa: o contexto compõe valor quanto mais acumula, e compõe custo de saída na mesma proporção. O loop do agente tende a ser portável em conceito e proprietário em formato. Guardrails e políticas definem o que o agente pode fazer, com aprovação de quem e sob quais limites; em ambientes regulados, é o que auditores examinam. O runtime executa estado, retentativas, isolamento e escala; runtimes gerenciados são convenientes e também tornam a arquitetura não portável.

Ser agnóstico a modelo não é ser agnóstico a harness. Fornecedores dizem a verdade quando permitem trocar Claude por Gemini, rodar modelo de pesos abertos ou rotear por custo. Mas ninguém promete o segundo, porque o harness é o produto. Há três formas: framework no seu código, runtime gerenciado na nuvem e harness embutido em plataforma de aplicação. Nenhuma é errada; são três acordos diferentes, e o erro é assinar sem ler.

Onde o contexto vive e o que perguntar

Uma pergunta decide mais que qualquer comparação de recursos: o contexto acumulado vive na sua camada de dados ou dentro do harness? Se vive na sua camada, governado e atual, o harness é infraestrutura substituível. Se vive no harness, ele controla a utilidade dos agentes, e sair significa começar de novo.

Antes de comprometer, cinco perguntas: exportação das definições em formato legível por outro sistema; propriedade do contexto; se o runtime pode ser re-hospedado em infraestrutura própria; se a observabilidade entrega trilha de auditoria completa; e custo realista de saída em meses-engenheiro, medido hoje. A diferença entre o que o fornecedor alega e o que demonstra costuma aparecer entre a primeira e a quinta pergunta.

Limites e encaixe na arquitetura

Nem todo time precisa de portabilidade de harness. Quem roda agentes dentro de um SaaS que nunca deixará não ganha nada com definições portáveis; a posição cativa é racional. A comunidade de engenharia acrescenta que harnesses devem permanecer leves, porque cada geração de modelo muda a estrutura ótima do agente e fluxo de controle sofisticado demais quebra na próxima versão. A recomendação é manter a lógica esperta fina e descartável e investir no durável: estado, política, auditoria e portabilidade das definições.

O harness é o loop interno de um agente. Ele não coordena a empresa. Orquestração de workflow é o loop externo que coordena agentes, sistemas e humanos, com aprovações, agendas, retentativas, linhagem e trilha de auditoria. Inteligência de processos indica quais processos merecem agentes, e integração de dados alimenta tudo, porque um agente operando com dados obsoletos produz respostas erradas com confiança, por melhor que seja o harness. A conclusão: escolha o modelo pela capacidade; escolha o harness pelo que ele permite manter.