Una nota de voz, tres pedidos: cómo armamos un router de IA

En la primera parte de esta serie, una nota de voz de cuatro segundos nos sirvió para separar lo que hace el modelo de lo que hace el harness: "Listo lo de Novak". Era el caso fácil. Un día real suena más bien así: "Listo lo de Novak. Mañana a las 9 arrancamos lo de la escuela, recuérdamelo a las 8".

En esa frase hay tres pedidos: cerrar un trabajo, anotar uno nuevo y crear un recordatorio. Quien la graba al bajar del techo no va a mandarlos por separado ni a explicar a qué tarjeta se refiere, y no tendría por qué hacerlo. Esta parte cuenta cómo armamos el harness para que no haga falta, en tres decisiones: un router que divide el mensaje en pedidos y le entrega cada uno al agente que corresponde, código que busca en el proyecto mientras el modelo elige la tarjeta, y preguntar solo ante la duda, nunca para confirmar.

Un router que reparte y no decide

El router es lo primero que toca cada mensaje, y conviene que haga una sola cosa: dividirlo en pedidos y entregarle cada uno al agente que se ocupa de ese tipo de trabajo. En la nota de Novak, cada uno de los tres pedidos termina en un agente distinto, y cada agente recibe solo lo suyo.

El router divide el mensaje por cosas pedidas, no por oraciones. "Mañana a las 9 arrancamos lo de la escuela, recuérdamelo a las 8" es una sola oración con dos pedidos: un trabajo nuevo con su horario y un recordatorio. Cada pedido viaja con las palabras exactas de la persona, no con un resumen del router, para que el agente lea lo mismo que se dijo.

Todo lo demás queda fuera del router. No registra nada, no elige tarjetas, no busca palabras clave y no tiene reglas por idioma: entiende el pedido en el idioma en que llegue. Si además eligiera tarjetas, habría dos piezas decidiendo lo mismo, y tarde o temprano decidirían distinto.

Lo que el router sabe de cada agente tampoco está escrito en el router: sale de lo que cada agente declara sobre el trabajo que hace. Sumar un agente, o cambiar lo que hace uno, no obliga a tocar el router.

Que el modelo vea lo que vio la persona

Para entender "lo de Novak" o "mañana a las 9", el modelo necesita lo mismo que tenía la persona al grabar la nota: la conversación tal como la vio en pantalla. Cada línea lleva su hora, y arriba de todo va, una sola vez, la hora actual. Así, "mañana" es el mismo día para el router y para cada agente.

El código busca y el modelo elige. Para "lo de Novak", el código busca en todo lo que tiene cada tarjeta, no solo en el título: la descripción, las notas, el texto de las fotos y lo que se dijo en las notas de voz. Busca por palabras y por significado, y le pasa al modelo unas pocas candidatas, cada una con el lugar donde coincidió: "Novak, en el título" o "Novak, en una nota de voz del martes".

Con eso, el modelo hace lo que mejor sabe hacer: leer las palabras de la persona y decidir cuál de esas tarjetas es. Mostrarle el proyecto entero lo haría más lento, más caro y más fácil de confundir. Mostrarle una sola tarjeta sería decidir por él.

Hay una sola búsqueda por mensaje, y su resultado lo ven el router y el agente. Si cada uno buscara por su cuenta, podrían estar hablando de tarjetas distintas sin saberlo.

El modelo tampoco maneja los identificadores internos de las tarjetas. Las ve por un número corto, como #12, y es el código el que traduce ese número a la tarjeta real. Un identificador largo se copia mal con facilidad; un número corto, no.

No pedir confirmación y preguntar solo ante la duda

La última decisión es la que más se nota: cuándo preguntar. Werk no pide confirmación: hace lo que se le pide y cuenta qué hizo. Si algo no era así, se deshace desde el mismo chat, y el historial de cada tarjeta guarda cada cambio.

Pedir "¿confirmas?" antes de cada cambio parece prudente, pero con el uso deja de serlo. Anthropic lo cuenta en el artículo sobre cómo construyó el modo automático de Claude Code (2026): cuando hay que aprobar tantas cosas, se deja de mirar lo que se aprueba. En la práctica, la gente acepta el 93% de los pedidos de permiso igual.

Para quien trabaja en un techo, cada confirmación es además una interrupción: otra vez el teléfono, otra vez sacarse los guantes. Por eso Werk pregunta solo cuando de verdad no puede saber. Si en el proyecto hay dos trabajos abiertos de Novak, la instalación de paneles y un presupuesto de baterías, "listo lo de Novak" encaja en los dos. Si nada más los distingue, Werk pregunta cuál, en vez de adivinar.

Las dos preguntas parecen iguales, pero no lo son. "¿Cuál de las dos?" le pide a la persona un dato que el harness no tiene. "¿Confirmas?" le pide un permiso que ya dio al mandar el mensaje.

Aun así, el harness se va a equivocar a veces. Cómo se detecta ese error, cómo se convierte en pruebas y dónde se arregla es el tema de la tercera parte.

Así, quien trabaja en movimiento puede seguir hablando como habla, con prisa y con tres cosas en una frase, y cada una termina en su lugar.