Automatizar vs agentizar: no le pongas un agente a lo que resuelve un script

Hay una pregunta que casi nadie se hace antes de meter un agente de IA en un flujo de trabajo: ¿esto realmente necesita razonar, o solo necesita ejecutarse? La mayoría de las veces la respuesta es la segunda, y sin embargo terminamos armando un agente con prompt, herramientas, memoria y reintentos para un problema que un script determinístico resolvía en minutos.

No es un problema técnico, es un problema de sobrepensar. Cuanto más de moda está una tecnología, más ganas dan de usarla para todo, incluso para lo que no la necesita.

Automatizar no es agentizar

Automatizar es codificar un proceso conocido: pasos fijos, reglas claras, un input que se transforma en un output siempre de la misma manera. Un cron que corre un backup, un script que renombra archivos, una integración que mueve datos de un sistema a otro. No hay ambigüedad que resolver, solo trabajo repetitivo que un programa puede hacer mejor que una persona.

Agentizar es otra cosa. Es delegarle a un modelo la parte que no se puede escribir como una secuencia fija de pasos: interpretar una instrucción ambigua, decidir entre varios caminos posibles, adaptarse a un input que cambia de forma. Un agente tiene sentido cuando el problema en sí requiere juicio, no cuando solo requiere repetición.

La confusión entre las dos cosas es donde arrancan los problemas.

El sobrepensar como patrón

Vi este patrón una y otra vez, en distintas formas:

• Un flujo de aprobación con tres reglas fijas (“si el monto es menor a X, aprobar; si no, escalar”) armado como agente conversacional con function calling, cuando un if lo resolvía.
• Un pipeline de renombrado y clasificación de archivos con criterios claros, envuelto en un agente con memoria y razonamiento, cuando una función pura con un par de reglas de negocio era suficiente.
• Integraciones entre APIs con contratos estables, tercerizadas a un agente que “decide” cómo mapear los campos en cada corrida, en vez de una transformación fija que se define una sola vez y no cambia.

En todos los casos el resultado es el mismo: más latencia, más costo, más superficie de falla y, lo más irónico, menos previsibilidad que la versión simple. Un script hace lo mismo todas las veces. Un agente, no necesariamente.

Por qué pasa

Agentizar de más rara vez es una decisión técnica. Suele ser una mezcla de cosas:

• Novedad. Los agentes son la herramienta del momento, y usar la herramienta de moda se siente como progreso aunque no lo sea.
• Miedo a subestimar la complejidad futura. “¿Y si mañana el proceso cambia?” es una pregunta legítima, pero diseñar hoy para un problema que no existe todavía es la definición de sobreingeniería.
• Evitar pensar el problema a fondo. Es más fácil escribirle un prompt largo a un modelo y esperar que resuelva la ambigüedad, que sentarse a definir las reglas reales del proceso. El agente termina tapando un análisis que no se hizo.

Ese último punto es el más caro. Cuando no entendiste bien el problema, un agente no te salva: solo esconde la falta de entendimiento detrás de una capa de razonamiento que parece funcionar hasta que falla de una forma que no podés explicar.

Cuándo automatizar

• El proceso tiene reglas conocidas y estables.
• El input tiene una forma predecible, aunque varíe en los valores.
• Necesitás que el resultado sea el mismo cada vez que corre.
• El costo de un error silencioso es alto y preferís que falle ruidosamente antes que “interprete” mal.

Cuándo agentizar

• El input es genuinamente ambiguo o no estructurado (lenguaje natural libre, documentos heterogéneos, instrucciones que cambian de forma).
• Las reglas del proceso no se pueden enumerar de antemano, o cambian con más frecuencia de la que se pueden mantener a mano.
• El valor está justamente en el juicio: priorizar, resumir, decidir entre opciones con criterios blandos.
• Podés tolerar (y auditar) cierta variabilidad en el resultado.

La regla práctica

Si podés escribir el proceso como un diagrama de flujo con condiciones fijas, escribilo como código. Si no podés, ahí es donde un agente empieza a tener sentido, y ni siquiera ahí conviene dejarlo suelto sin límites: la ingeniería de arneses (herramientas acotadas, permisos claros, puntos de confirmación) sigue aplicando igual.

Menos ruedos no significa menos tecnología. Significa elegir la pieza que el problema realmente pide, y no la que más entusiasmo genera esta semana.