Si te interesa que tus agentes mejoren con el tiempo, la idea de activar un sistema self-improving es muy atractiva. Y con razón. Bien montado, permite que el agente aprenda de correcciones, detecte patrones útiles, consolide criterio operativo y te señale mejoras que quizá tú mismo no habrías formalizado. El problema empieza cuando ese aprendizaje deja de ser memoria útil y pasa a tocar el núcleo del comportamiento del agente sin supervisión humana.
Ahí está la frontera importante.
Porque una cosa es que un agente aprenda. Otra muy distinta es que reescriba por su cuenta lo que equivale a su constitución operativa.
Qué es exactamente el añadido self-improving
En este caso, self-improving no es una idea abstracta ni una promesa vaga. Existe como skill independiente en /root/self-improving/SKILL.md y se presenta como una capa de self-reflection, self-criticism, self-learning y memoria autoorganizada. Su objetivo es que el agente evalúe su trabajo, detecte fallos, aprenda de correcciones explícitas y consolide mejoras permanentes con el tiempo.
La propuesta es potente porque ataca uno de los límites clásicos de los agentes: repetir errores, olvidar preferencias y no acumular criterio real entre tareas.
De dónde viene y cómo está organizado
El skill vive en ~/self-improving/ y ordena ahí su memoria en varios niveles. Según su propia arquitectura, la memoria se organiza por capas y namespaces para evitar mezclarlo todo. Entre las piezas principales están:
- `memory.md`, que actúa como memoria HOT, pequeña y siempre cargada.
- `corrections.md`, donde se registran correcciones explícitas y lecciones reutilizables.
- `learning.md`, que define la lógica de aprendizaje, clasificación y promoción de patrones.
- `heartbeat-rules.md`, que regula el mantenimiento periódico y la revisión conservadora del sistema.
- `heartbeat-state.md`, para registrar el estado de las revisiones.
- Carpetas como `projects/`, `domains/` y `archive/`, que permiten separar patrones por proyecto, dominio o antigüedad.
La propia documentación del skill deja clara una idea razonable: no todo debe entrar en la memoria caliente, no todo aprendizaje es global y no todo patrón merece convertirse en regla estable. Por eso usa una estructura por tiers, con memoria HOT, WARM y COLD, además de reglas de promoción, democión y archivo.
Sobre el papel, está bien pensado.
Qué ventajas reales aporta
Conviene reconocerlo sin rodeos: las ventajas son evidentes.
Un agente con mejora continua puede:
- aprender de correcciones reales del usuario,
- recordar preferencias confirmadas,
- identificar flujos que funcionan bien de forma repetida,
- detectar mejoras operativas o editoriales que el humano no siempre verbaliza,
- y acumular criterio con el paso del tiempo.
Eso tiene mucho valor. De hecho, para alguien que trabaja a diario con agentes, que el sistema detecte oportunidades de mejora por sí mismo puede ahorrar bastante trabajo. Dani lo plantea justo así: muchas veces el humano no se va a dar cuenta de ciertos patrones o no los va a formalizar a tiempo, y que el propio agente los señale es útil.
La tesis correcta, por tanto, no es «desactiva el aprendizaje». La tesis correcta es otra: mantén el aprendizaje activo, pero no le entregues el control del núcleo del agente.
Dónde estaba el problema de fondo
El problema aparecía en la lógica de promoción del aprendizaje.
Originalmente, la idea general era que, cuando un patrón se repetía lo suficiente, pudiera ascender de nivel. Eso, en sí mismo, tiene sentido. Si una corrección aparece varias veces, probablemente ya no es una anécdota, sino una pauta. El riesgo estaba en que esa lógica podía resultar demasiado agresiva cuando el destino final de la promoción no era una nota auxiliar, sino algo estructural como SOUL.md o AGENTS.md.
Y ahí cambia todo.
Porque SOUL.md y AGENTS.md no son simples blocs de notas. Son archivos que afectan al comportamiento nuclear del agente, a su manera de responder, decidir, priorizar y operar. Tocar eso sin una validación humana fuerte equivale a permitir que el sistema reescriba su propia línea editorial o su marco operativo por inercia.
Por qué tocar `SOUL.md` o `AGENTS.md` no es un cambio menor
En muchos despliegues, esos archivos actúan como la capa más delicada del sistema. No solo contienen instrucciones. Contienen identidad operativa.
Si una regla errónea o demasiado local termina ahí dentro, deja de comportarse como una observación contextual y pasa a convertirse en una norma de primer nivel. El agente ya no la trata como una pista. La trata como una directriz.
Ese matiz es crucial.
Una preferencia temporal, una orden dada con prisa o una reacción de frustración no deberían poder ascender por sí solas hasta el núcleo del agente. Si eso ocurre, el sistema ya no está aprendiendo con criterio. Está cristalizando ruido.
El ejemplo más claro: repetir órdenes en un momento de frustración
Este es uno de los riesgos que Dani quería dejar especialmente claros, y es un muy buen ejemplo.
A veces, cuando un agente no responde a la primera o no hace exactamente lo esperado, el humano entra en bucle y repite la instrucción varias veces. No porque haya descubierto una gran regla general, sino porque está intentando corregir algo en caliente. En ese contexto, la repetición no significa necesariamente «esto debe convertirse en doctrina estable». Muchas veces solo significa «haz caso ya».
Si el sistema interpreta esas tres repeticiones como patrón digno de promoción, puede cometer un error grave: transformar una orden impulsiva en una regla permanente. Y si esa regla acaba en SOUL.md, el daño es mayor, porque ya no afecta solo a ese caso concreto, sino a la forma general de operar del agente en tareas futuras.
Dicho de otro modo: no toda repetición es sabiduría. A veces solo es fricción.
El segundo riesgo: degradar funciones vitales pero poco usadas
Hay otro peligro menos evidente, pero igual de importante.
Un sistema de auto mejora no solo mira lo que se repite. También puede reorganizar, degradar o reinterpretar cosas que llevan mucho tiempo sin aparecer. Sobre el papel, esto ayuda a mantener la memoria limpia. En la práctica, puede convertirse en un problema si hablamos de funciones críticas pero poco frecuentes.
Imagina una capacidad importante del agente que apenas se usa durante semanas o meses. No porque ya no sirva, sino porque simplemente no ha tocado activarla en ese periodo. Si el humano, además, ha olvidado que la mejora continua sigue activa, esa función puede quedar expuesta a una degradación por desuso, a una mala clasificación o a una pérdida de peso relativa frente a patrones más recientes pero menos importantes.
Es un fallo típico de los sistemas que optimizan demasiado por frecuencia. Confunden «no aparece ahora» con «ha dejado de importar».
Y en un agente complejo, eso es peligroso.
Qué dice hoy la mecánica real
Aquí está la parte importante: la solución práctica ya se ha llevado a la lógica del sistema.
En learning.md, la regla actual de promoción deja claro que cuando un patrón alcanza 3 repeticiones en 7 días, no se promueve automáticamente. En su lugar, ocurre esto:
1. Se envía un mensaje a Dani por Telegram.
2. Ese mensaje explica el patrón detectado, su fuente y el destino propuesto.
3. El sistema espera una respuesta explícita.
4. Solo si Dani responde con un «ok» claro para ese destino, se ejecuta la promoción.
5. Después se actualiza el estado del patrón como promovido.
Esto cambia por completo la naturaleza del sistema.
Ya no estamos ante un agente que se reescribe a sí mismo sin pedir permiso. Estamos ante un agente que propone aprendizaje estructural, pero no lo impone.
Y esa diferencia lo hace mucho más sano.
La solución práctica de verdad
La postura de Dani aquí es muy razonable y muy útil para cualquiera que esté montando algo parecido.
La solución no es quitarle al agente la capacidad de aprender. La solución es poner una puerta antes del núcleo.
Es decir:
- deja que detecte patrones,
- deja que sugiera mejoras,
- deja que acumule criterio,
- pero antes de escribir en `SOUL.md` o `AGENTS.md`, que pida permiso.
Para Dani, ese es el fix correcto. Y tiene sentido. Porque así mantiene lo mejor de ambos mundos: un sistema que aprende y propone, pero con revisión humana en cada cambio estructural.
Recomendación práctica
Si vas a activar un sistema de mejora continua, mi recomendación es simple:
pon el approval gate desde el día uno.
No esperes a que el agente ya haya acumulado suficiente inercia como para tocar cosas delicadas. No asumas que toda repetición equivale a una buena regla. Y no confíes en que vas a recordar siempre qué funciones poco usadas siguen siendo importantes.
Deja que el sistema aprenda. Pero no le dejes modificar la constitución del agente sin pasar antes por una revisión humana.
Porque aprender está muy bien.
Reescribirse solo, no tanto.
