Plugin de arquitectura de generación de agentes que resuelve el ruido y el decay de la memoria de agentes (código abierto)

La mayoría de las configuraciones de agentes manejan mal la memoria. O escriben todo directamente en la memoria de largo plazo y la llenan de ruido y contradicciones, o lo olvidan todo cuando se corta la sesión y hay que volver a empezar desde cero cada vez. Publico una arquitectura de agentes de código abierto diseñada con especial cuidado en la memoria (Apache-2.0). La misma configuración corre tal cual en Claude Code, Codex y Gemini CLI, así que no queda atada a una herramienta específica.
La idea central es que el agente debe ser un repo, no un prompt. El resultado son archivos reales (AGENTS.md, agents/, skills/, .agentlas/), así que los tres runtimes pueden leerlos, y puedes seguir usando el modelo que ya usabas. Se instala con una sola línea y, si le dices lo que quieres, te crea un equipo completo de agentes instalables.
3 modos que puede crear

Agente individual: un worker con habilidades, reglas de memoria, adaptador de runtime y etapa de validación. También se le pueden agregar bucles de self-evolution y research-refresh sin necesidad de escalarlo a un equipo.
Equipo multiagente: orchestrator/HQ, PM Soul, Memory Curator, Policy Gate, workers, eval judge, QA/puerta de evidencia y los handoffs entre ellos. Es el modo de “créame una empresa para este flujo de trabajo”.
Reempaquetado: organiza agentes o workspaces que ya tienes (Claude/Codex/local) como un portable package. También les agrega plugin público e instalación con una sola línea, y elimina rutas locales, secretos y logs privados para que sea seguro publicarlo.

Cómo funciona realmente la memoria (no es una lista de roles, sino archivos que van dentro del resultado)

Memoria basada en tickets: no escribe directamente en la memoria de largo plazo. Cuando un worker emite un bloque ## Memory Events, se acumula en memory-tickets.jsonl como tickets (id, scope, trust label, evidence, status) y solo después se promueve.
Memory Curator: revisa los tickets antes del commit y deja la decisión en el libro contable curator-decisions. Así evita que la memoria se llene de ruido o contradicciones.
PM Soul: se encarga de la continuidad a nivel de proyecto. Conserva intención, decisiones y tareas pendientes, así que recuerda no solo “qué decisión se tomó”, sino “por qué se tomó”.
Policy Gate: la memoria compartida del equipo debe pasar una etapa de aprobación antes de promoverse. Esto evita que un solo agente contamine todo el contexto.
Self-evolution validada: el agente puede crear nuevas habilidades y proponer cambios por sí mismo, pero las habilidades nuevas salen solo como candidatas y solo se recuerdan como first-class después de pasar por el libro de evidencia de trial, la revisión de Curator y la aprobación de políticas. La idea es que mejore por sí solo sin degradarse en silencio. Las autoediciones también son proposal-first, no sobreescrituras no autorizadas.
Escaneo de seguridad para publicación: antes de publicar el paquete, bloquea rutas de máquina, tokens, JSON de service-account y formatos comunes de secretos.