Le estás pagando a un modelo para que haga de if

Hay una pregunta barata que casi nadie se hace antes de sumar un agente a un flujo de trabajo: de todo lo que le voy a pedir, ¿cuánto son decisiones y cuánto son reglas?

Elegir la próxima tarea de una lista según sus prerequisitos no es una decisión: es una regla. Marcar esa tarea como terminada y recalcular los contadores, tampoco. Eran las dos cosas que le estaba pidiendo a un modelo cuando armé mi orquestador de agentes, y las dos salieron del agente a los tres días de arrancar.

Lo que anoté en los commits de ese momento: unos 0,25 dólares y 40 segundos por corrida en la selección, unos 0,30 y 20 segundos en el cierre. Suena a nada. Cuatro meses y 2.095 tareas después, esos dos scripts acumulan más de mil dólares y más de treinta horas que nunca se gastaron.

Y el punto que importa si estás armando algo parecido: el ahorro no vino de elegir un modelo más barato ni de escribir mejores prompts. Vino de achicar la superficie que le toca al modelo.

Los dos primeros días fueron todos de interfaz

Arranqué el 7 de abril de 2026, y lo primero que construí no fue nada de eso: fue una pantalla. Un servidor que gestionaba varios proyectos a la vez, con un tablero al medio mostrando en qué etapa estaba cada cosa. 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.

Dos pasos que pasaron a ser scripts

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.

La pregunta incómoda llegó mirando el primero de los tres. Hay un índice de items, cada uno con un estado y una lista de prerequisitos, y la regla completa es: agarrá el primero que esté pendiente y tenga todos sus prerequisitos cumplidos, marcalo como en progreso y dejá constancia.

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.

Dónde están los tuyos

El ejercicio no requiere construir nada: listá los pasos de tu flujo y marcá los que tienen una única respuesta correcta dada la entrada. Elegir el próximo item, mover un estado, recalcular un contador, comprobar si los prerequisitos están dados. Cada uno de esos que hoy resuelve un modelo lo estás pagando dos veces —en tokens y en varianza— para obtener algo que un condicional devuelve siempre igual.

Con los pasos deterministas afuera, el pipeline empezó a producir a buen ritmo, y apareció el problema inverso, que me ocupó los cuatro meses siguientes: el agente terminaba, informaba que había implementado lo pedido, y el único criterio para creerle era que el paso no hubiera devuelto error. De eso trata la próxima entrega.