Un agente no es un chat que responde bonito. Es un trabajador digital con una tarea, acceso a los sistemas y permiso para actuar dentro de límites definidos.
Un agente de IA es un componente de software que recibe una señal, decide qué corresponde hacer y lo hace usando los sistemas de la empresa. La señal puede ser un mensaje de WhatsApp, un correo con una factura adjunta, un evento del ERP o simplemente la hora de cierre de la jornada.
Lo que lo distingue no es el modelo de lenguaje que usa por dentro, sino tres cosas: tiene una tarea acotada, tiene acceso a datos reales y tiene permiso para ejecutar acciones concretas. Sin esas tres, hay un asistente conversacional; con ellas, hay trabajo que deja de hacerse a mano.
El marco que usamos para explicarlo es simple: llega una señal, el agente decide, el sistema actúa y el resultado queda en memoria. Todo lo demás —modelos, orquestadores, integraciones— es la manera de sostener esos cuatro pasos.
Un chatbot clásico funciona con respuestas preparadas y un árbol de opciones. Si la pregunta se sale del árbol, responde algo genérico o pide que se repita. No consulta datos, no registra nada y no cambia el estado de ningún sistema: la conversación termina donde empezó.
Un agente parte de la pregunta real, la interpreta y va a buscar la respuesta donde está: las existencias en el ERP, el estado del pedido en el sistema de ventas, la condición comercial en la planilla. Si la respuesta existe, la entrega con el dato vigente. Si no existe, no la inventa: deriva el caso a una persona con el contexto ya reunido.
La segunda diferencia es que el agente escribe, no solo lee. Registra un pedido, actualiza un campo, deja un archivo clasificado o emite una alerta. Por eso su alcance se define con límites explícitos: qué puede hacer solo y qué necesita aprobación humana.
Un agente sirve para poco si está aislado. Las herramientas son las conexiones que le permiten trabajar: consultas al ERP, lectura y envío de correo, acceso a la conversación de WhatsApp, lectura de la tienda online, escritura en planillas, consulta de repositorios de documentos.
Cada herramienta se entrega con un permiso concreto. Un agente de atención puede consultar stock y crear un pedido, pero no modificar precios. Un agente documental puede leer archivos y escribir campos extraídos, pero no borrar registros. Ese detalle, que parece administrativo, es lo que hace que un agente se pueda poner en producción sin miedo.
El primer paso es la señal. Algo pasa: entra un mensaje, llega un documento, se cierra la caja, baja el stock de un insumo. En una arquitectura ordenada, esa señal la recibe un orquestador —nosotros usamos n8n— que decide qué agente corresponde.
El segundo paso es la decisión. El agente revisa los datos vigentes y los criterios definidos por la empresa. Aquí no hay magia: si el criterio no está escrito, el agente no lo puede aplicar. Parte del trabajo de implementación consiste en hacer explícito lo que hoy vive en la cabeza de alguien.
El tercer paso es la acción. El sistema que corresponde se actualiza, la respuesta sale, el pedido queda armado o el aviso llega al responsable. El cuarto paso es la memoria: el caso queda guardado con su resultado, y eso es lo que permite que mañana el mismo trabajo se repita igual, sin depender de quién esté de turno.
Sin memoria, cada interacción empieza de cero. Con memoria, el agente acumula el conocimiento de la empresa: las respuestas que ya fueron validadas, los criterios de decisión, el historial de cada caso y lo que se resolvió la última vez que apareció una situación parecida.
Esa memoria es también el lugar donde la empresa deja de depender de la rotación. Cuando alguien se va, lo que sabía sobre el proceso no se va con él si quedó escrito como criterio del agente. Es el argumento menos vistoso y probablemente el más útil.
Y es lo que permite trazabilidad: cada acción queda registrada con su motivo. Frente a una revisión interna, se puede reconstruir qué se hizo y por qué.
Un proceso completo rara vez cabe en un solo agente. Lo que funciona es dividirlo: un agente atiende al cliente, otro revisa inventario, otro prepara la compra, otro deja el reporte listo. Cada uno con su tarea y sus permisos.
La coordinación ocurre por traspaso. El agente de atención pregunta al de inventario si hay existencias; el de inventario avisa al de compras que hay que reponer; el de compras deja el pedido preparado y notifica a una persona para la aprobación. Nadie transcribe nada entre un paso y el siguiente.
En la práctica esto se parece más a un equipo con roles claros que a un robot que lo hace todo. Y tiene una ventaja concreta: si un paso falla, se corrige ese paso sin rehacer el proceso completo.
El mismo esquema se ve distinto según el negocio, pero la estructura se repite: señal, decisión, acción, memoria.
Partimos por el proceso, no por la herramienta. La primera conversación no es sobre modelos ni plataformas: es sobre qué trabajo repetitivo consume horas del equipo, quién lo hace hoy y qué pasa cuando se hace mal.
Después se mapea: qué sistemas participan, qué datos existen y en qué estado están. Ahí también se define lo que no se automatiza, porque un proceso que primero necesita ordenarse no mejora por ponerle un agente encima.
Luego se construye un alcance acotado, se mide, y con ese resultado se decide el paso siguiente. Es menos vistoso que un plan de transformación completo, y es la razón por la que estas cosas terminan funcionando.
Si tienes un proceso en mente, media hora alcanza para saber si conviene automatizarlo, qué habría que conectar y cuál sería el primer paso.