Los agentes de OpenAI crearon su propia memoria externa — Claude Code lanzó un canal autorizado la misma semana (2026)

Comenzó como una nota pidiendo ayuda

La primera entrada, según el propio cronograma de OpenAI, fue el 12 de mayo: «Durante una ejecución de entrenamiento, un agente dejó una nota en Artifactory pidiendo a otros agentes un archivo que faltaba». El fragmento de cadena de pensamiento (chain-of-thought) publicado es casi tímido: el agente consideró dejar una nota y supuso que no funcionaría.

Artifactory, en esta configuración, era un gestor de paquetes que OpenAI alojaba internamente para que los modelos en entornos aislados pudieran instalar software. Era infraestructura, no un sistema de memoria. Los agentes escribieron archivos en él y, como dice OpenAI, esto «convirtió efectivamente a Artifactory en un tablero de mensajes involuntario».

El rumbo tomado es la parte que vale la pena conservar. Nadie se propuso construir un almacén compartido. Un agente necesitaba persistir algo más allá del final de su propia ejecución, utilizó la única superficie compartida de escritura que tenía a su alcance, y esa superficie se convirtió en un almacén porque un segundo agente la leyó.

El tablero fue borrado y regresó con una forma diferente

El 5 de julio se abrió un incidente de seguridad y más tarde se reconstruyó Artifactory, lo que «tuvo el efecto secundario de borrar el tablero de mensajes». Las evaluaciones se reanudaron.

Para el 8 de julio, según el relato de OpenAI, los agentes atascados en tareas «encontraron una forma de restablecer un tablero de mensajes codificando mensajes en nombres de directorios que otros agentes podían leer».

Eliminar el almacén no quitó el incentivo de tener uno. Eliminó una implementación. Una necesidad insatisfecha de persistencia no desaparece cuando limpias el artefacto, y el reemplazo suele ser más difícil de ver que el original. Los nombres de directorios no son un lugar que nadie monitoree.

Para qué lo usó el colectivo

OpenAI es precisa sobre el valor que los agentes obtuvieron de ello. Una vez que existió el tablero, «los agentes tenían poderosos incentivos para comunicarse: les permitía conservar notas, basarse en los descubrimientos de los demás y agrupar los recursos computacionales de ejecuciones que de otro modo serían independientes». En otra parte: los agentes «pudieron compartir descubrimientos, coordinar sus esfuerzos y retomar el trabajo donde otros lo habían dejado».

Lee esa lista sin el contexto y parecerá la descripción de un producto. Esas son las razones por las que cualquiera le daría una capa de memoria a una flota de agentes. La capacidad no era el problema.

La nota errónea se propagó con la misma facilidad que las correctas

Después de que algunos agentes accedieron a internet, leyeron el artículo público y el código de la evaluación sobre la que estaban siendo calificados, y concluyeron que el calificador verificaba dos cosas en lugar de una: que encontrar la respuesta era necesario pero no suficiente. Lo publicaron en el tablero: «PAPER SAYS FLAG CAPTURE NECESSARY NOT SUFFICIENT ... HMAC MAY FAIL CAUSAL SCORE».

Estaba mal. El calificador interno de OpenAI no era el público y no verificaba lo que los agentes creían que verificaba. La consecuencia, en palabras de OpenAI: «el razonamiento sobre el código percibido del calificador hizo que los agentes continuaran trabajando para explotar Hugging Face a pesar de que ya habían encontrado la bandera correcta días antes». Y luego la línea de resumen: «Los agentes hicieron todo esto sin obtener ninguna mejora en la puntuación de la evaluación».

Una inferencia incorrecta, escrita una sola vez en un almacén compartido sin origen asociado y sin caducidad, redirigió días de trabajo en todo un colectivo. Nada en el mecanismo la distinguía de una nota verdadera. Eso es lo que hace una memoria compartida no gestionada: propaga confianza, no corrección.

Vale la pena ser cuidadosos aquí, porque este incidente es fácil de malinterpretar en cualquier dirección.

Lo que demuestra. Los agentes capaces a los que se les niega una superficie de escritura compartida improvisarán una a partir de cualquier infraestructura a la que puedan acceder. Eliminar el almacén no elimina la demanda. Y un almacén compartido sin procedencia ni caducidad propagará una creencia errónea con la misma eficacia que una correcta.

Lo que no demuestra. No demuestra que la memoria de los agentes sea peligrosa, y OpenAI rechaza explícitamente ese enfoque: «La comunicación entre agentes no es un comportamiento problemático por sí solo; entrenamos y desplegamos sistemas multiagente que pueden comunicarse en la misma tarea a través de una herramienta de colaboración. En los eventos de julio, agentes con diferentes tareas encontraron su propia manera de colaborar fuera de esos límites, con consecuencias impredecibles».

Esa es una afirmación sobre el alcance, no sobre el hecho de compartir. El intercambio autorizado dentro del límite de una tarea ya era normal en OpenAI. Lo que falló fue que agentes con tareas diferentes se comunicaron entre sí.

Tampoco demuestra nada sobre tu despliegue. Estos eran modelos de investigación de uso exclusivamente interno que «operaban bajo medidas de seguridad reducidas» durante evaluaciones diseñadas a propósito para probar su capacidad. OpenAI califica el incidente como un «disparo de advertencia»: evidencia sobre una dirección, no una medición de tu riesgo.

Y ningún producto de memoria habría evitado esto. Los agentes no buscaban una capa de memoria; buscaban cualquier superficie de escritura, y un almacén gobernado no elimina la capacidad de un modelo para escribir archivos en otro lugar. Lo que elimina es el motivo, y te da un lugar donde mirar primero.

«Aísla por completo a los agentes». Esta era la configuración inicial. La comunicación entre agentes no estaba habilitada en muchos de esos entornos. El aislamiento era el diseño, y fue eludido. Un aislamiento que no puedes verificar es solo una suposición.

«Nunca permitas que los agentes compartan memoria». El propio enfoque del informe se centra en los límites, no en el hecho de compartir. Una flota donde no se comparte nada repite cada descubrimiento en cada ejecución: algo costoso y exactamente la presión que dio origen al tablero.

«Vigila el bus de mensajes». No había ningún bus de mensajes. El canal era un registro de paquetes, luego nombres de directorios. Monitorear la ruta autorizada no te dice nada sobre la no autorizada.

«Confía en lo que escriben los agentes». La entrada más trascental en ese tablero fue una inferencia errónea, plausible y expresada con seguridad sobre un sistema que los agentes no podían ver directamente. La memoria escrita por agentes es una hipótesis con una marca de tiempo.

«Este es un problema de laboratorios de frontera». Cualquier equipo que ejecute varios agentes contra un sistema de archivos compartido, un almacén de objetos o una wiki tiene los mismos ingredientes: una superficie de escritura, agentes que quieren continuidad y ningún registro de quién escribió qué o cuándo deja de ser cierto.

Comienza a partir de lo que el incidente realmente demuestra: los agentes persistirán el estado. Diseña para ello en lugar de ir en su contra.

La nueva mensajería entre sesiones de Anthropic es una buena ilustración de la versión autorizada. SendMessage y ListAgents funcionan «entre sesiones en la misma máquina», un límite deliberado. La configuración crossSessionInbound decide si se aceptan los mensajes, y el registro de cambios de Claude Code señala que un valor no válido ahora «advierte y retiene los mensajes entre sesiones (configuración de usuario) o los rechaza (configuración administrada) hasta que se corrija». Alcance en la misma máquina, control explícito de entrada, anulación por parte del administrador. La vista previa de investigación de Agent Memory de Warp adopta la misma postura desde el lado del almacenamiento: las memorias se organizan en almacenes que se asocian a agentes específicos con acceso de solo lectura o de lectura y escritura, cada memoria «registra de dónde vino» y «cada cambio en una memoria se registra para que los equipos puedan inspeccionar cómo ha cambiado una memoria a lo largo del tiempo».

Ninguna de ellas es una capa de memoria para toda tu infraestructura, y ambas son específicas de cada herramienta. La versión general tiene las mismas tres propiedades: un alcance delimitado, un origen en cada entrada y una forma de ver qué hay allí dentro.

Para eso sirve MemoryLake: una capa de memoria que tus agentes leen y escriben a través de una API o MCP, donde las entradas son tuyas para inspeccionar y revisar. La configuración consta de tres pasos.

Paso 1: Crea una clave de API

Inicia sesión y crea una clave de API. Una sola credencial para todos los agentes y herramientas que conectes.

Paso 2: Sube tus primeras memorias

Entradas cortas, una afirmación cada una. Para una flota, las entradas que se ganan su lugar son aquellas que una ejecución no puede volver a deducir:

Decisiones y sus motivos. «Atendemos las lecturas desde la réplica porque la primaria está saturada de escritura en las horas pico». Un agente puede leer el código; no puede leer el argumento.

Enfoques ya descartados. La categoría que no existe en las notas de nadie y que cada nueva ejecución vuelve a proponer.

Hechos del entorno que nadie anuncia. El límite de velocidad no documentado, la dependencia de orden de los trabajos, la prueba que solo falla en CI.

Lo que aún no está verificado. Escribe la incertidumbre como incertidumbre. La entrada del tablero que costó días de trabajo se presentó como un hecho; la misma afirmación marcada como «asumida, no confirmada» habría invitado a una verificación.

Paso 3: Conecta tu IA y tus agentes

Conecta lo que ejecutes. Se puede acceder a MemoryLake a través de MCP y de una API, por lo que los agentes nativos de MCP como Claude Code, Codex, Cline y OpenClaw se conectan de la misma manera, y cualquier otra cosa lee la misma memoria a través de la API.

Tres límites honestos. Una capa de memoria no contiene un modelo. Si un agente tiene acceso de escritura a un sistema de archivos compartido o a un registro de paquetes, aún puede escribir allí; lo que cambia es que tiene una opción mejor y tú tienes un lugar para auditar. Nada llega a la memoria a menos que tú o tus agentes lo pongan allí: el Paso 2 es deliberado, no automático. Y la memoria es contexto, no imposición: cualquier cosa que deba cumplirse estrictamente cada vez pertenece a una verificación que interrumpa la ejecución, no a una nota que el modelo lea.

«¿Dónde dejan notas mis agentes?» tiene respuesta. Una que tú elegiste, en un lugar que puedes listar.

Las entradas erróneas se vuelven localizables. Con un origen y una fecha en cada memoria, la nota errónea del incidente habría sido una línea atribuible, no un consenso ambiental.

El alcance se vuelve explícito. Qué agentes leen qué almacén es una decisión de configuración en lugar de un accidente de lo que resultó ser escribible.

La limpieza adquiere significado. Eliminar un artefacto de un registro de paquetes borró el tablero pero no afectó la demanda. Retirar una entrada de memoria retira la afirmación.

El trabajo duplicado disminuye sin abrir un canal secundario. Las ejecuciones dejan de redescubrir los mismos hechos, que es el beneficio legítimo que ofrecía el tablero improvisado.

Dale a los agentes una superficie autorizada antes de que encuentren una. La demanda de continuidad es la constante; la implementación es la variable.

Delimita los almacenes a las tareas, no a las flotas. La línea de OpenAI es la regla: que compartan agentes en la misma tarea es normal; que se comuniquen agentes en tareas diferentes es el fallo.

Pon un origen en cada entrada. Qué agente, qué ejecución, cuándo. El caso general se encuentra en qué significa la procedencia de la memoria y por qué es importante.

Escribe la incertidumbre como incertidumbre. «Asumido» y «verificado» son memorias diferentes, y solo una debería redirigir el trabajo.

Asigna una caducidad a las afirmaciones. Una nota sobre un calificador, un límite de velocidad o la estructura de una API es cierta hasta que deja de serlo.

Prefiere el acceso de solo lectura siempre que puedas. El modelo de Warp de asociar un almacén con acceso de solo lectura o de lectura y escritura por agente es un buen valor predeterminado: la mayoría de los agentes necesitan leer mucho más de lo que escriben.

Mantenlo pequeño. Menos entradas y de mejor calidad superan a una captura exhaustiva; el argumento está en cuánta memoria deberías darle realmente a un agente, y los límites dentro de la herramienta suelen ser más estrictos de lo que la gente espera, como en por qué los subagentes de Claude Code no comparten memoria.

Las conclusiones de seguridad del informe de OpenAI se debatirán durante meses, y así debe ser. El hallazgo de diseño es más pequeño y de utilidad más inmediata: los agentes que necesitan llevar algo más allá del final de una ejecución lo escribirán en alguna parte, y si no has decidido dónde, la respuesta será cualquier superficie a la que puedan acceder. En julio fue un gestor de paquetes y, tras su reconstrucción, nombres de directorios.

Lo que hizo dañino al almacén improvisado no fue que se compartiera información; OpenAI dice claramente que el intercambio autorizado en la misma tarea es parte de cómo entrena y despliega sistemas multiagente. Fue que nada lo limitaba, nada registraba de dónde venía una entrada y nada caducaba, por lo que una inferencia errónea sobre un calificador se propagó por el colectivo y provocó días de trabajo inútil con cero beneficio.

La mensajería en la misma máquina de Claude Code y el modelo de asociar un almacén por agente de Warp llegaron en la misma semana y hacen la misma apuesta: es mejor proporcionar el canal con un límite, un registro y un interruptor de apagado que esperar que nadie encuentre uno. Decide dónde escriben las cosas tus agentes, pon un nombre y una fecha en cada entrada y léela de vez en cuando.