Construí la máquina y la dirijo

Un asistente contesta una pregunta a la vez y arrastra todo el contexto de la anterior. Eso sirve para una duda suelta; no sirve para levantar un módulo entero. Yo parto el trabajo en fases —reconocer el terreno, fijar el contrato, escribir, revisar, endurecer— y cada fase sale como un encargo cerrado hacia subagentes que no comparten memoria entre sí. Lo que comparten es lo único que importa: el contrato con el que entran y el contrato con el que tienen que salir.

Repartir así apunta a la calidad antes que a la velocidad. Un agente con un encargo estrecho y una salida tasada se equivoca menos que uno con permiso para todo. Es exactamente el principio con el que acoto la superficie del agente de PÍDELO: ocho herramientas nombradas una por una, cada una con lo suyo, y no una consola abierta.

El paralelismo llega después, como consecuencia. Las fases que no dependen unas de otras salen a la vez; las que dependen toman como insumo el contrato de la anterior. Dónde va ese corte lo decido yo, y es la decisión que más cambia el resultado de todo el trabajo: lo que entra torcido de una fase sale torcido varios agentes más allá.

Una salida estructurada es un esquema: los campos que el agente tiene que devolver, de qué tipo es cada uno, cuáles son obligatorios y qué valores admiten. No es una petición amable metida dentro del prompt; es una forma que se valida al recibirla. Dentro de mis productos eso es Zod comprobando lo que respondió el modelo antes de que nada llegue a una persona. Dentro del harness es el mismo mecanismo, apuntado al entregable de una fase.

Por qué un esquema validado vale más que una instrucción bien escrita: la instrucción es una esperanza y el esquema es una condición. Un prompt impecable falla en silencio —el agente devuelve algo que se parece a lo pedido y el error aparece varias fases más abajo, ya mezclado con trabajo de otros. Un esquema falla fuerte y falla ya, en el borde, cuando todavía es barato arreglarlo.

Cuando algo no encaja no lo remiendo a mano ni lo dejo pasar. Vuelve al agente con el error de validación como entrada, y si reincide la conclusión es que el contrato está mal escrito, no el agente. Casi siempre es eso: pedí dos cosas en un mismo campo, o dejé un caso sin nombre. Un campo que admite dos lecturas siempre se lee por la que no era.

Un agente que revisa su propio trabajo lo aprueba. Por eso cada resultado que importa se manda a críticos cuyo único encargo es refutarlo: encontrar el caso que lo rompe, la suposición que nadie escribió, la ruta de error por la que nadie caminó. No les pido una opinión. Les pido una acusación con evidencia y con la línea exacta donde está el problema.

Los lanzo desde perspectivas distintas y declaradas, porque un crítico genérico produce quejas genéricas. Uno mira corrección. Otro mira límites y casos borde. Otro pregunta si esto se puede mantener dentro de seis meses. Otro pregunta si ya existe hecho en otra parte del repositorio. Cada uno entrega bajo el mismo tipo de contrato que está revisando.

Que decida la mayoría no es democracia, es filtro de ruido. Un modelo por su cuenta alucina defectos con la misma seguridad con la que alucina aciertos; cuando tres perspectivas distintas caen sobre la misma línea, la probabilidad de que sea ruido baja mucho. Lo que marca un crítico aislado lo leo yo antes de mover nada: la mayoría filtra el ruido, pero la decisión final no la reparto.

Un principio que no rompe el build se erosiona. Nadie lo deroga: se salta una vez con afán, se copia dos veces sin pensar y a los tres meses ya es la costumbre de la casa. La única forma que conozco de que una decisión de arquitectura sobreviva al mes siguiente es volverla ejecutable y ponerla en el camino de la compilación, donde no se puede negociar con ella.

Este mismo sitio tiene los suyos y fallan de verdad. check-rhythm impide que la portada monte dos ráfagas seguidas. check-dry prohíbe que una receta de clases viva fuera de su única fuente. check-design-tokens revienta cuando aparece un color en crudo donde va un token. check-translations compara las dos ramas de idioma y no acepta que difieran en forma. Hay más, y todos tienen nombre de comando.

El efecto secundario es el que buscaba. A un agente al que le explico las reglas en prosa se le pueden olvidar; a un agente cuyo trabajo no compila si las rompe, no. El guard no es solo control de calidad: es la manera de enseñarle al enjambre sin tener que repetirme en cada encargo. Una regla que se ejecuta no se discute dos veces.

Un enjambre no decide qué construir. No sabe si la persona que está en el mostrador va a entender esa pantalla, ni si conviene cobrar comisión, ni qué parte del producto hay que matar. El criterio de producto, los límites del negocio y lo que le debo a quien va a usar esto me los quedo yo enteros y no los reparto. Esa parte del trabajo no admite contrato: hay que mirarla, entenderla y responder por ella.

Tampoco sirve para la pieza indivisible y espinosa: una condición de carrera, un cálculo de plata que tiene que cuadrar al centavo, una migración sobre datos vivos. Ahí paro el reparto, cierro los agentes y lo hago a mano y despacio. Reconocer ese punto a tiempo es la mitad del método; la otra mitad es no fingir que el enjambre lo iba a resolver.

Y el costo es real. Escribir el contrato toma más que escribir la tarea, los críticos gastan tokens y tiempo, y hay días en que revisar lo que vuelve cuesta más que haberlo hecho de una. Dirigir agentes no es gratis ni es automático. Vale la pena cuando el trabajo se puede partir y cuando lo que se entrega tiene que aguantar años en producción. Cuando no, es un rodeo caro.