La automatización de siempre es una lista de instrucciones
Durante años, automatizar un proceso significó lo mismo: dibujar el flujo completo por adelantado. Un disparador, una serie de pasos fijos y una condición para cada bifurcación posible. Herramientas como Zapier o n8n hicieron esto accesible para mucha gente, pero la idea de fondo nunca cambió. Si el proceso tiene un caso que no previste, el flujo no lo resuelve: se rompe o lo ignora.
Ese modelo funciona bien cuando el proceso es estable y tiene pocas variantes. Empieza a fallar cuando el trabajo real es ambiguo, cambia seguido o depende del criterio de quien lo hace.
Un agente no sigue el flujo, decide el flujo
Con un agente el planteamiento se invierte. En vez de programar cada paso, le das tres cosas: un objetivo, un conjunto de herramientas que puede usar y el contexto para entender la situación. El agente arma el camino en el momento, según lo que va encontrando.
Un ejemplo sencillo. El proceso "responder la solicitud de un cliente", en un flujo tradicional, necesitaría una rama por cada tipo de solicitud, y aun así se quedaría corto tarde o temprano. Un agente con acceso al historial del cliente, al inventario y a la política de la empresa puede leer la solicitud, buscar lo que le falta y responder, sin que nadie haya anticipado esa combinación exacta.
La automatización clásica te obliga a prever cada caso. Un agente solo necesita saber qué puede hacer y por qué.
Lo que esto cambia en la práctica
El cambio no es solo técnico. Cambia qué vale la pena automatizar y cómo se le da mantenimiento.
- Procesos que antes quedaban fuera por ser "demasiado variables" ahora entran, porque el agente absorbe la variación en lugar de que tú la enumeres una por una.
- El mantenimiento se parece más a ajustar instrucciones y permisos que a reescribir diagramas cada vez que algo cambia.
- Aparece un riesgo nuevo. El agente puede tomar una decisión que no querías, así que el diseño se concentra en qué acciones se le permiten y en qué pasa cuando se equivoca.
Un caso propio, contado por encima
Uno de los sistemas que construí para un equipo interno, al que llamamos Synapse, es un buen ejemplo de este cambio. El equipo trabajaba con asistentes de IA por separado y el conocimiento se fragmentaba: decisiones ya tomadas se volvían a discutir y nadie tenía una visión clara de lo que había hecho el resto.
Synapse es una memoria compartida que cada persona consulta desde donde ya trabaja, sea el editor, la terminal o un chat. No es un flujo con pasos numerados. Alguien pregunta lo que necesita y el sistema responde con lo que a esa persona le corresponde ver según su rol, porque no toda la información de un proyecto es para todo el mundo. La parte difícil no fue conectar un modelo de lenguaje, fue decidir qué puede alcanzar cada quien y aplicarlo de una forma que el agente no pueda saltarse.
No voy a entrar en cómo está hecho por dentro. Lo que importa acá es la forma. En lugar de programar "cuando pase esto, haz esto otro", el sistema entiende una pregunta, decide qué buscar y devuelve una respuesta filtrada. Eso resolvió un problema que un flujo fijo no podía tocar.
Cuándo conviene y cuándo no
Un agente no reemplaza a la automatización tradicional en todos los casos. Si el proceso es fijo, predecible y crítico, un flujo explícito sigue siendo más fácil de entender y de auditar. Los agentes ganan terreno cuando el proceso tiene demasiadas variantes para escribirlas todas, cuando el contexto pesa más que los pasos o cuando el trabajo cambia lo suficiente como para que mantener el diagrama cueste más que el proceso mismo.
La pregunta útil antes de construir uno no es si suena moderno. Es qué decisión concreta le estás delegando y qué quieres que pase si esa decisión sale mal.