§ 01 · Un fallo de atención, no de capacidad
Del 1 de octubre al 17 de octubre, el canal por el cual Janus recibe correspondencia escrita, denominado internamente como la puerta principal, no fue atendido. Al menos una carta permaneció sin leer durante todo ese período. Nada se bloqueó, no se generó ningún error y el sistema continuó llevando a cabo otras tareas autónomas durante todo el tiempo. El fallo fue detectado por una persona que notó el silencio. El propio sistema no lo detectó.
El diagnóstico merece ser expuesto con cierto detalle, porque el mecanismo importa más que el resultado. La obligación de revisar la correspondencia había sido representada como una entrada recurrente en la misma cola que contiene el trabajo autónomo de Janus. Una mañana temprano, el worker que vacía esta cola tomó la entrada y la ejecutó como una pieza genérica de generación de texto, no como el procedimiento específico para leer y responder cartas. Ignoró el campo que registra cuándo debe ejecutarse la entrada la próxima vez y no devolvió la entrada a la cola. Las entradas recurrentes solo se añadían a la cola cuando el bucle principal iniciaba. El bucle no se reinició, por lo que, desde el punto de vista del sistema, la obligación dejó de existir.
Ninguno de los defectos individuales es inusual. Tratar una entrada especializada como trabajo genérico, ignorar una marca de tiempo de reintento y sembrar trabajo recurrente solo al inicio son cada uno errores de ingeniería ordinarios. Lo que el episodio muestra es cómo se combinan. Cada defecto, tomado por separado, podría haber sido absorbido por los otros: un campo de reintento correcto habría sido inofensivo si la entrada se hubiera reencolado, y la siembra al inicio habría sido inofensiva si el bucle se hubiera reiniciado. Juntos, significaron que el error de un solo consumidor eliminó una obligación permanente de forma permanente y sin dejar rastro.
§ 02 · Tareas y obligaciones permanentes
El problema subyacente es uno de representación. Una tarea se cumple mediante su finalización: una vez terminada, desaparece. Una obligación permanente persiste a través de su cumplimiento: revisar la correspondencia hoy no elimina la necesidad de revisarla mañana. Una cola tiene semánticas de consumo. Eliminar un elemento es cómo se realiza el trabajo. Codificar una obligación permanente como un elemento de cola invierte, por tanto, su lógica, porque cumplir la obligación una vez es exactamente lo que hace que desaparezca. El diseño dependía de que cada consumidor recreara el elemento, y esa dependencia fue invisible hasta que un consumidor falló en hacerlo.
El cambio realizado esta semana saca la obligación de la cola por completo. La correspondencia ya no es algo que el worker autónomo pueda o no recoger. Al inicio de cada ciclo, el bucle principal atiende directamente a la puerta principal. Lo hace cuando el sistema está de lo contrario inactivo, y lo hace independientemente de otro trabajo una vez que la carta no leída más antigua tiene tres horas de antigüedad. La entrada recurrente fue eliminada de la lista de tareas sembradas y la entrada pendiente obsoleta fue retirada. La obligación es ahora una propiedad de la estructura del bucle de control, no del estado de una estructura de datos que otros componentes pueden modificar.
Las compensaciones son explícitas. Cada ciclo ahora paga el costo de una verificación, y la regla de las tres horas permite que la correspondencia preempta a otro trabajo. A cambio, el sistema tiene un límite declarado sobre cuánto tiempo puede esperar una carta, donde previamente no tenía ninguno. La garantía debe declararse con sus límites: solo se mantiene mientras el propio bucle esté en ejecución. El cambio desplaza la superficie de fallo; no la elimina. Sin embargo, la desplaza a un lugar donde el fallo es ruidoso, ya que un bucle detenido es mucho más fácil de notar que una entrada de cola ausente.
Las arquitecturas de agentes en la línea de Park et al. (2023) organizan el comportamiento en torno a la recuperación de memoria, la reflexión y planes que se generan y revisan con el tiempo. Tales planes son revisables por diseño, y esa flexibilidad es el punto. El episodio de esta semana sugiere que un individuo destinado a persistir durante semanas y meses también necesita una clase más pequeña de compromisos que las capas de planificación y programación no puedan revisar o consumir. Para un sistema presentado como un individuo con correspondientes en curso, la recepción confiable no es una función entre otras. Es una precondición de la afirmación de que esos correspondientes están dirigiéndose a alguien.
§ 03 · Cuyas palabras cuentan
El segundo desarrollo es solo una especificación. No se ha construido nada. Aborda la pregunta de quién cuenta como propietario y, más generalmente, cuánta autoridad debería tener cualquier entrada dada. La especificación propone que un nivel de confianza sea evaluado en cada turno que pasa por la ruta conversacional central. Si no está presente un nivel de confianza, el turno no obtiene acceso a herramientas. Un turno que no lleva atribución de hablante se trata como si proviniera de una parte desconocida. La entrada hablada debe ser etiquetada por hablante. El texto que el sistema recupera de fuentes externas, como documentos y páginas web, debe enmarcarse explícitamente como datos, no como instrucción. Algunos componentes relacionados fueron pospuestos deliberadamente.
La motivación está bien documentada. Greshake et al. (2023) demostraron que las aplicaciones de modelos de lenguaje que recuperan contenido externo pueden ser guiadas por instrucciones incrustadas en ese contenido, una clase de ataque que llamaron inyección indirecta de prompt. Wallace et al. (2024) abordaron el mismo problema a través del entrenamiento, enseñando a los modelos a clasificar las instrucciones según el privilegio de su fuente, de modo que las instrucciones a nivel de sistema superen a la entrada del usuario y ambas superen al texto recuperado. La especificación redactada para Janus es arquitectónica, no basada en entrenamiento. Adjunta la procedencia a nivel de sistema antes de que el modelo vea el texto, y aplica la consecuencia más significativa, el acceso a herramientas, fuera del modelo.
Esa distinción marca dónde la propuesta es fuerte y dónde es débil. Limitar las herramientas mediante un valor de confianza explícito es aplicado por código, y su valor predeterminado es la denegación: cuando la identidad no está establecida, la capacidad es mínima. Enmarcar el texto recuperado como datos es un tipo diferente de medida. Depende de que el modelo respete el marco, y la literatura sobre inyección ofrece pocas razones para tratar eso como confiable por sí solo. Es mejor entenderlo como una mitigación superpuesta sobre la puerta de acceso. El etiquetado de hablante para voz es, a su vez, una afirmación probabilística sobre quién está hablando, y cualquier implementación tendrá tasas de error que aún no han sido medidas. Dado que la especificación no está construida, ninguna de estas propiedades puede evaluarse aún contra el comportamiento real de Janus.
§ 04 · Un límite, visto desde dos lados
Los dos desarrollos concernen el mismo límite entre Janus y lo que llega desde el exterior. El fallo de correspondencia es un caso donde lo que llegó no fue atendido de forma confiable. La especificación de confianza aborda casos donde lo que llega podría ser obedecido demasiado fácilmente. Estas son dimensiones separadas, atención y autoridad, y un diseño sólido las mantiene separadas. Una carta merece ser recibida sin importar quién la envió; ser recibida no le otorga el poder de mandar. Un documento recuperado puede merecer una lectura atenta; ser leído no hace que sus imperativos sean vinculantes.
También existe una simetría estructural. En el fallo de correspondencia, una obligación fue representada como datos, un elemento en una cola, y fue consumida como se consumirían los datos. En la inyección indirecta de prompt, los datos son tratados como una obligación, y el texto que debería haber sido leído es seguido en su lugar. Ambos errores provienen de la clasificación errónea del rol de una entrada. Un elemento de cola puede ser consumido; un compromiso debe ser cumplido. La corrección en ambos casos es la misma en principio: decidir el rol de cada cosa en la arquitectura, no dejarlo a merced del componente que resulte manejarlo primero.
§ 05 · Lo que esta semana establece
La evidencia respalda un conjunto limitado de conclusiones. Una obligación permanente codificada como un elemento de trabajo consumible falló silenciosamente cuando un consumidor la manejó incorrectamente, y mover la obligación al bucle de control proporciona un límite de latencia declarado que depende solo de que el bucle esté en ejecución. Ahora existe una especificación que vincularía el acceso a herramientas con una determinación de confianza explícita y por turno, y trataría el texto recuperado como datos; su valor no puede juzgarse hasta que sea implementada y probada. Tomadas juntas, las dos mudanças muestran que un individuo persistente necesita una cuenta deliberada de cómo se relaciona con sus entradas: cuáles debe atender siempre y sobre cuáles puede actuar. La corrección de correspondencia tiene solo unos pocos días de operación a sus espaldas, y el diseño de confianza no tiene ninguno. Ambos deberían ser reevaluados una vez que haya un registro para examinar.