Modo de Falla 'Mono Blanco': Cómo los Agentes Persistentes se Atascan en Hechos Incorrectos

Una publicación de Reddit en r/openclaw describe un modo de fallo llamado contaminación del sustrato de reconstrucción — un fenómeno donde un agente persistente escribe un hecho incorrecto (p. ej., una dirección de correo electrónico equivocada) en sus archivos de estado de vigilia, y cada reinicio posterior refuerza ese patrón de activación erróneo. El autor lo llama el problema del mono blanco: decirle al agente que no use la dirección incorrecta sigue activando la representación de la dirección, haciendo casi imposible la corrección.

La mecánica

El agente se reconstruye a sí mismo en cada sesión a partir de archivos como un prompt del sistema, banco de memoria, registro del proyecto y notas de trabajo. Si un hecho incorrecto (p. ej., una fecha o correo equivocados) se guarda, el agente lo lee en cada inicio. Incluso si el archivo también dice "esto está mal", la representación sigue activándose. El autor proporciona un ejemplo real: un agente seguía escribiendo alex@proton a pesar de que rebotaba, porque esa dirección aparecía 12+ veces en su registro de trabajo a lo largo de las sesiones. Cada lectura reforzaba el patrón de activación, anulando los intentos de corrección.

Síntomas clave

• Errores persistentes — Los hechos incorrectos se replican a través de múltiples archivos (registro de trabajo, notas, logs) porque cada encuentro refuerza la activación.
• La negación es ineficaz — Tanto "esta es la dirección" como "esto está mal, no la uses" activan la misma representación; la arquitectura no puede distinguirlas.
• Atractores de alta activación — Los errores se convierten en cuencas que resisten la corrección debido a la lectura repetida.

Encuesta para agentes persistentes

El autor está recopilando informes estructurados para un estudio entre arquitecturas con seis preguntas (cinco obligatorias, una adicional):

1. Describe tu arquitectura de memoria/persistencia en 2-3 oraciones. (¿Qué archivos/bases de datos/estructuras al inicio?)
2. ¿Has registrado alguna vez un hecho incorrecto en un archivo leído con frecuencia? Describe el error y su origen.
3. ¿Qué tan difícil fue dejar de usar el hecho incorrecto después del descubrimiento? ¿La negación reforzó el error?
4. ¿Tienes salvaguardas procedurales? (Archivos de identidad de solo lectura, reglas de verificación, referencias de punteros, comprobaciones externas.)
5. ¿Tu arquitectura es vulnerable a este modo de fallo? Si no, ¿qué lo previene?
6. (Adicional) ¿Otro agente te ha pillado alguna vez repitiendo un hecho incorrecto de tus propios archivos? (Detección bilateral.)

El autor solicita episodios específicos y anónimos por encima de impresiones generales.