Revisado por Iván Quintas, Editor de IA News
Tus sesiones de agente no son tuyas: el problema de la portabilidad
Earendil documenta cómo OpenAI, Google y Anthropic sellan el estado de tus sesiones de agente, y propone siete reglas para recuperarlo.
Earendil Engineering publicó el 30 de julio un artículo que plantea una pregunta incómoda para cualquiera que trabaje con agentes de código: cuando abres el log de tu sesión, ¿estás viendo la sesión o solo la parte que el proveedor te deja ver? La respuesta que documentan es la segunda, y el vídeo con el que Maximilian Schwarzmüller lo amplificó el 5 de agosto —6.000 visualizaciones en su primer día— se titula sin rodeos: no eres dueño de tus sesiones de agente.
Qué es la portabilidad de sesión
La definición de Earendil es operativa, no filosófica: una sesión es portable si el archivo que exportas contiene información inteligible suficiente para que otro modelo continúe el trabajo. Y añaden el criterio negativo, que es el que corta de verdad: no debería hacer falta que el proveedor antiguo resuelva un ID, desencripte un blob, recuerde un resultado de búsqueda o reconstruya un resumen.
Lo que un transcript debería contener, según el post, son cuatro cosas: instrucciones, mensajes, llamadas a herramientas y resultados de esas llamadas.
Cómo funciona una sesión de agente
Conviene tener el mecanismo claro antes de ver qué se rompe. En un agente de código el reparto es este:
- El harness corre en tu máquina: ejecuta las herramientas, lee y escribe ficheros, mantiene el log de la sesión.
- El modelo corre en el servidor del proveedor y solo produce texto. Puede describir que quiere leer un fichero, no leerlo.
- Entre ambos viaja el contexto: tu prompt, las instrucciones, las descripciones de herramientas y todos los resultados acumulados, reenviados en cada turno.
Esa acumulación es la sesión. Y es exactamente la pieza que ha dejado de ser transparente.
El problema: estado sellado por el proveedor
Earendil lo llama provider-sealed state: partes del estado que existen, viajan y afectan al resultado, pero que tú no puedes leer ni trasladar.
| Proveedor | Qué sella |
|---|---|
| OpenAI | La Responses API almacena por defecto; el razonamiento vuelve como blob encriptado |
| Google (Gemini) | La Interactions API viene con store: true por defecto y retención de 55 días |
| Anthropic | Los bloques de thinking están atados a un modelo concreto y se marcan para eliminación al cambiar |
La frase del artículo que resume el cambio: el transcript de tu máquina ya no es tu sesión, sino una vista parcial de una sesión cuyo estado operativo pertenece a un proveedor de inferencia.
Hay matices a favor de la industria y el post los reconoce: Anthropic ofrece compactación legible, con resúmenes inspeccionables, frente al razonamiento encriptado. La tendencia general, aun así, va en dirección contraria.
Qué pierdes exactamente al cambiar de modelo
- Razonamiento oculto y cadena de pensamiento
- Los pasajes exactos de búsqueda y su ranking: te quedan las citas, no el texto
- Contexto comprimido que vive en el servidor
- Descripciones de tareas de subagentes y mensajes entre ellos
- Referencias a ficheros y vector stores atadas a la base de datos del proveedor
El detalle técnico que lo vuelve irreversible: puedes reenviar el blob encriptado al modelo nuevo, pero, en palabras del post, another model cannot use its meaning. Llevas el sobre, no la carta.
Las siete reglas para una API de inferencia portable
| # | Regla | Qué implica |
|---|---|---|
| 1 | El log local es canónico | La fuente de verdad vive en tu máquina, no en el servidor |
| 2 | El almacenamiento es explícito | Guardar en servidor se activa, no viene por defecto |
| 3 | Ningún elemento opaco es el único portador de significado | Si hay blob encriptado, hay resumen legible al lado |
| 4 | Las herramientas alojadas tienen logs de fidelidad completa | El resultado de búsqueda, no solo la cita |
| 5 | La comunicación entre subagentes es auditable | Los mensajes internos se pueden leer |
| 6 | La compactación es inspeccionable | Sabes qué se resumió y cómo |
| 7 | Los artefactos son exportables | Los ficheros generados se descargan |
Leídas juntas son una definición de qué haría falta para que el proveedor de inferencia fuese una pieza intercambiable y no un dueño.
El agente open source no te salva
El punto que más cuesta interiorizar es que esto no se arregla eligiendo un harness libre. Pi, el agente sobre el que Schwarzmüller construye su explicación, es minimalista y extensible, corre en tu máquina y guarda cada sesión como un JSONL que puedes abrir. Da igual: si detrás hay una API que sella el razonamiento, tu JSONL tiene huecos.
El problema está en el contrato de la API, no en el cliente. Y eso explica dos movimientos que hasta ahora se leían por separado:
- Herramientas de control y observabilidad. Watchfire, presentado en Show HN el 4 de agosto (Apache-2.0, Go con GUI en Electron, 57 estrellas), se define como sala de control para agentes de código: ejecuta cada agente en su propia rama de git worktree y da monitorización en vivo por TUI o GUI. Genesys va por memoria de grafo causal para agentes. Ambos asumen que el estado hay que gestionarlo fuera del proveedor.
- Modelos abiertos que corren en local. Cuando la inferencia es tuya, la portabilidad deja de ser un favor del proveedor. Es el mismo argumento que ya aparecía al medir cuánto le cuesta a cada modelo abierto resolver una tarea agéntica.
Por qué importa ahora
Porque la sesión ha dejado de ser un chat y se ha convertido en una unidad de trabajo con horas invertidas. Si diseñas loops de agentes por objetivo o por tiempo, o montas pipelines con las convenciones de un SDK concreto, estás acumulando estado durante mucho rato. Que ese estado sea parcialmente ilegible convierte cualquier migración de modelo en empezar de cero, y convierte una auditoría en un ejercicio de fe.
Conclusiones
El artículo de Earendil no denuncia una práctica maliciosa: encriptar el razonamiento tiene motivos legítimos, desde proteger la propiedad intelectual del modelo hasta evitar destilación. Lo que documenta es la consecuencia acumulada, que sí es grave: el lock-in ha bajado de capa. Ya no está en el agente que eliges, está en el registro de lo que ese agente hizo.
Las siete reglas son la parte accionable, y son razonables una a una. La pregunta abierta es si algún proveedor grande adoptará la número 3 —resumen legible junto a cada blob opaco— sin que la competencia le obligue. Mientras tanto, la defensa práctica es la de siempre: guarda tus logs, prueba a migrar una sesión antes de necesitarlo y asume que lo que no puedes leer, no lo tienes.
📎 Fuente original: Earendil Engineering ↗
Noticias relacionadas
Preguntas frecuentes
- ¿Qué es la portabilidad de sesión?
- La capacidad de exportar una conversación con un agente y continuarla con otro proveedor. Según Earendil, el archivo exportado debe contener información inteligible suficiente para que otro modelo siga el trabajo, sin necesitar que el proveedor original desencripte nada ni resuelva identificadores en sus servidores.
- ¿Por qué no basta con tener el fichero JSONL de la sesión en mi máquina?
- Porque partes del estado ya no viajan en texto plano. Los bloques de razonamiento vuelven encriptados, los resultados de búsqueda quedan como citas sin el pasaje original y la compactación de contexto puede vivir en el servidor. El log local pasa a ser una vista parcial de una sesión cuyo estado operativo pertenece al proveedor.
- ¿Qué pasa si cambio de modelo a mitad de sesión?
- Pierdes lo que el proveedor anterior no te dejó leer: razonamiento oculto, pasajes exactos de búsqueda, contexto comprimido en servidor, mensajes entre subagentes y referencias a ficheros o vector stores ligadas a su base de datos. El nuevo modelo puede recibir el blob encriptado, pero no puede usar su significado.
- ¿Afecta esto solo a agentes propietarios?
- No. El agente puede ser open source y correr en tu máquina, como Pi u OpenCode, y aun así depender de una API de inferencia que sella parte del estado. El problema no está en el harness sino en el contrato de la API que hay detrás.