Un agente de IA casi nunca falla en el primer paso. Falla dos, tres o cuatro pasos después, cuando ya nadie está mirando la pantalla y el propio agente sigue encadenando el siguiente movimiento sobre la base de que el anterior salió bien. Esa es la pregunta que nos hacemos cada vez que un cliente quiere que un agente deje de solo responder y empiece a actuar dentro de su ERP o su CRM: no "qué puede hacer", sino "cuántos pasos le dejamos dar antes de obligarlo a parar y comprobar".
El problema no es el paso 1, es el paso 3
Cuando alguien prueba un agente de IA por primera vez, casi siempre lo hace con una tarea de un solo paso: "búscame este cliente", "dime el stock de este producto". Ahí el agente rinde bien casi siempre, porque un fallo se ve al momento y se corrige sin coste.
El problema aparece cuando el agente deja de responder y empieza a encadenar acciones sobre un sistema real: valida un dato, y con ese dato decide el siguiente paso, y con el resultado del siguiente decide el que viene después. Si el paso 2 se apoya en una lectura equivocada del paso 1, el error no se queda en el paso 2: viaja hasta el final de la cadena, y cuando alguien lo nota (si lo nota) ya hay un pedido, una factura o una oportunidad creada con un dato que nunca fue correcto.
Cuantos más pasos encadena un agente sin que nadie verifique el resultado intermedio, más lejos puede llegar un error antes de que alguien lo vea. No es una cuestión de que el modelo "razone peor" al quinto paso: es que nadie comprobó los cuatro anteriores.
El caso real: cinco pasos, cinco puntos de control
En el agente comercial que montamos para una distribuidora industrial con más de 50.000 productos, la IA cotiza por WhatsApp dentro de Odoo, y la cadena real tiene cinco pasos:
- Valida que el cliente que escribe existe y está identificado correctamente.
- Aplica la tarifa que le corresponde a ese cliente concreto (no una tarifa genérica).
- Comprueba el stock real del producto pedido.
- Crea la oportunidad comercial en el sistema.
- Genera el pedido.
Podríamos haber dejado que el agente hiciera los cinco pasos seguidos y solo mostrara el resultado final. No lo hicimos. Cada uno de esos cinco pasos tiene su propia verificación antes de dejar pasar al siguiente: si el cliente no se valida, no se aplica tarifa; si la tarifa no cuadra con el cliente, no se mira el stock; si el stock no alcanza, no se crea el pedido. El agente no avanza "porque parece que va bien": avanza porque cada paso concreto pasó su propia comprobación.
| Paso | Qué decide el agente | Qué lo verifica antes de continuar |
|---|---|---|
| 1. Validar cliente | Quién escribe y qué cuenta es | Coincidencia exacta con el registro del ERP |
| 2. Aplicar tarifa | Qué precio le corresponde | La tarifa vinculada a ese cliente, no una por defecto |
| 3. Comprobar stock | Si hay unidades suficientes | El stock real en el ERP en ese momento, no una caché |
| 4. Crear oportunidad | Si el pedido sigue adelante | Que los tres pasos anteriores pasaron su verificación |
| 5. Generar pedido | El pedido final que se envía | Que la oportunidad quedó creada con los datos correctos |
Por qué esto no es lo mismo que "vigilar si el agente falla"
Es fácil confundir esta idea con la de poner una alarma que avise si algo se rompe. Son cosas distintas. Una alarma detecta un fallo cuando ya ha pasado. Un punto de control impide que el fallo se propague al paso siguiente, porque no deja avanzar la cadena hasta que el paso actual queda confirmado.
La diferencia importa porque el coste de arreglar un error crece con cada paso que lo arrastra. Corregir un cliente mal identificado en el paso 1 cuesta una consulta más. Corregir un pedido ya creado con la tarifa equivocada en el paso 5 cuesta deshacer un pedido, avisar al cliente y, si ya salió mercancía, algo peor.
La regla de decisión
Después de montar varios agentes que escriben en sistemas reales (ERPs, CRMs, contabilidad), la regla que aplicamos es esta:
Un agente puede encadenar todos los pasos que haga falta, siempre que cada paso que escribe (no que lee) en un sistema real tenga su propia verificación explícita antes de dejar avanzar al siguiente. Si un paso solo lee y muestra información, un error se corrige preguntando otra vez. Si un paso escribe (crea, modifica o borra algo en un sistema real), ese paso necesita su propio "esto está bien, sigo" antes de continuar, no una suposición de que como el paso anterior salió bien, este también saldrá.
Dicho al revés, en forma de aviso: si tu agente encadena varios pasos que escriben en tu sistema y solo hay una comprobación al final de todo, no tienes cinco pasos verificados, tienes un paso verificado y cuatro a ciegas.
Checklist antes de dejar que un agente encadene pasos que escriben
- ¿Cada paso que escribe tiene una verificación propia, o solo se comprueba el resultado final?
- ¿Qué pasa si el paso 2 se apoya en un dato del paso 1 que resultó estar mal? ¿Se detiene la cadena o sigue adelante con el error dentro?
- ¿Hay algún paso donde, si falla, prefieres que el agente pare y pregunte a un humano en vez de decidir solo?
- ¿Puedes ver, después de que el agente termine, qué verificación pasó en cada paso, o solo ves el resultado final?
- ¿El coste de deshacer un error crece según en qué paso ocurrió? Si es así, los últimos pasos necesitan más control, no menos.
No es un problema de "cuántos pasos", es de cuántos sin control
La pregunta del titular no tiene una respuesta en número fijo de pasos ("hasta 3 va bien, a partir de 4 falla"), porque no depende de cuántos pasos hay, sino de cuántos de esos pasos escriben en un sistema real sin que nada los verifique antes de continuar. Un agente puede dar veinte pasos con seguridad si diecinueve solo leen y consultan, y el único que escribe tiene su verificación. Y puede descarrilar en el segundo si ese segundo paso ya escribe algo y nadie lo comprobó antes del tercero.
Es la misma disciplina que aplicamos en la plataforma de datos con IA que montamos para un grupo de farmacias, donde la IA no razona sobre un número sin que antes se haya validado al céntimo, y en el agente comercial dentro del ERP de esta distribuidora: primero se ordena qué puede fallar y dónde, después se deja que el agente actúe. Puedes ver cómo lo montamos, con más detalle técnico, en nuestros servicios de IA a medida.
Si estás evaluando dar permisos de escritura a un agente de IA en tu ERP, tu CRM o tu contabilidad, y no tienes claro cuántos de sus pasos tienen de verdad un punto de control, es la primera pregunta que respondemos en una conversación. Escríbenos y lo repasamos juntos.
