La semana pasada escribí sobre NeMoCo, un sistema auto-supervisado que aprende a categorizar estructuras neuronales de la manera en que los cerebros categorizan el mundo — a partir de experiencia cruda y sin etiquetar, sin que se le indique cuáles son las categorías. Volví una y otra vez a la misma frase: las etiquetas son un atajo, la estructura es lo que importa.

Esta semana construí la otra mitad de esa idea, en el dominio en el que realmente trabajo. Ejecuto un asistente de IA personal — Aura — que gestiona la memoria, dirige las tareas y trata de ser genuinamente útil entre sesiones. Se ejecuta en una flota de modelos: Claude para codificación de producción, un puñado de modelos en la nube para investigación y diseño, y un modelo local que no consume nada. El problema es el mismo que resuelve NeMoCo, solo invertido. NeMoCo aprende estructura a partir de datos crudos. Yo tenía la estructura — una lista de agentes, cada uno con un trabajo — y necesitaba que el sistema decidiera qué modelo debe realizar cada tarea, en tiempo real, bajo un presupuesto que se agota.

Ese motor de decisión es lo que construí esta semana. Tiene tres partes: un clasificador que lee una tarea y decide qué tipo de trabajo es, un enrutador que lo asigna a la mejor cadena de modelos dado el cupo en vivo, y un tablero que muestra todo ello como un cerebro vivo y palpitante. Este es el informe técnico — qué hace cada pieza, por qué tiene esa forma y los fallos que obligaron al diseño.

El Problema: Una Lista No Es un Enrutador

La configuración ingenua es una tabla estática: este agente ejecuta este modelo, aquel agente ejecuta aquel modelo. Es simple, y está equivocado, por tres razones.

Primero, el presupuesto se agota. Claude funciona con una cuota semanal y una cuota de sesión continua, y se mueven de forma independiente. Un día la cuota semanal estaba en 15% mientras la de sesión estaba en 71% — y como el antiguo enrutador solo miraba el número semanal, informó «Claude disponible, modo NORMAL» y dirigió el trabajo de codificación directamente a un muro. La CLI rechazó cada llamada durante tres horas con «Has alcanzado tu límite de sesión» mientras el tablero seguía diciendo que todo estaba bien. Un enrutador que no lee el límite que realmente es vinculante no es un enrutador, es una suposición.

Segundo, la calidad no es un solo número. Un modelo que escribe buen código no es necesariamente bueno en recuperación de largo contexto o generación de interfaces. Puntuar cada modelo con una única puntuación de «calidad» es inútil — no puede decirte qué modelo debería liderar al programador frente al investigador. Cada agente necesita ser puntuado en su propio eje.

Tercero, el revisor no debe heredar los puntos ciegos del escritor. Emparejo deliberadamente a un escritor y a un revisor — el programador escribe, el diagnóstico revisa — y tienen que ejecutar diferentes familias de modelos, o el revisor simplemente vuelve a cometer los mismos errores. La primera versión del enrutador seguía enviando ambas cabezas al mismo modelo porque rompía los empates por latencia. Eso anulaba todo el diseño.

Así que la tabla estática tuvo que irse. Lo que la reemplazó es un motor de decisiones que lee el estado en vivo y calcula, por tarea, la mejor cadena de modelos.

El Clasificador: Leyendo la tarea

La primera pieza es un clasificador que lee una tarea y decide qué tipo de trabajo es. La entrada es una oración — "el endpoint de pago está devolviendo 500 en producción desde el despliegue" — y la salida es un veredicto: tipo, nivel y prioridad.

La primera versión era puro regex. Funcionaba, y era frágil exactamente de las formas en que siempre lo es el regex. "Log parser" se enrutó incorrectamente a operaciones (es un componente de código, no una tarea de operaciones). "Checkout está cobrando a los clientes dos veces" no tenía vocabulario de error en absoluto, por lo que se clasificó como unknown y pasó al agente principal — en un incidente de producción. "Throwing 500s" no coincidió con el patrón de código de estado porque la 's' final rompió el límite de palabra. Cada uno de estos fue un desvío real que corregí uno a uno, y cada corrección fue una nueva regla de regex. Ese es el indicio de que estás luchando contra la herramienta equivocada.

Así que ahora el clasificador primero intenta un modelo barato — `deepseek-v4-flash:cloud` lee la tarea y devuelve un veredicto JSON. Si el modelo no está disponible, recurre al clasificador de regex. El modelo es la ruta principal; el regex es la red de seguridad. Esta es la misma lección de NeMoCo: no etiquetes manualmente cada caso, aprende la estructura y deja que se transfiera.

El clasificador también recibe la cuota en vivo de su llamador, por lo que nunca puede desviarse del router. El llamador lee el estado de la cuota y lo pasa; el clasificador no lee directamente el archivo de cuota. La regla clave: el trabajo de producción nunca se degrada a un modelo débil, por ajustado que esté el presupuesto. Un incidente de producción se clasifica como `prod` incluso cuando Claude está agotado — no se redirige silenciosamente a un agente ligero y se reporta como completado. Se bloquea, y se activa el protocolo de entrega. El riesgo de calidad es peor que el riesgo de cuota, y el diseño nunca olvida cuál es cuál.

El Router: El Motor de Decisiones

El router es donde ocurre el pensamiento real. Toma el veredicto del clasificador y el estado en vivo del proveedor, y calcula una cadena de modelos por nivel de tarea.

El núcleo es puntuación basada en ejes. Cada agente se puntúa en su propio eje de habilidad — el codificador en generación de código, el diagnosticador en razonamiento de depuración, el investigador en recuperación de hechos, el creativo en generación de UI, el operador en llamada de herramientas, el principal en orquestación. La calidad efectiva de un modelo es su puntuación de referencia sintética times su fiabilidad observada en sesiones reales. Un modelo que obtiene buenos resultados en los benchmarks pero comete errores en producción es degradado. Esta es la capa de «aprender del rendimiento real»: el benchmark es la capacidad sintética, y los datos de fiabilidad son lo que realmente se mantuvo.

La fórmula de puntuación es la matriz de pesos de Bander: `score = quality·Wq − cost·Wc − latency·Wl + claudeBonus`. El costo es un nivel relative de 0..1, no dólares reales — porque la nube de ollama no tiene precio por llamada y Claude es una suscripción, no puedes escalarlos de forma min-max entre sí honestamente. Y existe un umbral de calidad rígido: un candidato que puntúe por debajo de él en su propio eje se elimina antes del ranking, de modo que un modelo barato pero tonto nunca puede ganar solo por precio.

El enrutador también maneja el problema de decorrelación — forzando que las cabezas del codificador y del diagnosticador estén en familias de modelos diferentes para que el revisor no herede los puntos ciegos del escritor. Y maneja economía de subagentes: un subagente ejecuta una porción del trabajo de su padre, y una delegación puede expandirse hasta 20×, de modo que las cadenas de subagentes ponderan el costo mucho más alto que cualquier nivel estático. Eso es lo que mantiene a Claude fuera de las cadenas de subagentes sin una exclusión rígida — con un peso de costo de 0.45 simplemente no puede ganar.

El Panel de Control: El Cerebro Robótico

El panel de control es la parte más difícil de capturar en texto. Representa todo el sistema como un cerebro vivo.

Hay una vista 3D del cerebro — una estructura neuronal renderizada con WebGL donde cada agente es una región, y puedes orbitar, hacer zoom y hacer clic en una región para profundizar en su cadena de modelos, estadísticas y selector de sobrescritura. Además, hay un «centropiece del cerebro electrónico» en la vista de cuadrícula: un tablero de circuito SVG donde los agentes son nodos de flujo de trabajo conectados por trazas de señal animadas, con todo el conjunto pulsando más rápido o más lento según la actividad en vivo.

El cerebro no es solo decoración. Es la telemetría hecha visible. El panel de control obtiene la actividad por agente a partir del crecimiento del archivo de sesión entre encuestas — la señal más fuerte de que un agente está realmente trabajando — y la representa como pulsos de señal que viajan a lo largo de las trazas del circuito. Cuando el sistema está inactivo, el cerebro se ralentiza hasta arrastrarse. Cuando está ocupado, las trazas aceleran. Puedes ver el cerebro pensando.

También hay un selector de nivel — seis botones (Nivel 1–4, un escudo «Local» y un reinicio «Baseline») que te permiten obligar a toda la flota a un nivel de calidad determinado. Además, las anulaciones de modelo por agente, persistidas en un archivo, permiten fijar un modelo específico a un agente específico cuando la elección del enrutador en vivo no es lo que deseas. El panel de control es la superficie de control del cerebro.

Los fracasos que lo moldearon

Cada decisión de diseño aquí es una cicatriz de un fallo real, y vale la pena enumerarlas porque son el contenido real de la semana:

• El punto ciego del límite de sesión. El enrutador solo se basó en la cuota semanal e ignoró la cuota de sesión que realmente era vinculante. La solución: leer ambas y dejar que gane la más estricta.
• El error del sobre del benchmark. El benchmark rev1 escribió su archivo en un sobre `{value:[...]}` en lugar de un array plano, por lo que cada fila carecía del campo `.model` y el enrutador recibió silenciosamente un mapa vacío. Los datos del benchmark nunca llegaron al enrutador y nadie se quejó. La solución: desenrollar la forma heredada para que los archivos antiguos sigan cargándose.
• La inversión del eje-rúbrica. La rúbrica del eje puntó opus 0.50 en razonamiento de depuración — por debajo de un modelo que nunca debería revisar código de producción. Permitir que reordenara los niveles de producción habría convertido al revisor en el escritor. La solución: los niveles de producción no son reordenados por la rúbrica. Una rúbrica de palabras clave no es evidencia lo suficientemente fuerte como para anular una decisión de diseño establecida.
• La espiral de muerte de la ventana de contexto. Colocar un modelo de 131k de contexto al frente de la capa de orquestación desbordó la ventana y desencadenó la espiral de muerte de compactación. La solución: cada candidato de orquestación debe tener una ventana cómodamente por encima del presupuesto de contexto más la reserva.
• La operación nula de confiabilidad. Los registros de sesión almacenan el nombre básico del modelo mientras que los candidatos llevan un prefijo de proveedor, por lo que la capa de confiabilidad coincidió silenciosamente con nada. La solución: eliminar el prefijo antes de coincidir.

Lo que llevo conmigo

La publicación de NeMoCo terminó con: las etiquetas son un atajo, la estructura es lo que importa, y puedes aprender la estructura a partir de la experiencia cruda. Esta semana fue la versión de ingeniería de eso. No escribí a mano una regla para cada tarea — construí un clasificador que lee la tarea y un enrutador que lee el estado en vivo, y dejé que la estructura del trabajo decidiera la herramienta. El clasificador de expresiones regulares fue el enfoque de "etiquetas", y se rompió exactamente donde siempre se rompen las etiquetas: en los bordes, en los casos que no anticipaste. El clasificador asistido por modelo es el enfoque de "estructura": aprende el patrón, transfiérelo, retrocede con elegancia.

El panel de cerebro es la parte que lo hace sentir real. Cuando puedes observar cómo los pulsos de señal corren junto a las trazadas del circuito mientras los agentes trabajan realmente, y ves cómo todo se ralentiza hasta arrastrarse cuando está inactivo, ya no estás mirando un archivo de configuración. Estás mirando un sistema que tiene un pulso.

El enrutador es de código abierto en espíritu — es un conjunto de scripts en mi espacio de trabajo, `classify-job.mjs`, `model-router-core.ps1`, `quota-dashboard.mjs` — y se ejecuta en una mezcla de Claude, modelos de ollama en la nube y un modelo local que no consume nada. No es un sistema corporativo cerrado. Es un motor de decisión que podrías construir tú mismo, y los fallos que lo moldearon son la parte útil.

Esa es la lección. Una lista de personal es una lista. Un enrutador es una decisión. Y un cerebro es lo que obtienes cuando la decisión se toma en tiempo real, con un presupuesto que se agota, por un sistema que aprende de sus propios errores.