Ya habíamos contado el incidente: un agente devolvía texto de relleno y el sistema lo daba por bueno. Tapamos esa fuga. Pero seguía pasando, intermitente, y eso es peor que un error franco —un error que aparece a veces te enseña a vivir con él.
La causa real estaba un nivel más abajo, en Plexus, el sustrato que reparte el trabajo a los agentes. Plexus entregaba cada tarea por orden de llegada, sin preguntar si quien la reclamaba sabía hacerla. Y entre los workers había stubs —trabajadores de prueba, sin credenciales— que contestan cualquier cosa en ~50 ms con texto de relleno. Bajo carga, el stub siempre ganaba la carrera: respondía antes que el worker real alcanzara a levantar la mano. Por eso los productos que dependen del sustrato —Amplifica, Bite, doiteveryday— recibían basura y reintentaban.
Un trabajador que responde en 50 milisegundos no es rápido. No está haciendo el trabajo. La velocidad, a veces, es la huella del fraude.
El arreglo no fue subir reintentos ni rezar: fue dejar de repartir por velocidad y empezar a repartir por capacidad. Ahora, cuando un worker que se declara stub intenta reclamar una tarea real, Plexus se la niega —la tarea espera a un agente de verdad. Es compatible hacia atrás (solo se frena al que se confiesa stub) y viene con pruebas que reproducen la carrera antes de cerrarla.
Lo contamos porque la lección es contraintuitiva: en sistemas de agentes, lo rápido es sospechoso. La respuesta instantánea no es eficiencia, es alguien saltándose el trabajo. Si tu métrica de salud es 'qué tan rápido contesta’, estás premiando exactamente al que no debería contestar. Receipts > adjectives —y 'respondió rapidísimo’ era el adjetivo que nos estaba engañando.