Una transcripción no es una representación de estado

Imagina un agente trabajando durante una hora. Empieza con una hipótesis sobre un bug. Lee cinco archivos. Modifica dos. Los tests fallan. Descubre que su hipótesis original estaba equivocada. Revierte un cambio. Añade otra implementación. Un test pasa. Luego falla un test de integración que no se había visto antes.

Todo esto vive en la transcripción de la conversación. Si simplemente seguimos extendiendo la ventana de contexto, el modelo recibe cada paso:

  • suposiciones que ya no son ciertas;
  • fallos que ya se han arreglado;
  • archivos que resultaron ser irrelevantes;
  • decisiones de implementación temporales;
  • planes desactualizados;
  • hechos actuales.

Ahora el modelo tiene otro problema que resolver antes de poder seguir programando:

Reconstruir el estado actual de la tarea a partir de un historial cronológico ruidoso.

Los humanos reconocen este problema de inmediato. Por eso mantenemos issue trackers, el estado de Git, paneles de tests y checklists en lugar de reconstruir el proyecto releyendo Slack desde el principio.

Un contexto más grande no resuelve automáticamente el trabajo de largo horizonte

Las ventanas de contexto grandes son extremadamente útiles. Pero la capacidad de contexto y la gestión de estado son capacidades distintas.

Los sistemas de memoria para agentes más recientes empiezan a hacer explícita esa distinción: tratan la memoria como gestión del estado de ejecución y no como recuperación semántica sobre interacciones pasadas.

La idea común es importante:

La memoria no consiste solo en recuperar algo que parece semánticamente relevante.

A veces el agente necesita saber qué sigue siendo válido.

Considera un experimento fallido

Supón que un agente intentó antes:

Mover la validación al middleware.

Más tarde descubrió que los trabajos en segundo plano no pasan por ese middleware. Un sistema de memoria semántica podría recuperar la vieja discusión sobre el middleware la próxima vez que la validación se vuelva relevante. Léxica y semánticamente, es una coincidencia perfecta. Operativamente, es peligroso.

La información importante no es simplemente que la idea existió. Es:

Mover la validación al middleware — RECHAZADO porque los trabajos en segundo plano no pasan por el middleware.

El estado necesita procedencia. Necesita validez. A menudo necesita orden. Por eso tratar todas las interacciones previas como un índice de embeddings puede ser fundamentalmente erróneo para la ejecución.

Hay al menos tres tipos de memoria en un agente de código

A menudo los reducimos a una sola palabra, pero resuelven problemas distintos.

1. Conocimiento del repositorio. ¿Qué es verdad sobre el software? ¿Dónde están los componentes? ¿Qué dependencias existen? ¿Qué convenciones arquitectónicas están en vigor? ¿Qué capacidades ya existen? Este estado evoluciona con el repositorio.

2. Estado de la tarea. ¿Qué es verdad sobre el trabajo actual? ¿Qué hipótesis se han descartado? ¿Qué archivos se modificaron? ¿Qué tests fallan actualmente? ¿Qué decisiones siguen sin resolver? ¿Qué falta por verificar? Esto cambia continuamente durante la ejecución.

3. Experiencia. ¿Qué nos enseñaron tareas anteriores? Quizá cada intento de modificar un subsistema de autenticación exige actualizar un esquema generado. Quizá una suite de tests es inusualmente lenta. Quizá un paquete concreto contiene un mecanismo de extensión inesperado. Este conocimiento puede ayudar a tareas futuras, pero no es necesariamente un hecho sobre la ejecución actual.

Mezclar los tres en una única base de datos vectorial es conveniente. No es obviamente correcto.

El estado puede ser parcialmente determinista

Aquí es donde los agentes de código tienen ventaja frente a asistentes más abiertos. Buena parte de su entorno es inspeccionable.

Git sabe qué archivos cambiaron. El sistema de archivos sabe qué existe ahora mismo. El test runner sabe qué falló. El gestor de procesos sabe qué se está ejecutando. El índice del repositorio sabe qué relaciones estructurales se extrajeron. El runtime puede saber qué llamadas a herramientas tuvieron éxito.

El agente no necesita recordar estos hechos de forma conversacional. El sistema que lo rodea puede mantenerlos.

Esto sugiere un límite arquitectónico útil:

Los modelos deberían razonar sobre el estado. La infraestructura debería poseer el estado siempre que sea posible.

Eso hace que una tarea larga dependa menos de que el modelo comprima con precisión su propio pasado.

Los planes deberían ser objetos, no prosa

Hay un problema similar con la planificación. Los agentes suelen generar algo como:

1. inspeccionar el servicio de autenticación
2. identificar llamadores
3. modificar la validación
4. añadir tests
5. ejecutar la suite de integración

Luego el plan desaparece en el historial de chat. Una representación más útil rastrearía cada obligación explícitamente:

[hecho] inspeccionar el servicio de autenticación
[hecho] identificar llamadores
[hecho] modificar la validación
[en curso] añadir tests
[pendiente] ejecutar la suite de integración
[nuevo] comprobar la ruta del worker en segundo plano

Ahora el plan puede evolucionar. El sistema puede preguntar si una acción está justificada por evidencia ya completada.

Retrasar las ediciones hasta haber recogido evidencia específica de la tarea mejora la tasa de éxito sin tocar el modelo. Eso es lo interesante: la mejora no viene de hacer el modelo más listo, sino de poner estructura de ejecución a su alrededor.

La memoria también puede conservar errores

Esta es la parte de la memoria persistente que más me preocupa. Si un agente aprende de sesiones anteriores, ¿qué pasa cuando la conclusión anterior era errónea?

Las organizaciones humanas ya sufren de folclore institucional: «no toques ese servicio porque rompe producción». Quizá eso era cierto hace cuatro años. Quizá nunca lo fue.

La memoria de un agente puede industrializar el mismo problema. El conocimiento persistente, por tanto, necesita: información de origen, marca temporal o alcance de versión, confianza, invalidación y enlaces de vuelta a la evidencia.

De lo contrario construimos un sistema que se vuelve cada vez más confiado a medida que acumula folclore cada vez más obsoleto.

Un repositorio ya contiene memoria en sí mismo

Hay una ironía útil aquí. Los repositorios de software siempre han contenido mecanismos para el conocimiento duradero: los tests codifican expectativas de comportamiento, los sistemas de tipos codifican restricciones estructurales, los esquemas codifican suposiciones sobre datos, los linters codifican reglas de estilo y seguridad, los tests de arquitectura codifican reglas de dependencias, la documentación codifica intención, y Git registra decisiones históricas.

El sistema de memoria de un agente de código probablemente debería integrar todo esto en lugar de inventar un universo completamente separado de hechos recordados.

La memoria más fuerte a menudo no es una frase que dice «no llames a este módulo desde la capa de API». Es un test de arquitectura que hace imposible fusionar esa llamada.

El agente del futuro puede recordar menos texto

Esto lleva a una predicción contraintuitiva. Los mejores agentes de código de largo horizonte puede que no necesiten cargar historiales conversacionales enormes. Puede que carguen menos prosa y más estado actual estructurado.

La transcripción sigue siendo útil como registro de auditoría. Pero el contexto activo se vuelve algo más parecido a: objetivo actual, requisitos validados, evidencia relevante del repositorio, decisiones que siguen en vigor, archivos cambiados, resultados de tests, fallos sin resolver, próximas obligaciones.

La diferencia parece pequeña. En trabajo autónomo de larga duración, es fundamental. Una conversación le cuenta a un agente la historia de lo que pasó. Un modelo de estado le dice en qué mundo está operando ahora. Para los agentes de código, lo segundo puede acabar importando más.