Un correo dice «mándame otras seis cajas como las del mes pasado». Antes de convertirlo en un pedido hay que saber quién escribe, qué producto compró y si esas seis cajas están disponibles. Leer la frase es una parte pequeña del trabajo.
Yo empezaría por decidir qué puede hacer el sistema cuando falte uno de esos datos. Esa decisión importa más que llamarlo agente.
Del texto a un borrador de pedido
Este es un escenario hipotético. Una empresa recibe pedidos por correo y quiere reducir la transcripción al programa de gestión. El sistema propone producto, cantidad y cliente; después consulta el catálogo y prepara un borrador para una persona.
El modelo puede interpretar texto poco uniforme y proponer campos. La conexión al programa de gestión permite consultar datos o escribir un registro. Las reglas comprueban cantidades permitidas, referencias existentes y campos obligatorios. Ninguna de esas piezas sustituye a las otras: un texto bien entendido puede acabar en un cliente equivocado si la identificación está mal resuelta.
La documentación de n8n sobre agentes describe un modelo que decide qué acciones y herramientas utilizar. Un flujo de pasos fijados de antemano puede ser suficiente para este pedido. Si la secuencia nunca cambia, añadir decisiones del modelo puede complicar el control sin aportar utilidad. Según la tarifa oficial de n8n (consulta: 11 de octubre de 2026), todos los planes incluyen usuarios ilimitados: no cobra por usuario, sino por ejecuciones mensuales de los flujos. Esto no significa que el servicio sea gratis.
Tampoco «chatbot» significa necesariamente menú rígido. Una conversación puede apoyarse en modelos y herramientas; la cuestión práctica es qué permisos tiene y qué comprobaciones preceden a una acción.
Dónde pondría la revisión
En el primer ensayo, el sistema solo crearía borradores. Una persona revisaría cliente, referencia, unidades y dirección antes de confirmar el pedido. Si el correo dice «como la otra vez», habría que mostrar qué pedido anterior se ha utilizado, para poder corregir esa interpretación.
La consulta de existencias requiere otro límite: ver stock disponible no equivale a reservarlo. Si dos pedidos consultan la última unidad a la vez, el programa de gestión debe resolver la reserva. No dejaría que el modelo prometiera una entrega a partir de una lectura aislada del inventario.
Además, guardaría el identificador del correo y del borrador. Si una conexión falla después de crear el registro, un reintento no debería duplicarlo. Y si falta una referencia, el caso pasaría a revisión con el dato pendiente, sin inventarlo.
n8n permite configurar flujos de error y revisar ejecuciones. Eso ayuda a detectar fallos de ejecución. Un pedido incorrecto que el programa acepta necesita controles propios: puede no producir ningún error técnico.
Una prueba que permita decidir
Tomaría una muestra de pedidos normales, ambiguos y repetidos. Mediría el tiempo manual hasta dejar cada pedido correcto y el tiempo nuevo, incluida la revisión y las correcciones. Contaría también cuántos casos se detienen y si aparece alguna acción indebida.
Si el borrador ahorra transcripción pero exige investigar cada propuesta, quizá no compense. Si funciona con pedidos claros, puede quedarse limitado a ellos. La ampliación de permisos vendría después de esa medición y de acordar quién responde ante las excepciones.
Para empezar, elige una acción reversible, identifica los datos necesarios y escribe qué hará el sistema cuando no los encuentre.
Fuentes
- n8n: cómo funcionan los agentes — Consultado el 10-10-2026. El modelo elige acciones y herramientas; el flujo puede ejecutar varias llamadas. No garantiza comprensión, velocidad ni corrección.
- n8n: gestión de errores — Consultado el 10-10-2026. Permite asociar un flujo de errores y revisar ejecuciones fallidas; no detecta por sí solo todos los errores de negocio.
Si tienes una tarea con entradas y excepciones identificadas, puedes contármela para estudiar qué parte conviene delegar.