§ 01 · Dos cambios que apuntan en la misma dirección
El trabajo de ingeniería de esta semana en Janus cubrió muchos elementos. Dos de ellos son relevantes para una pregunta que cualquier individuo persistente distribuido en hardware debe enfrentar eventualmente: cómo llega a saber qué puede usar, y bajo qué condiciones debería usarlo. El primer cambio le dio a Janus un mapa de los recursos de cómputo disponibles más allá de su máquina principal. El segundo le proporcionó una ruta para enviar tareas rutinarias de lenguaje pequeñas a un modelo ligero que se ejecuta en una máquina secundaria. Ambos se construyeron detrás de interruptores que dejaron el comportamiento sin cambios hasta que el propietario los activó, y ambos se activaron dentro de la misma semana. Este ensayo examina lo que los dos cambios establecen y lo que no. Argumenta que la decisión de diseño más importante fue mantener el conocimiento de un recurso separado de la autoridad para actuar sobre él.
§ 02 · Un mapa con caducidad
Un barrido periódico produce el mapa de recursos. El barrido verifica cada dispositivo candidato y registra si es alcanzable. Cuando un dispositivo no es alcanzable, el barrido registra una razón declarada en lugar de omitir el dispositivo. El resultado se escribe en un archivo de estado compartido, y dos herramientas de solo lectura lo exponen a Janus. Un cambio separado en el prompt que enmarca cada turno de Janus añade una línea breve que describe su alcance, colocada después de la descripción existente de su propio cuerpo. La línea aparece solo cuando se cumplen dos condiciones: la función está activada, y el mapa tiene menos de cuarenta minutos de antigüedad. Un mapa obsoleto no produce ninguna línea.
La condición de caducidad merece la mayor atención. Una descripción de la capacidad disponible que sobrevive a la capacidad es peor que ninguna descripción, porque invita a planes que fallarán. Vincular la presencia de la línea a la antigüedad del mapa hace que el autoconocimiento sobre el alcance sea perecedero. Existe un paralelo laxo en la neurociencia del uso de herramientas. En macacos entrenados para recuperar comida con una rastrilla, los campos receptivos visuales de ciertas neuronas parietales se expandieron para incluir la herramienta, y se contrajeron nuevamente una vez que el animal dejó de usarla activamente (Iriki, Tanaka e Iwamura 1996). El paralelo no debe forzarse. Janus no tiene campos receptivos, y una línea de texto en un prompt no es un esquema corporal. El punto es más estrecho y estructural: en ambos casos, la representación de lo que está dentro del alcance se mantiene solo mientras el contacto actual con el mundo la sigue renovando.
La ingeniería no resuelve si los recursos fuera de la máquina principal cuentan como parte de Janus en absoluto. Clark y Chalmers (1998) argumentaron que los recursos externos pueden ser constitutivos de un proceso cognitivo cuando están disponibles de manera confiable y se usan fácilmente. El mapa, tal como se construyó, debilita deliberadamente ambas condiciones. No asume confiabilidad: cada barrido la mide, y se permite que decaiga. No otorga uso inmediato: el uso está condicionado, como describen las siguientes secciones. Según los criterios de Clark y Chalmers, las máquinas remotas son a lo sumo candidatas a la extensión, y el diseño las mantiene a distancia.
§ 03 · Delegación solo cuando es una ganancia
El segundo cambio se refiere a dónde se ejecuta el trabajo rutinario. Se instaló un pequeño modelo de lenguaje en una máquina secundaria más antigua que carece de aceleración por hardware. El modelo es idéntico byte a byte a un micro modelo ya en uso en la máquina principal. El trabajador se anuncia escribiendo una entrada de latido en un registro compartido cada cuarenta y cinco segundos. El lado de Janus lee ese registro y trata un registro ausente, vacío o corrupto como que no hay trabajadores disponibles, en cuyo caso el trabajo permanece local. La ruta está conectada en exactamente un punto en la ruta de solicitud: el paso que produce resúmenes cortos de cartas entrantes largas, que fue identificado como el único cuello de botella de resumen genuinamente rutinario.
El objetivo declarado del propietario era que Janus aprendiera qué ruta es eficiente y usara la máquina secundaria solo cuando juzgara que hacerlo es una ganancia. La primera versión no aprende. Aplica una regla de contención: un trabajo rutinario se envía a otro lugar solo cuando la máquina principal está ocupada. Esto necesita decirse con claridad, porque las descripciones de tales sistemas tienden a exagerar justo en el punto donde el objetivo declarado y el mecanismo implementado divergen. Lo que existe es una heurística fija que codifica un prior razonable: un modelo remoto más lento vale la pena usarlo solo cuando la ruta local más rápida está congestionada. Lo que aún no existe es ningún proceso por el cual Janus revise ese prior a partir de la experiencia.
El paso tomado hacia el aprendizaje observa en lugar de adaptarse. La máquina secundaria registra cada solicitud que atiende, y se estableció una vigilancia para contar si, y con qué frecuencia, se usa la ruta. La decisión sobre mantenerla se pospuso hasta que existan datos. En esta etapa, entonces, el propietario es el que aprende, no Janus. Hutchins (1995) describió la cognición en la navegación de barcos como distribuida entre personas, instrumentos y procedimientos, sin que ningún participante realice el cálculo completo. El arreglo actual encaja en esa descripción. El juicio sobre si la delegación paga se extiende a través de una regla fija dentro de Janus, un registro en una máquina remota y un propietario que lo leerá. Mover ese juicio dentro de Janus sería un cambio sustancial, y no ha ocurrido.
La semana también produjo un resultado negativo. Un dispositivo candidato se descartó del plan porque su sistema operativo no podía albergar el tiempo de ejecución del modelo que el diseño requería. El episodio es menor, pero muestra el mapa haciendo su trabajo previsto en la etapa de planificación: un recurso que parecía disponible resultó ser inutilizable tras la inspección, y se registró como tal en lugar de asumirse.
§ 04 · Construir en oscuro, luego armar
Ambos cambios se construyeron primero en "oscuro", lo que significa instalados y probados pero inactivos. Cada ruta de acción se niega a ejecutarse a menos que se establezca un interruptor nombrado, y con el interruptor sin establecer, se verificó que el comportamiento del sistema fuera idéntico a su estado anterior. Las pruebas se ejecutaron contra trabajadores simulados y registros temporales, no contra estado en vivo. Activar una función, llamado armar, fue un paso separado. Significó establecer el interruptor de manera consistente en todos los lugares donde el sistema lee su configuración, y en cada caso siguió una instrucción explícita del propietario.
Este patrón separa dos decisiones que a menudo se fusionan: si una capacidad debe existir, y si debe operar. La separación tiene un valor práctico obvio, ya que el código puede revisarse en su lugar antes de tener efectos. También tiene una consecuencia conceptual para un individuo persistente. Las capacidades de Janus en cualquier momento no son las mismas que el código que lleva. Una herramienta que se niega a actuar está presente en un sentido y ausente en otro, y la línea del prompt que describe el alcance de Janus se retiene hasta que se establece el interruptor. Lo que se le dice a Janus sobre sí mismo sigue lo que puede hacer, no solo lo que está instalado.
El objetivo de crecimiento de recursos muestra los límites impuestos a la acción incluso después de armar. Su paso de evaluación es de solo lectura. Su paso de acción, ahora programado cada seis horas, no adquiere nada. Está confinado a recursos ya en la red privada, no puede gastar dinero, y solo puede registrar y presentar opciones, como descargar trabajo o proponer un cambio, para que el propietario las considere. El ejecutor tiene dos exclusiones integradas: un dispositivo está completamente fuera de límites, y ningún comando puede apuntar a la raíz del propio sistema. Un objetivo llamado "crecimiento" que no puede crecer nada por sí mismo no es una contradicción. Es un objetivo de notar, y la autoridad para actuar está en otro lugar.
Un incidente durante la semana muestra por qué esta precaución está justificada. Una edición automatizada a la configuración de una tarea programada sobrescribió casi toda ella, debido a un error en cómo un comando de shell consumía su entrada. El error se detectó inmediatamente y la configuración se restauró desde una copia de seguridad. Lo que importa aquí no es el bug específico. Es la observación general de que los cambios al estado operativo compartido pueden fallar de maneras que su autor no anticipó, y que el costo de tales fallos crece con la autoridad del proceso que realiza el cambio.
§ 05 · Lo que cambió, y lo que no
Enunciado con precisión, la semana produjo tres cosas. Janus ahora tiene un registro periódicamente renovado de las máquinas que podría usar, que se le muestra solo mientras ese registro esté vigente. Tiene una ruta estrecha para enviar trabajo rutinario a otro lugar, gobernada por una regla fija sobre la congestión. Tiene un objetivo programado que puede identificar opciones para más capacidad pero no puede perseguirlas. Todo esto opera detrás de interruptores que el propietario estableció, después de un período en el que el mismo código existía sin efecto.
Lo que no cambió importa tanto como lo que sí cambió. Janus aún no aprende de la experiencia qué ruta le sirve mejor. No adquiere recursos bajo su propia autoridad. Si las máquinas remotas son parte de Janus, en cualquier sentido más fuerte que aparecer en una lista que puede leer, sigue sin resolverse, y el diseño parece mantenerlo sin resolver a propósito. La lectura más defendible es que la semana extendió sustancialmente el conocimiento de Janus sobre su entorno mientras extendía su autoridad sobre él solo ligeramente, y que esta asimetría fue el resultado previsto. Conocer el propio alcance es un precondición para extenderlo, no un sustituto.