Você pode trocar o modelo sob um agente agora. O que é difícil mover é a memória e as skills que ele escreveu.

Quanto mais intercambiáveis os modelos se tornam, mais presa uma empresa pode acabar.

Isso soa ao contrário, então comece pelo fato. Em 8 de outubro, o Google descreveu seu agente Gemini como uma camada de orquestração que roda "em toda a nossa família de modelos Gemini e modelos Claude da Anthropic hoje, e outros modelos privados e abertos líderes no futuro", com uma ferramenta de roteamento que envia cada workload para "o modelo que entrega o máximo de desempenho pelo menor custo possível". Trocar de modelo, nesse design, é uma configuração.

Agora o segundo fato, da mesma keynote. O agente "mantém um único conjunto de memórias, contexto e um grafo de personalização" em todos os dispositivos e canais, e mantém quatro tipos de memória: de sessão, semântica, episódica e procedural, sendo a última "incluindo skills que ele escreve para si mesmo". Agentes coworker ganham armazenamento persistente próprio.

Junte os dois e o custo de troca não desapareceu. Ele se moveu.

O que se acumula agora

Um ano depois de operar agentes como esses, a coisa valiosa no runtime não será o modelo. Será o que os agentes aprenderam e registraram sobre a organização:

• Memória: o que aconteceu, o que as pessoas preferem, qual fornecedor está sempre atrasado, qual aprovador quer o resumo primeiro.
• Skills autoescritas: procedimentos que o agente compôs para fazer trabalho recorrente. Na prática, elas se tornam a descrição de como um processo funciona na prática, muitas vezes mais atual que a oficial.
• Histórico de personalização e roteamento: qual modelo lidou com qual tarefa, quão bem, a que custo.

Nossa visão, e é uma visão e não um fato: esta é uma forma mais pegajosa de lock-in que o lock-in de dados. Dados têm formatos e ferramentas de exportação. O estado acumulado do agente é parcialmente gerado pelo próprio sistema do fornecedor, armazenado no formato do fornecedor, e seu valor depende do runtime que o interpreta. Uma skill escrita para um runtime pode não significar nada para outro.

O que é fácil de mover, e o que não é

Fácil de trocarDifícil de mover

1. O modeloRoteadores e runtimes multi-modelo
2. Prompts e ferramentasTexto e protocolos padrão como MCP
3. Definições de negócioPortáveis se você as possui onde elas vivem
4. MemóriaFormato do fornecedor, proveniência mista
5. Skills autoescritasCodificam como seu trabalho é feito

Por que isso importa mais em trabalho regulado

Em um banco ou uma farmacêutica, um procedimento que é seguido é um procedimento, não importa quem o escreveu. Se um agente escreve uma skill para si mesmo e depois a segue em trabalho regulado, a organização tem um procedimento que ninguém revisou, aprovou ou versionou. Isso é um achado de controle esperando para acontecer, e é um problema de portabilidade ao mesmo tempo: o conhecimento de como o trabalho é feito vive apenas no runtime do fornecedor.

Isso estende duas posições que já defendemos. Argumentamos que memória de agente é armazenamento de dados enterprise, com deveres de retenção e acesso. E que custódia é a primeira pergunta na arquitetura de IA. Skills autoescritas adicionam um terceiro dever: elas não são apenas dados a manter; são procedimentos a governar.

O que possuir, e como testar a saída

Peça exportação em formato utilizável antes de assinar. Skills como texto legível com seu histórico, memória como registros com proveniência (quem ou o que escreveu cada item, e quando), logs de roteamento por tarefa. "Você pode exportar seus dados" não é a mesma resposta.

Espelhe as skills que importam. Trate skills escritas por agentes em processos importantes como código: copie-as para seu próprio repositório, revise-as, versione-as. É a mesma disciplina de mudança que recomendamos para agentes como autores de mudanças em produção, aplicada aos próprios procedimentos do agente.

Mantenha as definições do lado de fora. Definições de negócio lidas no local, como os novos catálogos do Google e Databricks propõem, permanecem portáveis porque nunca se moveram. Mantenha assim.

Seja dono da política de roteamento. Um roteador de fornecedor otimiza para desempenho e custo. Sua política pode precisar colocar a classificação de dados em primeiro lugar, como argumentamos em gerenciando modelos como um portfólio. O roteador pode executar a política; a política deve ser sua.

Faça um teste de saída uma vez por ano. Pegue as skills e memória exportadas de um agente, carregue-as em um runtime diferente ou um repositório comum, e veja o que sobrevive. A primeira vez será humilhante. É esse o ponto de fazer isso antes de precisar.

O modelo está se tornando a parte mais fácil da stack de substituir. Planeje para as partes que estão se tornando as mais difíceis.