Antes de conectar un agente a su ERP hay que decidir dos cosas: qué se le permite tocar y en qué orden. Los escalones son tres, leer, avisar y ejecutar, y cada uno le ahorra más y le puede costar más. Detrás de lo que sigue hay cuatro sistemas nuestros funcionando: uno en uso público, dos en producción y uno en despliegue.
Qué se le permite tocar en cada escalón
Tres preguntas separan un escalón del siguiente, y ninguna es sobre el modelo.
Quién lo arranca. El primer agente arranca cuando usted le pregunta algo. El segundo y el tercero arrancan solos: un reloj, o un mensaje que entra.
Qué deja detrás. El primero deja una respuesta. El segundo deja un aviso, dirigido a quien lleva esa cuenta o ese turno. El tercero deja el trabajo hecho.
Cuánto mide su lista de acciones permitidas. La del primero es una lista corta que la empresa escribió de antemano, o ninguna. La del segundo tiene un solo elemento: abre la incidencia y se para. La del tercero es el trabajo entero menos el último paso. A cada uno se le permite una cosa más que al anterior, y en los tres casos alguien escribió la lista antes de que el agente se ejecutara.
| arranca | deja detrás | permite | |
|---|---|---|---|
| Leer | usted pregunta | una respuesta | lista corta o nada |
| Avisar | un reloj | un aviso | abrir la incidencia |
| Ejecutar | reloj o mensaje | el trabajo hecho | todo menos el último paso |
Esa es la diferencia entera. Un sistema real puede llevar más de uno de esos tres permisos, y así lo hacen tres de los cuatro nuestros. Eso es lo que enseña la tabla de los cuatro sistemas, más abajo, y de ahí sale también el orden en que conviene concederlos.
Cómo se escribe lo que la IA sabe de una empresa es otro texto. Este va de lo siguiente: qué se le permite hacer una vez lo sabe.
Leer: el agente contesta y no toca nada
Un agente de consulta contesta preguntas sobre una empresa con los datos de esa empresa delante. Ese es el trabajo entero, y lo interesante está en qué significa «delante»: está conectado al ERP y al resto de sistemas en tiempo real, así que la pregunta se contesta contra el sitio donde vive el dato y no contra un documento que alguien escribió hace meses.
Eso cambia qué se le puede preguntar. Un modelo de propósito general contesta bien a lo que se sabe del mundo, y no puede contestar a nada que dependa de sus clientes, de su catálogo o de su almacén, porque no los ha visto nunca.
La cartera B2B lleva uno dentro del panel: contesta en lenguaje natural con las mismas cifras que muestran las pantallas, y cada respuesta enseña de dónde sale cada número.
Es la clase que todo el mundo ha visto en una demostración, y la que, en estado puro, no cambia nada y por eso no necesita permiso de nadie. También carga el límite que más importa: no hace nada hasta que alguien pregunta. Si nadie pregunta por el pedido que se ha quedado atascado, el pedido sigue atascado.
El nuestro funciona en una tienda especializada y está abierto a cualquier visitante en la web de la propia tienda, sin registro. Su límite publicado dice: «El agente opera dentro de la tienda. Responde de sus productos y condiciones y lanza únicamente los procedimientos definidos por la empresa.»
Para qué se usa un agente que solo lee
Un agente de consulta sirve para dos públicos distintos, y conviene no confundirlos. Hacia dentro, el de la cartera B2B contesta a quien lleva la operación, que son las dos conversaciones de estas figuras: preguntas que cruzan varios sistemas y que nadie puede responder de memoria.
Hacia fuera, en nuestro caso público, contesta a cualquier visitante de una tienda especializada: condiciones, plazos, garantías y estado de un pedido; localiza y enseña el catálogo sin mandar a nadie a un buscador; y resuelve compatibilidades, que la ficha del caso llama la pregunta típica de ese sector.
Hace una cuarta cosa que ya no es contestar, y es la razón por la que este agente no es la primera clase en estado puro: inicia una devolución. Eso es un procedimiento lanzado dentro de los sistemas de la propia empresa, conectado con su ERP, y la tienda decidió de antemano qué procedimientos puede lanzar.
Así que este sistema es dos clases a la vez: responde, y se le ha permitido una acción. Otros dos de los nuestros también apilan clases; el del almacén, en cambio, solo avisa. La tabla de los cuatro sistemas, más abajo, los pone uno al lado de otro.
Quién calcula la cifra, el código o el modelo
La objeción obvia a un agente de consulta es que el modelo se invente el número. Tiene respuesta comprobable, y lo que la da es dónde está escrita la aritmética.
En el panel de la cartera B2B, que es el sistema que hemos medido, la aritmética está fuera del modelo. Lo contamos el 29 de agosto de 2026 sobre el código que dibuja ese panel, entendiendo por operación cada agregación que produce una cifra de las que se ven en pantalla: 87 operaciones, y ninguna que hable con un modelo.
Y hay una comprobación que puede hacer usted mismo, sin abrir nuestro código.
Cada respuesta enseña de dónde sale cada número. La tabla y el gráfico salen de esas operaciones, y el texto que los acompaña lo redacta el modelo, así que la cifra que manda es la de la tabla. Compararla con el texto lo puede hacer cualquiera en la propia pantalla.
Avisar: el agente vigila y no mueve nada
Un agente de supervisión no espera la pregunta. Comprueba una condición cada cierto tiempo y, cuando se cumple, avisa a quien lleva esa cuenta o ese turno.
La condición es el producto entero, y no se compra hecha. En la cartera B2B de un fabricante, el ritmo de compra es el propio de cada cliente y se mide sobre sus dos últimos años. Cuando una cuenta lleva el doble de su ritmo sin pedir, salta el aviso, priorizado por importe.
La aritmética es lo bastante pequeña para escribirla. Tome un cliente cuyos pedidos de dos años se espacian unos 18 días: el aviso de esa cuenta espera al día 36. Tome otro que pide cada 90 días: la misma regla espera al día 180, y el día 36 no dice nada. Esos dos números están puestos a modo de ejemplo; la regla por la que pasan es la publicada.
No hay un número único que signifique «este cliente se está yendo». Un cliente que pide cada semana y otro que pide dos veces al año están los dos sanos, y los dos están en problemas en puntos completamente distintos del calendario. El umbral tiene que ser personal.
Personal significa calculado con el historial de cada cuenta y recalculado a medida que ese historial se mueve.
En la misma pasada nocturna, cada cliente recibe además una puntuación de salud de 0 a 100 con sus razones: recencia, frecuencia, importe, tendencia y regularidad. Se congela una foto mensual, para que la puntuación se lea como una trayectoria.
La cartera además responde: el agente de consulta descrito más arriba vive dentro de este de supervisión, en el mismo panel.
La ficha del caso publica el tamaño de lo vigilado: más de 14 millones de líneas de venta y 840.000 perfiles recalculados al mes. Esa es la superficie que se repasa cada noche. Y lo que sale de repasarla es el aviso: llega al vendedor con el cliente, el motivo y el importe ya preparados, antes de que nadie lo pida.
Para qué se usa un agente que solo avisa
En el almacén es la misma idea apuntando a otro objeto. De serie vienen veinticuatro reglas, que se ejecutan sobre los datos del almacén en tiempo real. Cuatro están nombradas públicamente: órdenes retenidas, picking abandonado, reposiciones abiertas y órdenes que constan en el ERP y nunca llegaron al almacén. La figura de arriba enseña una quinta, la de ubicaciones que no cuadran.
La última es la interesante, y ninguno de los dos sistemas está equivocado por separado. El ERP tiene razón en que la orden existe. El sistema de gestión del almacén tiene razón en que no tiene nada que hacer. La orden solo aparece perdida cuando alguien pone los dos al lado.
Antes de que entre el turno no lo hace nadie. El agente lo hace sin descanso, y cada incidencia que abre trae la lista exacta de órdenes afectadas, con su ficha y la opción de exportarla. La detección la hacen los datos; la redacción la hace el modelo, para quien tenga que leerla. El aviso queda registrado en el sistema del almacén y va dirigido al jefe de turno, que es quien decide qué hacer con él.
También vigila el transporte, que es donde el mismo truco se complica: agencias que tardan en recoger, envíos parados o perdidos, destinos fuera de su plazo habitual, devoluciones por encima de lo normal. Y separa lo que se pausó a propósito de lo que va retrasado de verdad, que es la diferencia entre un aviso útil y un ruido que la gente aprende a ignorar.
El límite está publicado y es estricto: «Los agentes detectan, explican y avisan. No mueven una orden ni cambian una prioridad: eso queda en manos del almacén.»
Los umbrales de esas veinticuatro reglas salen de medir los datos de cada almacén, así que son distintos en cada instalación y no hay un número único que imprimir.
Ejecutar: el agente hace el trabajo y se para donde está escrito
Un agente de ejecución hace el trabajo. Lee el correo, monta el expediente, prepara la respuesta. Y se detiene donde le han dicho que se detenga, que en casi todos los asuntos es antes de firmar.
Conviene separarlo de las dos cosas con las que se confunde, porque las tres se venden con las mismas palabras.
Un copiloto sugiere. Redacta, completa, propone, y el trabajo lo sigue haciendo usted. Su límite es que nunca actúa.
El RPA repite. Reproduce una secuencia fija de clics y campos. Es rápido y es barato, y se rompe el día que una pantalla se mueve o un formulario gana un campo, porque reconoce formas y no significados.
Un agente de ejecución hace el trabajo y se para donde una regla escrita le dice que se pare, no donde se le acaba la capacidad. En casi todos los asuntos ese punto es la firma. En los que la empresa ha subido al nivel más alto, la parada se mueve detrás del envío: la respuesta sale y se verifica después. Lo que no se mueve nunca es que el punto esté escrito de antemano.
La diferencia con el copiloto no es de potencia: es de dónde está el límite, y de que el límite esté escrito antes de que nadie compre nada.
Lo que lo gobierna es el nivel de autonomía, y el nivel es del tipo de asunto, no del agente. En el más bajo, el agente deja un borrador sugerido y una persona lo lee y lo envía. En el más alto, la respuesta sale sin pasar por nadie y se verifica después. Y la regla que mueve entre esos dos extremos es asimétrica: los niveles únicamente suben con aprobación, y bajarlos no requiere ninguna.
Esa asimetría es lo que conviene exigir a cualquiera. Una subida automática es como un sistema acaba enviando algo que nadie acordó que pudiera enviar. Una bajada automática es como se para antes de que llegue la reclamación.
Dos condiciones pasan siempre por una persona, diga lo que diga el nivel: un tono negativo y cualquier mención legal.
Para qué se usa un agente que ejecuta
Un minuto, tal como lo publica la ficha del caso. Un correo en italiano que pregunta por un pedido entra a las 9:12. En ese mismo minuto el expediente está montado: ficha, pedido y seguimiento. A las 9:13 la respuesta está preparada, en italiano. Y a las 9:13 el compromiso de entrega que va dentro de esa respuesta ya se está vigilando contra el transportista.
La última línea es la fácil de saltarse. El agente leyó su propio borrador, encontró la fecha que acababa de prometer y puso esa promesa bajo vigilancia. Si el envío se retrasa, el cliente sabe de nosotros antes de que se le ocurra reclamar. Eso es el trabajo de un agente de supervisión hecho dentro de la acción de uno de ejecución, que es lo que significa «las clases se apilan» cuando deja de ser un diagrama.
Nada de eso es la parte difícil. Antes, el correo había que entenderlo: filtrar publicidad y respuestas automáticas, detectar el idioma, traducir, resumir en dos líneas y clasificar intención y urgencia. Después identificar al cliente y sacar directamente del ERP los pedidos, envíos e importes que el mensaje citaba. Quien abre ese caso lo abre con la ficha, el pedido y el seguimiento ya delante.
Y ahí se para, que en este asunto es antes de enviar.
Dónde se para cada agente, y a qué se conecta
| sistema | contesta | avisa | ejecuta |
|---|---|---|---|
| Asistente de tienda (en uso público) | sí | no | solo lo que la tienda definió |
| Cartera B2B (en producción) | sí | sí | no |
| Almacén (en producción) | no | sí | no |
| Buzón de soporte (en despliegue) | sí | sí | con nivel por asunto |
Un agente de ejecución lleva dentro uno de consulta, y uno de supervisión en cuanto el trabajo se lo pide. Por eso el tercero es también el más fácil de fingir: por fuera, una demostración del primero parece la misma.
La otra mitad de la pregunta es de fontanería, y cada ficha publica la suya. Es lo que decide si esto se puede montar en una empresa concreta.
- El asistente de la tienda lee el catálogo, el ERP y los procedimientos de gestión, devoluciones incluidas.
- La cartera B2B lee el ERP en réplica de solo lectura, el comercio electrónico B2B, el sistema de gestión del almacén y el correo de la empresa.
- El almacén lee su sistema de gestión en tiempo real, el ERP, los datos de las agencias de transporte y los datos maestros comerciales.
- El buzón de soporte lee el correo, el ERP y el comercio electrónico mediante conector, y el seguimiento de los transportistas.
Dos de esas cuatro conexiones valen más que el resto. La cartera lee una réplica de solo lectura: el agente que vigila 14 millones de líneas no puede escribir en el ERP aunque se lo pidan, porque no está mirando el ERP. Y el almacén lee su sistema de gestión en tiempo real, que es lo que permite que un aviso de las siete de la mañana sea de las siete de la mañana y no del cierre de ayer.
Cuánto tarda esa conexión depende del sistema que haya al otro lado, y es de las primeras cosas que se concretan en una conversación.
Por dónde se empieza, y por qué se empieza leyendo
Vuelva un momento a la tabla de arriba. Solo dos de los cuatro sistemas ejecutan algo, y no lo hacen igual.
El buzón de soporte ejecuta con nivel de autonomía por tipo de asunto. Esa es la forma abierta, y es el último de los cuatro en llegar a producción: exactamente el orden que recomendamos. El asistente de la tienda ejecuta en uso público, pero solo las gestiones que la tienda definió de antemano: una lista cerrada, escrita antes de encenderlo.
En nuestros cuatro sistemas el patrón es el mismo: la ejecución abierta es lo único que aún no está en producción, y la que sí está en uso público está vallada. Cada escalón añade algo que hay que acordar antes de encenderlo: leer necesita una conexión, avisar necesita además un umbral que alguien acepte como suyo, y ejecutar necesita una regla escrita que diga dónde se para y quién responde de lo que salga.
Lo primero se resuelve con un permiso de lectura. Lo último no se resuelve con ningún permiso.
Por eso empezamos leyendo, y lo que decide por dónde es de qué sistema se puede leer hoy. Con la lectura funcionando aparece el primer umbral, y casi nunca es el que se había imaginado en una reunión. Y cuando los avisos llevan tiempo siendo ciertos, ya se sabe sobre qué se ejecutaría, que es la información que no se tiene el primer día.
Saltarse escalones tiene un coste concreto. Un agente que ejecuta sobre un umbral que nadie ha comprobado hace trabajo de verdad sobre casos equivocados, y lo hace deprisa. Una réplica de solo lectura no comprueba el umbral: quita la pregunta, porque un agente que no puede escribir no puede actuar sobre un umbral malo. Es el escalón convertido en fontanería, donde ya no depende de que nadie se acuerde.
La lista que puede sacar esta tarde
No hace falta comprar nada para saber si un agente de supervisión le serviría. La regla de la cartera se ejecuta a mano una vez, contra su propio ERP, y lo que sale es exactamente el aviso que el agente daría mañana.
Saque los pedidos de sus clientes de los dos últimos años. Para cada cliente, los días que suelen pasar entre un pedido y el siguiente: la mediana, que aguanta mejor un pedido raro, no la media. Después, los días que lleva desde el último. Los que pasen del doble de su propio ritmo son la lista, y los que además tengan un cobro vencido van los primeros.
Cualquiera que sepa sacar un listado de su ERP lo tiene en una tarde, y no hace falta que sea usted.
Dos lecturas del resultado. Si aparecen nombres que no esperaba, acaba de ver dinero yéndose sin que nadie lo mirara. Y si la lista sale vacía o llena de ruido, también ha aprendido algo: su negocio no compra a ritmo, y esta regla no es la suya.
Lo que esa tarde no le da: una vigilancia. Le da una foto. No se vuelve a ejecutar esta noche, no ordena la lista por importe y no sabe cuáles de esos nombres llevan además un cobro vencido. Esa es la distancia entre un listado sacado a mano y un agente de supervisión, medida dentro de su propia empresa.
Cuándo no le hace falta un agente de supervisión
Tres casos en los que un agente de supervisión no le va a dar nada.
Si su venta va por proyectos y no por reposición. El ritmo de compra no existe cuando cada pedido es un contrato distinto. La regla dispara sobre ruido, la gente aprende a ignorar los avisos, y eso es peor que no tenerlos.
Si su cartera cabe en la cabeza de una persona. Con treinta cuentas y un comercial que las conoce, nadie necesita que un sistema le diga quién lleva tiempo sin pedir. Esto empieza a valer cuando la cartera ya no cabe en la memoria de una persona.
Si sus pedidos viven en hojas de cálculo y en correos. No hay a qué conectarse. Lo primero no sería un agente: sería poner el pedido en un sitio del que se pueda leer.
Cómo se llama esto fuera de aquí
Estas tres clases no son un vocabulario nuestro. Son un corte distinto sobre uno que ya existe, y conviene tener las equivalencias delante antes de sentarse a comparar proveedores.
El corte más citado entre quienes construyen estos sistemas es el de Anthropic, que separa flujos de trabajo, donde el modelo y sus herramientas se orquestan por rutas escritas de antemano, de agentes, donde el modelo dirige su propio proceso. Su criterio no es cuántas acciones tenga permitidas, sino quién dirige el proceso. Por ahí, las dos primeras clases de aquí son flujos de trabajo. La tercera queda en la frontera: el modelo decide qué mirar y qué preparar, pero no decide qué se le permite hacer, porque eso estaba escrito antes de que se ejecutara.
Quien tiene que firmar el riesgo usa otro eje, el de niveles de autonomía. Una propuesta publicada en el blog de la Cloud Security Alliance plantea una escala de seis, de L0 a L5, en la que en L0 la IA informa y la persona actúa. Por ese eje, leer y avisar caen las dos en L0. Solo la tercera sube, y hasta dónde depende del tipo de asunto.
La tercera tiene nombre propio en el sector desde hace años: human in the loop, con el punto donde se detiene llamado puerta de aprobación. Cuando le ofrezcan «el agente prepara y usted aprueba», le están ofreciendo eso, y la pregunta útil es dónde está escrita esa puerta.
| lo que aquí llamamos | qué es en el eje de orquestación | cómo lo llama el sector |
|---|---|---|
| Leer (consulta) | un flujo de trabajo que arranca usted | pregunta y respuesta sobre datos propios |
| Avisar (supervisión) | un flujo de trabajo que arranca un reloj | detección y aviso |
| Ejecutar (ejecución) | un flujo de trabajo con acciones permitidas | human in the loop, con la puerta de aprobación donde la ponga la regla |
Traducirlo así tiene una ventaja práctica: cuando un proveedor use una de esas palabras, usted ya sabe en cuál de las tres filas encaja lo que le está enseñando.
Lo que sale de una primera conversación
La primera clase es la única que se puede enseñar sin conectar nada con nada. Por eso es casi siempre la que se enseña, y por eso la tercera conviene verla funcionando.
No hace falta que prepare nada. Traiga un proceso que le esté costando dinero y díganos dónde viven sus datos.
De esa conversación sale, con los nombres de sus sistemas y no de los nuestros: cuál de las tres clases resuelve ese proceso, la regla escrita que la gobernaría y dónde se pararía el agente. Las tres, por escrito.
Y si prefiere no sacar usted la lista de más arriba, mándenos un volcado de sus pedidos de los dos últimos años y se la devolvemos hecha y ordenada por importe. Con su límite escrito, como el de los agentes: para ese cálculo no hacen falta nombres de cliente, basta con un identificador, la fecha del pedido y el importe.
Lo que se pregunta antes de decidir
- ¿En qué se diferencia un agente de IA de un copiloto y de un RPA?
- Un copiloto sugiere y el trabajo lo hace usted. El RPA reproduce una secuencia fija y se rompe cuando una pantalla cambia, porque reconoce formas y no significados. Un agente lee el estado de los sistemas de la empresa, aplica una regla escrita y actúa: contesta, avisa, o hace el trabajo y se para donde una regla escrita le dice que se pare.
- ¿Puedo empezar por un proceso o hay que conectarlo todo?
- Por uno. Las cuatro fichas publicadas conectan cosas distintas y ninguna lo conecta todo: la cartera lee una réplica de solo lectura del ERP, el almacén lee su sistema de gestión en tiempo real. Lo que decide por dónde se empieza es de qué sistema se puede leer hoy.
- ¿Puede un agente subir de nivel por sí solo?
- No. En nuestro buzón de soporte el nivel de autonomía sube únicamente con aprobación explícita. Bajarlo no requiere ninguna, que es la asimetría que conviene exigir. La ficha publica el disparador: los niveles bajan solos si la calidad cae. El número exacto sale de los datos de cada instalación, así que no hay uno que sirva para todas.
- ¿Tengo que empezar por un agente que solo lea?
- Casi siempre sí, y no por prudencia: es que sin la lectura funcionando no se sabe sobre qué se avisaría ni sobre qué se ejecutaría. Además las clases se apilan: un agente de ejecución lleva dentro uno de consulta, y uno de supervisión en cuanto el trabajo se lo pide. Lo que sí hay que hacer antes de cualquiera es la auditoría de qué datos hay, qué procesos los mueven y qué reglas los gobiernan.
- ¿Por qué no se publica ningún umbral con su número?
- Porque se derivan de los datos de cada empresa. Un umbral que es correcto para un almacén es un mal valor por defecto para el siguiente. Lo que sí se publica es la forma de la regla: el ritmo de compra medido sobre los dos últimos años de cada cliente, y el aviso al doble.
- ¿Dónde se ve cada clase funcionando?
- En los cuatro casos publicados, cada uno con sus cifras, su estado y su límite declarado: el asistente de la tienda especializada, la cartera B2B, el almacén y el buzón de soporte.
Fuentes
- 1.Caso publicado: un agente de IA de cara al público en comercio especializado, con su límite declarado. En uso público ↩
- 2.Caso publicado: la cartera B2B vigilada cada noche, con sus cifras, su regla y su límite declarado. En producción ↩
- 3.Caso publicado: el almacén vigilado en tiempo real, con sus 24 reglas, sus cifras y su límite declarado. En producción ↩
- 4.Caso publicado: el buzón de soporte convertido en casos resueltos, con sus niveles de autonomía y su límite declarado. En despliegue ↩
- 5.Anthropic, «Building Effective AI Agents»: el corte entre flujos de trabajo y agentes ↩
- 6.Propuesta en el blog de la Cloud Security Alliance, «Autonomy Levels for Agentic AI»: la escala de seis niveles, de L0 a L5 ↩