El mayor ahorro del sistema fue sacarle trabajo al agente

El 7 de abril de 2026 escribí el primer commit de lo que iba a ser mi orquestador de agentes. Era, básicamente, una pantalla. Un servidor que gestionaba varios proyectos a la vez y desde el cual podía disparar tareas de un agente de código, con un tablero al medio que mostraba en qué etapa estaba cada cosa. Si me hubieran preguntado ese día cuál era el problema que estaba resolviendo, habría contestado sin dudar: ver y lanzar. Necesitaba un lugar desde donde disparar el trabajo y mirar cómo avanzaba. Cuatro meses después, con más de dos mil tareas cerradas por ese sistema, puedo decir que esa respuesta estaba equivocada, y que el primer indicio de por qué llegó a los tres días. Los dos primeros días fueron todos de interfaz Si miro el historial de esa primera semana, es casi cómico. El ancho del panel lateral. Los tooltips con las fechas completas al pasar el mouse. Los badges de "en progreso" sobre cada etapa. Los colores por etapa del pipeline, para que se distinguieran de un vistazo. Hay un par de commits consecutivos que me gusta especialmente como retrato de ese momento. El primero pone un emoji como ícono del botón de repetición. El segundo lo reemplaza por un carácter Unicode, porque el emoji ignoraba el color que le definía por CSS y se veía siempre igual, sin importar el estado. No lo cuento para burlarme de mí mismo. Lo cuento porque es exactamente cómo se ve un proyecto cuando todavía no sabés cuál es el problema. Estaba puliendo la superficie del sistema con mucho cuidado porque la superficie era lo único que tenía enfrente. La pregunta de fondo -qué parte de este flujo tiene que decidir un modelo y qué parte no- ni siquiera me la había hecho. El 10 de abril cambió el foco Para entonces el pipeline ya tenía forma: una cadena de pasos donde un agente elegía la próxima tarea pendiente, la implementaba y después la marcaba como terminada. Los tres pasos los hacía el modelo, porque los tres estaban escritos como instrucciones dentro de las habilidades que le pasaba. Y ahí apareció la primera pregunta incómoda: ¿por qué está eligiendo el modelo? Elegir la próxima tarea, cuando lo mirás de cerca, no tiene nada de ambiguo. Hay un índice de items. Cada uno tiene un estado y una lista de prerequisitos. La regla es: agarrá el primero que esté pendiente y tenga todos sus prerequisitos cumplidos, marcalo como en progreso y dejá constancia. Eso no es criterio, es un filtro. Es un if con un par de condiciones. Ese día lo convertí en un script determinista. Parsea el índice, encuentra el primer item pendiente con los prerequisitos en orden, lo marca en progreso y commitea el cambio. También contempla el caso de retomar un item que ya estaba empezado, que era la única parte con algo de sutileza. El mismo día hice lo propio con el otro extremo de la cadena. El paso de cerrar una tarea -cambiar el estado, recalcular los contadores del resumen, borrar el archivo de especificación y commitear- también dejó de pasar por el modelo. Es una secuencia de operaciones sobre archivos y estado. No hay nada que interpretar. Los números que anoté en ese momento Lo que hace que esto no sea una anécdota es que medí el antes y el después, y lo dejé escrito en los mensajes de esos commits. La selección automática costaba alrededor de 0,25 dólares y 40 segundos cada vez que corría. El cierre, alrededor de 0,30 dólares y 20 segundos. Como script, la selección pasó a ser el paso cero del pipeline: instantáneo y de costo cero, ejecutándose antes de que se levantara ningún agente. Poco menos de sesenta centavos y un minuto por tarea. Visto de a una, es despreciable. Ese es justamente el problema con este tipo de desperdicio: nunca duele lo suficiente como para que lo mires. Cuatro meses más tarde, el sistema lleva 2.095 funcionalidades y arreglos completados. A ese ritmo, esos dos scripts acumulan más de mil dólares y más de treinta horas de espera que nunca se pagaron. Y no porque el modelo hiciera mal su trabajo: lo hacía bien. Simplemente estaba haciendo un trabajo que no requería un modelo. El modelo se paga donde hay ambigüedad La conclusión que saqué de esos dos días la sigo usando como criterio para cada paso nuevo que agrego al pipeline. Un modelo se justifica donde hay que interpretar algo: entender una especificación escrita en prosa, decidir cómo estructurar un cambio, evaluar si un resultado es aceptable. Donde la regla se puede escribir, la regla gana. Y no gana solo por precio. Gana por tres motivos que pesan más a medida que el sistema crece: - Es más barato, que es lo obvio y lo menos importante. - Es más rápido: un script tarda milisegundos donde un agente tarda decenas de segundos, y esa diferencia se multiplica por cada tarea del backlog. - Es determinista, que es lo que realmente importa. Un pipeline que tiene que correr sin nadie mirando no puede tener pasos que a veces hagan una cosa y a veces otra. Cada punto donde interviene un modelo es un punto donde el resultado puede variar, y esa varianza se acumula a lo largo de la cadena. Dicho de otro modo: cada paso determinista que le sacás al agente no es solo ahorro, es una fuente de incertidumbre que eliminás del sistema. La telemetría fue lo que hizo posible verlo Hay un detalle sin el cual nada de esto habría pasado: para poder afirmar que un paso costaba veinticinco centavos, primero tuve que medirlo. Esa instrumentación -registrar el costo y la duración de cada paso, uno por uno- es de lo primero que construí, y hoy el sistema lleva 5.698 corridas de habilidades y 9.109 pasos registrados, cada uno con lo que costó y lo que tardó. Es la base sobre la que se apoyan casi todas las decisiones que voy a contar en esta serie. Sin esos números, el razonamiento de aquel 10 de abril habría sido una intuición más, del mismo tipo que las que después resultaron equivocadas. Con los números, fue una decisión de diez minutos. Lo que vino después Con el flujo ordenado y los pasos deterministas fuera del modelo, el pipeline empezó a producir a buen ritmo. Y ahí, casi de inmediato, apareció el problema que me iba a ocupar los cuatro meses siguientes y que todavía hoy no está del todo cerrado. El agente terminaba su corrida, informaba que había implementado lo pedido, y el sistema lo daba por terminado con un único criterio: que el paso anterior hubiera corrido sin error. Eso resultó insuficiente muy rápido. De eso se trata la próxima entrega: cómo saber si el agente hizo lo que dice que hizo. Top comments (0)