La memoria de los agentes necesita su momento OpenTelemetry

Agent memory needs its OpenTelemetry moment

Cada herramienta de código guarda lo que «recuerda» en un formato distinto —AGENTS.md, CLAUDE.md, reglas de Cursor, la herramienta de memoria de Anthropic, Copilot, servidores MCP— y ninguna puede leer las demás. El autor, que construye LoreKit, sostiene que el problema no es una herramienta que falte sino un acuerdo que no existe, y traza el paralelo con OpenTelemetry: un modelo de datos, convenciones semánticas, un protocolo y pruebas de conformidad compartidos, dejando la competencia para lo que viene después.

El problema no es una herramienta que falte. Es un acuerdo que falta, y eso solo surge cuando la comunidad trabaja en ello en conjunto.
  1. armchairhacker

    ¿Es esto un problema importante? Parece que hay 15 soluciones para cada problema de "formato de texto" de la IA, pero todas son meramente estructura sobre alimentar a la IA con inglés informal, una estructura que creo que el modelo "transformer" es específicamente capaz de reducir a una forma común (que es cómo funcionó entrenarlo con todo internet).

    La IA sí se beneficia de aprender a usar habilidades, y de recibir instrucciones con buenas estructuras (como "guarda [tipo específico e importante de detalle] en memorias" y "planifica antes de implementar cualquier cosa"). Pero ninguna de estas soluciones de memoria parece mejor que otra, básicamente son solo carpetas distintas. Tu CLAUDE.md puede decir "ver AGENTS.md" y AGENTS.md puede decir "escribe las memorias en .agent/memories/", y me interesaría una medición, pero supongo que rinde casi exactamente igual que el CLAUDE.md nativo y .claude/memories.

    Una cosa que he notado que la IA hace mucho mejor que yo es no tener TOC con la solución "perfecta".

  2. speedping

    Todo el artículo del blog apesta a LLM.

    Si hubiera una forma suficientemente fiable de detectar texto de LLM, construiría una extensión de navegador que directamente lo filtrara del todo.

  3. Dirak

    No, no es así. Todavía hay mucha innovación y cambio en el espacio de los LLM, y ninguna solución sirve para todo. Por lo que sé, las soluciones tienen que sopesar tres preocupaciones principales: velocidad, precisión y coste. Ni siquiera creo que la memoria como archivos esté ya consolidada. Hay muchísima innovación y progreso por hacer en este espacio.

  4. Fordec

    Sobre la premisa general, estoy de acuerdo. Pero no creo que ese momento sea hoy, al menos todavía no. No creo que entendamos aún la forma correcta de abordar el contexto y la memoria, ni cuánto deberían durar, y mucho menos estandarizar prematuramente sobre una abstracción que acabe siendo como SOAP o SGML.

  5. baalimago

    ¿De verdad necesitamos esto...? Lo que los LLM hacen bien es interpretar lenguaje natural. Así que son una esponja para cualquier formato que se use en un proyecto concreto: un formato predefinido no hace realmente falta.

    Además, ¿de verdad queremos que la memoria de los agentes del usuario A coexista con la del usuario B? La verdad es que no. Así que el argumento a favor de la colaboración y el uso compartido es bastante débil, al menos para los agentes de programación. El contexto específico del repositorio se puede codificar en un directorio docs/ o architecture/, igual que se ha hecho también antes de la era de los agentes.

    Para monitorizar agentes desplegados: quizá. Para esto construí (otra más) herramienta de gestión de memoria, slivingdoc.dev, con la que es posible descargar el contexto duradero de todos los agentes. Pero aquí el problema es uno de sistemas distribuidos, no el formato de las memorias.

  6. imgyuri

    La necesidad de un formato o especificación unificados se reduce enormemente en el caso de la memoria de agentes porque, por definición, la leen agentes, y los agentes ya están instruidos o programados para leer archivos de memoria de distintos formatos. Incluso si tales instrucciones no existieran, los agentes son extremadamente buenos recorriendo archivos para obtener el contexto que necesitan.

  7. palijer

    Es demasiado pronto para abogar por la estandarización de este problema. Otel se desarrolló tras décadas de experiencia en el campo y exploramos innumerables soluciones y nos basamos en ellas al desarrollar Otel.

    Decir que ya hemos explorado lo suficiente en soluciones de memoria de agentes como para estandarizarlo y añadir fricción a cualquier experimentación futura sería un error, creo.

  8. mmasu

    Tengo curiosidad por saber qué hace la gente hoy en día y cómo aborda este problema. A nivel de repositorio puedes arreglártelas con AGENTS.md y quizá un conjunto curado de documentos adicionales con la historia del proyecto, pero en cuanto sales de ahí y quieres tener contexto adicional, las soluciones disponibles son demasiadas: Hindsight, Graphiti y muchas otras; o simplemente montas la tuya. Me gustaría algo que pueda levantar con Postgres o con un bucket de S3 y que me escriba archivos .md conservando algún tipo de relación entre las distintas entidades; sin embargo, parece que todavía no hay ninguna solución "simple" por ahí, y muchas de las implementaciones existentes son demasiado elaboradas o requieren soluciones de BD exóticas. Sería muy interesante saber si alguien conoce una solución básica que pueda enchufar a cualquier agente.

Más de este día

2026-11-08