Agentes de IA en la entrega: dónde pagan y dónde no

"Agente de IA" se volvió un término paraguas para cosas muy distintas, y esa imprecisión cuesta dinero. Los equipos montan orquestaciones complejas para problemas que un flujo fijo resolvería mejor, más barato y con menos probabilidad de fallar de madrugada.

Un workflow y un agente no son lo mismo

La distinción que Anthropic propone en su trabajo sobre ingeniería de agentes es la más útil disponible hoy:

• Workflow: el LLM corre dentro de caminos de código predefinidos. Tú decides la secuencia; el modelo completa los pasos.
• Agente: el LLM dirige su propio camino, elige las herramientas y decide cuándo terminó.

Los workflows son predecibles, baratos de depurar y fáciles de probar. Los agentes son flexibles y caros, en tokens, en latencia y en lo difícil que es investigarlos cuando salen mal.

La recomendación que acompaña a la distinción es directa: usa lo más simple que funcione, y agrega autonomía solo cuando el problema realmente lo exija.

Empieza por el workflow, casi siempre

Buena parte de las tareas de entrega de software tiene una secuencia conocida. Generar release notes a partir de commits, clasificar y enrutar un ticket, actualizar un changelog, traducir documentación. Nada de eso necesita un agente eligiendo estrategia: necesita un encadenamiento con validación entre pasos.

La regla práctica: si puedes dibujar el diagrama de flujo de antemano, es un workflow. Si el camino depende de lo que se descubra sobre la marcha, entonces sí es candidato a agente.

Los patrones que aparecen de verdad

Cuatro se repiten en prácticamente todo proyecto serio:

1. Encadenamiento. La salida de una llamada es la entrada de la siguiente, con una verificación programática entre ellas. Esa verificación es lo que impide que el error se propague.
2. Enrutamiento. Una llamada barata clasifica, y cada clase va a un prompt o modelo especializado. Ahorra dinero y mejora la calidad a la vez.
3. Paralelización. Correr el mismo análisis desde ángulos distintos y agregar, o dividir trabajo independiente. Baja la latencia percibida.
4. Evaluador y optimizador. Uno genera, otro critica según criterios explícitos, iterando algunas veces. Funciona bien cuando hay criterio objetivo, y se vuelve un bucle infinito caro cuando no lo hay.

Las herramientas son la parte que decide el resultado

Un agente es tan bueno como las herramientas que le das y qué tan bien están descritas. Una herramienta mal nombrada, con un parámetro ambiguo o un mensaje de error inútil, produce un agente que intenta lo mismo cinco veces.

Conviene tratar la definición de herramientas con el cuidado de una API pública: nombres que dicen lo que hacen, parámetros con tipo y descripción, errores que explican cómo corregir. El Model Context Protocol estandariza justamente esa capa de conexión entre aplicación, contexto y herramientas, lo que reduce el acoplamiento entre tu agente y un proveedor específico.

Qué dicen los benchmarks sobre la realidad

Conviene calibrar expectativas con SWE-bench, que evalúa modelos sobre issues reales de repositorios reales en vez de ejercicios sintéticos. Cuando se publicó, expuso una distancia grande entre el desempeño en tareas de demostración y el desempeño en código de producción con historia, dependencias y contexto implícito.

Los números mejoraron bastante desde entonces, pero la lección estructural se mantiene: la tarea bien delimitada y verificable va bien; la tarea que exige entender la intención detrás de un sistema entero va mal. Eso debería guiar dónde apuntas primero un agente.

Dónde paga un agente en el ciclo de entrega

Los casos con mejor relación entre riesgo y retorno comparten tres rasgos: resultado verificable por máquina, alcance limitado y bajo costo de equivocarse.

Migraciones mecánicas repetitivas con pruebas que cubren el comportamiento. Triaje de fallos en CI, correlacionando logs y commits. Generación de pruebas para código legado sin cobertura, con la prueba pasando como criterio objetivo. Investigación de dependencias vulnerables, con la actualización propuesta validada por la suite.

Lo que no paga hoy: dejar que un agente abra PRs directo a producción sin revisión, o que toque solo el código central sin cobertura de pruebas.

Qué significa esto para tu equipo

Elige una tarea repetitiva con criterio de éxito verificable por máquina e impleméntala primero como workflow. Mide tiempo ahorrado y tasa de acierto durante dos o tres semanas.

Promuévela a agente solo si el flujo fijo está fallando porque no logra anticipar los caminos. Y antes de eso, invierte en las herramientas y en el logging: sin rastro de qué herramienta se llamó, con qué argumentos y con qué resultado, no vas a poder depurar ni mejorar nada.