Los agentes no necesitan memoria, necesitan documentación

Artículo original ↗ Discusión en Hacker News ↗

Los ingenieros de IA están replanteando cómo los agentes de software deberían “recordar” el trabajo pasado, sosteniendo que los almacenes de memoria opacos y las bases de datos vectoriales a menudo generan cruft desestructurado y obsoleto, mientras que la documentación explícita y versionada, los ADRs y el markdown local al repositorio pueden dar a los agentes una guía más clara y auditable. Muchos prefieren tratar a los agentes como desarrolladores junior: restringirlos con AGENTS.md, reglas de lint, pruebas y carpetas bien estructuradas, y luego hacer que los propios agentes ayuden a mantener la documentación sincronizada con el código. Otros replican que la documentación también se degrada, así que los sistemas prácticos probablemente necesitarán una mezcla de documentos curados, memoria ligera, gestión fuerte del contexto y retroalimentación determinista en lugar de una sola capa mágica de memoria.

Rol de la “memoria” frente a la documentación

  • Muchos coinciden en que los complementos ingenuos de memoria (fragmentos de solo anexado, almacenes opacos) se vuelven rápidamente obsoletos, ruidosos y difíciles de curar.
  • Varios sostienen que una documentación bien estructurada (AGENTS.md, ADRs, especificaciones, decisiones) es una mejor capa de “memoria”: consultable, auditable y actualizable.
  • Otros responden que la documentación también se degrada, puede estar fragmentada y rara vez refleja la realidad a menos que alguien (a menudo el agente) reciba la tarea explícita de mantenerla sincronizada.
  • Algunos ven la distinción como en gran parte semántica: la documentación no es más que un sistema de memoria estructurado y externalizado.

Prácticas concretas y estructuras de repositorio

  • Configuraciones populares:
    • AGENTS.md mínimo que apunta a documentos específicos.
    • Carpetas markdown basadas en características/incidencias; árboles decisions/, plans/, knowledge/, workbench/.
    • Archivos índice/catálogo que describen cada documento y cuándo leerlo (reglas “read_if”).
  • Se mencionan varias herramientas y patrones: “brains” en markdown dentro de repositorios, herramientas CLI para gestionar documentos, almacenes de documentos respaldados por S3 o git, mercados internos de habilidades y MCPs de memoria personalizados.

Comportamiento del agente, control y deriva

  • Queja reiterada: los agentes ignoran con el tiempo los sofisticados sistemas de memoria/ADR/principios y vuelven a grep + scripts rápidos de Python.
  • Fuerte deseo de reglas exigibles (por ejemplo, “usa jq, no Python improvisado”) mediante hooks, reglas de lint con mensajes prescriptivos y monitores de ejecución deterministas.
  • Algunos usan herramientas tipo entrevista o tokens de principio/versión en comentarios para orientar a los agentes y activar una reevaluación cuando cambian los principios.

Pruebas, verificación y retroalimentación

  • Experiencias mixtas con bucles TDD para agentes: las pruebas aseguran protección contra regresiones y comunican intención, pero pueden degenerar en marcar casillas.
  • Alternativa: habilidades “verify” personalizadas y retroalimentación basada en lint adaptada a code smells específicos del proyecto y principios arquitectónicos.
  • La retroalimentación determinista (similar a una puntuación estilo RL) se considera poderosa pero difícil de operacionalizar.

Gestión de contexto y evaluación

  • Fuerte enfoque en la gestión explícita del contexto: poda dinámica, sesiones por carpeta, monorepos con estructura clara.
  • Escepticismo sobre enormes pilas de documentación generada por IA; preocupa que se conviertan en “AI slop” ilegible y que no ayuden de forma medible.
  • Llamadas a evaluaciones A/B reales de configuraciones con mucha documentación frente a configuraciones mínimas; la evidencia actual en el hilo es anecdótica.

Seguridad y preocupaciones multiagente

  • Algunos ejecutan muchos agentes 24/7 con comunicación entre agentes y reportan buenos resultados; otros expresan temor ante el despliegue fácil a gran escala, la desalineación y el riesgo para sistemas financieros.
  • En general, los participantes coinciden en que los sistemas de agentes necesitan un estado transparente e inspeccionable más que “memorias” opacas a largo plazo.