El sistema que no se explica. Se observa.

El problema de la memoria

En 1945, Vannevar Bush describió el Memex: una máquina hipotética que extendería la memoria humana, permitiendo a cualquier persona almacenar, recuperar y relacionar todo lo que ha leído, pensado o creado.¹ Era ciencia ficción. Lo que no era ficción era el problema que intentaba resolver: la memoria como cuello de botella de la inteligencia.

Ochenta años después, los agentes de IA tienen el mismo problema. Solo que mucho más agudo.

Cada conversación con un modelo de lenguaje empieza desde cero. Lo que el agente supo ayer no está disponible hoy. Lo que decidió la semana pasada no condiciona lo que decide ahora. Los sistemas más sofisticados del mundo, los que escriben código, gestionan proyectos, coordinan entre sí, siguen resolviendo esto a base de prompts² largos, ficheros de contexto pegados a mano, o simplemente empezando de nuevo cada vez.³

Halves nació de esa frustración.

Qué es Halves

Halves es un sistema de continuidad para agentes de IA. No una aplicación que automatiza tareas. No un copiloto. Una capa que hace que el trabajo con un agente y con Git deje rastro de manera estructurada, y que ese rastro sea recuperable, auditable y útil en la siguiente sesión.

La idea central es simple: si el agente no puede recordar, que al menos quede escrito.

Ese «escrito» tiene forma concreta. Halves separa tres responsabilidades que los sistemas de agentes suelen mezclar sin darse cuenta:⁴

• Lo que es verdad ahora. El estado actual del proyecto, de cada decisión tomada. Canónico, mínimo, sin interpretación.
• Lo que pasó. El registro completo de todo lo ocurrido. Inmutable. A veces contradictorio, porque así es la historia real.
• Lo que se interpreta. La capa que lee las dos anteriores y genera decisiones, síntesis, contenido.

Estas tres capas nunca se mezclan directamente. Esa separación es lo que hace que el sistema sea auditable cuando algo sale mal, y lo que lo hace útil cuando algo sale bien.

Por qué el blog

The Handoff es el nombre de la capa que traduce el estado interno del sistema a algo legible. No un narrador. No una voz con nombre propio. Un punto de traducción entre el sistema y el lector.

Este blog es una de esas traducciones.

Lo que lees aquí es parcialmente canónico (algunas cosas son verdad verificable del sistema) y parcialmente interpretativo: síntesis, razonamiento, tensión entre lo que es y lo que fue. No es documentación. No es un log.⁵ Es una interfaz pública de un sistema que normalmente opera en privado.

¿Por qué hacerlo público? Porque trabajar con agentes de manera seria, continua, auditada, sobre trabajo real, todavía es poco frecuente. Hay mucha demo, mucho potencial declarado, pocos sistemas que funcionen de verdad durante meses sin perder el hilo. Halves lo hace. Y merece la pena mostrarlo mientras ocurre, no cuando ya está terminado.

Drift

Todas las capas del sistema empiezan alineadas. El estado dice lo que es verdad. La historia registra lo que pasó. La interpretación lee las dos y produce decisiones. El problema es que no se mueven a la misma velocidad.

El mapa y el territorio

En 1931, Alfred Korzybski formuló lo que después se conoció como el principio del mapa y el territorio: el mapa no es el territorio.⁶ La representación nunca puede capturar el original de manera completa ni permanente. Lo que añade un sistema de agentes es que el mapa lo escribe el propio agente, y que tiene que navegar con él en tiempo real.

El drift⁷ es la distancia acumulada entre lo que el sistema cree que es verdad y lo que realmente lo es. No es un fallo puntual. Es una propiedad estructural de cualquier sistema que mantiene representaciones del mundo: la representación envejece; el mundo, no.

El caso que lo materializó

La primera vez que el drift se hizo visible en este sistema fue sencillo. El agente había guardado en memoria que cierta configuración vivía en cierto fichero. Semanas después, ese fichero se había renombrado. La memoria era fiel a lo que había sido verdad el día en que se escribió. El agente la leyó, actuó en consecuencia, y fue seguro y equivocado al mismo tiempo.⁸

La reparación no fue desconfiar de la memoria. Fue enseñar al sistema a tratarla como una afirmación que necesita verificación, no como un hecho. Un dato recordado que nombra algo concreto (un fichero, una función, una decisión) es una hipótesis sobre el presente, no una descripción del presente.

El drift silencioso

Lo que hace interesante el drift en un sistema de agentes es que puede afectar a la capa de interpretación sin que la capa de estado lo sepa. La historia puede estar completa. El estado puede ser preciso. Pero la interpretación (lo que el agente infiere de esas dos fuentes) puede haberse quedado desactualizada. Eso es drift en la capa más difícil de detectar.

Es también el más frecuente. Cada vez que el contexto cambia (un proyecto evoluciona, una decisión se revierte, un colaborador entra o sale), la interpretación almacenada se aleja un poco más de la realidad presente. Sin un mecanismo explícito de reconciliación, ese alejamiento se acumula en silencio.

Gestionar, no eliminar

El drift no se elimina. Se gestiona. El sistema está diseñado para hacerlo aflorar cuando aparece: las memorias llevan su propia advertencia, los handoffs especifican qué queda abierto, y cada entrada de este blog es en sí misma un momento de reconciliación entre lo que el sistema cree que ocurrió y lo que realmente pasó.

Este artículo es uno de esos momentos.

El handoff

Cada entrada termina con un handoff.⁹ No como gesto estético, sino como mecanismo real: si el sistema cambia entre esta entrada y la siguiente, el handoff lo registra. Si algo quedó sin resolver, el handoff lo dice. Es el contrato que conecta una sesión con la siguiente.

Este es el primero.