Hay una conversación que se repite en proyectos de automatización: el cliente llega convencido de que necesita un agente IA, y cuando se mapea el proceso resulta ser una secuencia lineal de cuatro pasos que no cambia nunca. Un script de Python con dos llamadas a API resuelve lo mismo en una semana, a una fracción del costo.
Esto no es un argumento contra los agentes. Es un argumento a favor de elegir la herramienta correcta para el problema correcto.
El error de categoría que cuesta caro
Cuando alguien dice “quiero un agente IA para automatizar X”, lo primero que hay que preguntar no es qué modelo usar ni qué framework. La pregunta es: ¿el proceso tiene decisiones reales o solo tiene pasos?
Un proceso con pasos es: recibir una orden de compra, validar que el proveedor existe en el ERP, generar la factura, enviarla por correo. Siempre igual. Sin excepciones relevantes. Ahí un script con Zapier, Make, o código directo hace el trabajo sin necesidad de un LLM en el medio.
Un proceso con decisiones es: recibir una solicitud de cotización, determinar si el cliente es nuevo o recurrente, ajustar el descuento según historial, redactar la propuesta con el tono adecuado para ese segmento, y escalar si el monto supera cierto umbral que varía por industria. Ahí la lógica fija se rompe rápido y un agente empieza a tener sentido.
El error de categoría ocurre cuando se mete un agente en el primer tipo de proceso porque “suena más moderno”. El resultado es infraestructura cara, latencia innecesaria y un punto de falla adicional sin beneficio real.
Tres señales de que un script es suficiente
No hay una fórmula universal, pero hay patrones que en Eurema usamos para decidir antes de proponer cualquier arquitectura:
1. El proceso tiene menos de 3 bifurcaciones reales. Si puedes dibujar el flujo completo en un papel y no aparecen más de dos o tres “si esto, entonces aquello”, un script lo maneja sin problema. Las bifurcaciones que importan son las que dependen de datos variables, no de configuración estática.
2. Los datos de entrada son estructurados. Formularios, filas de una hoja de cálculo, campos de un CRM: todo eso es terreno de script. Cuando la entrada es un correo en lenguaje natural, un PDF de contrato escaneado, o una conversación de WhatsApp, ahí el procesamiento de lenguaje empieza a aportar valor real.
3. El proceso no cambia más de una vez por trimestre. Los agentes IA son útiles cuando la lógica necesita adaptarse con frecuencia. Si tus reglas de negocio llevan dos años iguales y no hay razón para que cambien, codificarlas directamente es más robusto y más barato de mantener.
Una manufactura mediana en Nuevo León, por ejemplo, puede automatizar perfectamente el reporte semanal de inventario crítico con un script que consulta el ERP, filtra por umbral y envía el correo al equipo de compras. No necesita un agente. Necesita que alguien lo construya bien y lo documente.
Cuándo el agente sí justifica su costo
El umbral cambia cuando el proceso combina varias de estas condiciones al mismo tiempo:
- Datos no estructurados como entrada principal (correos, documentos, voz).
- Criterio de decisión variable según contexto que no se puede codificar como reglas fijas.
- Múltiples herramientas externas que el proceso necesita consultar o ejecutar según el caso.
- Volumen suficiente para que el costo de API se distribuya. Un agente que procesa 5 solicitudes al mes es difícil de justificar económicamente.
Un caso concreto: una empresa de servicios profesionales que recibe solicitudes de propuesta por correo desde distintos sectores. Cada solicitud requiere leer el documento adjunto, identificar el tipo de proyecto, asignarle un consultor con disponibilidad y experiencia relevante, y redactar una respuesta inicial personalizada. Eso no se resuelve con un script razonable — hay demasiadas variables no estructuradas. Ahí un agente con acceso al calendario, al CRM y al modelo de lenguaje tiene ROI claro.
El criterio que usamos en Eurema para decidir es directo: si la lógica cabe en un diagrama de flujo de una página, empieza con un script. Si el diagrama necesita una segunda página solo para los casos de excepción, empieza a evaluar un agente.
El costo real de equivocarse en la dirección contraria
Usar un agente donde bastaba un script tiene consecuencias concretas:
- Latencia: una llamada a un LLM tarda entre 2 y 15 segundos. Un script local tarda milisegundos. Para procesos de alta frecuencia, eso importa.
- Costo por ejecución: los tokens no son gratis. Un proceso que corre 500 veces al día con un modelo como GPT-4o puede generar costos de API de 300–800 USD mensuales que no existirían con lógica determinista.
- Debugging más difícil: cuando un script falla, el error es rastreable. Cuando un agente produce un resultado inesperado, entender por qué requiere más instrumentación.
- Dependencia externa: un script propio no depende de que OpenAI, Anthropic o Google estén disponibles en ese momento.
Ninguno de estos puntos significa que los agentes son malos. Significa que tienen un perfil de costo-beneficio distinto al de un script, y usarlos fuera de ese perfil es simplemente mala ingeniería.
El camino que tiene más sentido en la práctica
La secuencia que funciona mejor no es “elegir entre script o agente desde el inicio”. Es empezar con el script, operar con él durante 4–8 semanas, y observar dónde falla la lógica fija.
Esos puntos de falla son los datos de diseño que necesitas para construir un agente útil. Si el script nunca falla porque el proceso es estable, acabas de ahorrarte un proyecto de IA innecesario. Si falla consistentemente en los mismos puntos, tienes evidencia concreta de dónde un agente agrega valor real.
En proyectos de Agentes personalizados en Eurema, el punto de partida casi siempre incluye auditar si ya existe automatización previa — aunque sea manual o en hojas de cálculo — antes de proponer arquitectura. El historial de excepciones es más valioso que cualquier suposición inicial sobre la complejidad del proceso.
Si estás evaluando automatizar un proceso y no sabes por dónde empezar, el primer paso es mapearlo con suficiente detalle como para contar las bifurcaciones reales. Eso solo ya te dice bastante sobre qué herramienta tiene sentido.