Ya se puede cambiar el modelo bajo un agente. Lo difícil de mover es su memoria y las habilidades que escribió

Cuanto más intercambiables se vuelven los modelos, más lock-in puede acabar acumulando una empresa.

Suena al revés, así que empiece por el hecho. El 8 de octubre, Google describió su agente Gemini como una capa de orquestación que funciona “en toda nuestra familia de modelos Gemini y los modelos Claude de Anthropic hoy, y otros modelos privados y abiertos líderes en el futuro”, con una herramienta de enrutamiento que manda cada carga de trabajo al “modelo que ofrece el máximo rendimiento al menor costo posible”. Cambiar de modelo, en ese diseño, es un ajuste.

Ahora el segundo hecho, del mismo keynote. El agente “mantiene un único conjunto de memorias, contexto y un solo grafo de personalización” en todos los dispositivos y canales, y guarda cuatro tipos de memoria: de sesión, semántica, episódica y procedimental, esta última “incluidas las habilidades que escribe para sí mismo”. Los agentes coworker tienen almacenamiento persistente propio.

Junte las dos cosas y el costo de cambio no ha desaparecido. Se ha movido.

Lo que se acumula ahora

Al año de operar agentes como estos, lo valioso dentro del runtime no será el modelo. Será lo que los agentes han aprendido y registrado sobre la organización:

• Memoria: qué pasó, qué prefiere la gente, qué proveedor llega siempre tarde, qué aprobador quiere el resumen primero.
• Habilidades propias: procedimientos que el agente compuso para hacer trabajo recurrente. En la práctica, se convierten en la descripción operativa de cómo funciona un proceso, a menudo más al día que la oficial.
• Personalización e historial de enrutamiento: qué modelo atendió qué tarea, qué tan bien, a qué costo.

Nuestra postura, y es una postura y no un hecho: esta es una forma de lock-in más pegajosa que la del dato. El dato tiene formatos y herramientas de exportación. El estado acumulado del agente lo genera en parte el propio sistema del proveedor, se guarda en el formato del proveedor y su valor depende del runtime que lo interpreta. Una habilidad escrita para un runtime puede no significar nada para otro.

Qué es fácil de mover y qué no

Fácil de cambiarDifícil de mover

1. El modeloRouters y runtimes multimodelo
2. Prompts y herramientasTexto y protocolos estándar como MCP
3. Definiciones de negocioPortables si las posee donde viven
4. MemoriaFormato del proveedor, procedencia mixta
5. Habilidades propiasCodifican cómo se hace su trabajo

Por qué esto importa más en trabajo regulado

En un banco o una farmacéutica, un procedimiento que se sigue es un procedimiento, lo haya escrito quien lo haya escrito. Si un agente escribe una habilidad para sí mismo y luego la sigue en trabajo regulado, la organización tiene un procedimiento que nadie revisó, aprobó ni versionó. Es un hallazgo de control esperando a ocurrir, y a la vez es un problema de portabilidad: el conocimiento de cómo se hace el trabajo vive solo en el runtime del proveedor.

Esto extiende dos posturas que ya sostenemos. Sostuvimos que la memoria del agente es almacenamiento de datos empresarial, con deberes de retención y acceso. Y que la custodia es la primera pregunta en la arquitectura de IA. Las habilidades propias añaden un tercer deber: no son solo datos que conservar; son procedimientos que gobernar.

Qué poseer y cómo probar la salida

Pida la exportación en una forma usable antes de firmar. Las habilidades como texto legible con su historial, la memoria como registros con procedencia (quién o qué escribió cada elemento, y cuándo), los logs de enrutamiento por tarea. “Puede exportar sus datos” no es la misma respuesta.

Replique las habilidades que importan. Trate las habilidades escritas por el agente en procesos importantes como código: cópielas en su propio repositorio, revíselas, versiónelas. Es la misma disciplina de cambio que recomendamos para los agentes como autores de cambios en producción, aplicada a los procedimientos del propio agente.

Mantenga las definiciones fuera. Las definiciones de negocio leídas en su sitio, como proponen los nuevos catálogos de Google y Databricks, siguen siendo portables porque nunca se movieron. Manténgalo así.

Sea dueño de la política de enrutamiento. Un router del proveedor optimiza por rendimiento y costo. Su política puede necesitar poner primero la clasificación de datos, como argumentamos en gestionar los modelos como un portafolio. El router puede ejecutar la política; la política debería ser suya.

Haga una prueba de salida una vez al año. Tome las habilidades y la memoria exportadas de un agente, cárguelas en otro runtime o en un repositorio simple y vea qué sobrevive. La primera vez será humillante. Ese es el punto de hacerlo antes de necesitarlo.

El modelo se está volviendo la parte más fácil de reemplazar del stack. Planifique para las partes que se están volviendo las más difíciles.