“Agente” se convirtió en la palabra de moda en inteligencia artificial. Se usa para describir desde un chatbot que responde preguntas frecuentes hasta sistemas que supuestamente reemplazan departamentos completos. Con tanto ruido, cuesta saber qué es real y qué es promesa.
Este artículo separa ambas cosas: qué es técnicamente un agente, qué puede hacer de forma confiable hoy y cómo saber si tu operación realmente lo necesita.
De chatbot a agente: la diferencia está en las herramientas
Un modelo de lenguaje, por sí solo, recibe texto y devuelve texto. Puede redactar, resumir o responder, pero no puede consultar tu inventario, revisar el estado de un pedido ni crear una tarea en tu CRM.
Lo que cambia el juego es el uso de herramientas (tool use). El sistema le describe al modelo un conjunto de acciones disponibles, por ejemplo “buscar pedido por número” o “consultar stock por SKU”, con sus parámetros. El modelo decide cuándo usar cada una, tu sistema ejecuta la acción real y le devuelve el resultado. Con esa información, el modelo decide el siguiente paso, y así hasta terminar la tarea.
Ese ciclo de pensar, actuar, observar y volver a decidir es lo que convierte a un modelo en un agente. La inteligencia viene del modelo; la utilidad viene de las herramientas que le conectas.
Para facilitar esas conexiones existe el Model Context Protocol (MCP), un estándar abierto que define cómo una aplicación de IA se conecta con fuentes de datos y herramientas externas. En la práctica, permite construir una integración una vez y usarla con distintos modelos y aplicaciones compatibles.
Flujos de trabajo y agentes no son lo mismo
Una distinción muy útil viene de la guía “Building effective agents” de Anthropic. Ahí se separan dos tipos de sistemas:
- Flujos de trabajo: el modelo y las herramientas siguen un camino definido de antemano en código. Tú decides los pasos; la IA ejecuta las partes que requieren entender lenguaje.
- Agentes: el modelo decide dinámicamente qué pasos dar y qué herramientas usar, según lo que va encontrando.
La misma guía recomienda partir por la solución más simple posible y agregar complejidad solo cuando mejora resultados de forma demostrable. Es un consejo que compartimos: buena parte del valor que la IA entrega hoy en empresas viene de flujos bien diseñados, no de agentes autónomos.
Ejemplo de flujo
Llega un correo de un cliente. La IA lo clasifica (reclamo, cotización, consulta), extrae los datos relevantes, crea el registro en el CRM y prepara un borrador de respuesta que una persona aprueba. Los pasos son siempre los mismos; lo que cambia es el contenido. Esto es lo que resolvemos en Automatización de procesos.
Ejemplo de agente
Un cliente escribe que su pedido no llegó. Para responder bien hay que revisar el estado del pedido, consultar el seguimiento del courier, verificar la política de reembolsos y, según lo que aparezca, ofrecer un reenvío o escalar el caso. Cada caso requiere investigar distinto. Ahí un agente con acceso de lectura a esos sistemas aporta algo que un flujo rígido no puede.
Qué hacen bien los agentes hoy
- Investigar y sintetizar información repartida en varias fuentes: documentos internos, bases de datos, sitios web.
- Operar sobre herramientas bien definidas, especialmente cuando cada herramienta tiene una descripción clara y entrega respuestas estructuradas.
- Resolver tareas de varios pasos donde pueden verificar su propio avance, por ejemplo comprobando que un registro quedó creado antes de continuar.
- Redactar con contexto real del negocio: respuestas, informes o propuestas que usan datos que acaban de consultar.
Dónde todavía fallan
Conviene ser honestos con los límites, porque son los que determinan el diseño:
- Los errores se acumulan. En cadenas largas, un dato mal interpretado en el paso dos contamina todo lo que viene después.
- Las herramientas ambiguas confunden. Si dos herramientas hacen cosas parecidas o sus nombres no son claros, el agente se equivoca al elegir.
- Costo y latencia crecen con cada paso. Cada vuelta del ciclo es una llamada más al modelo. Un agente que da veinte pasos para algo que un flujo resuelve en dos es más caro y más lento.
- Las acciones irreversibles son delicadas. Enviar un correo a un cliente, emitir una nota de crédito o borrar un registro no admiten “deshacer”.
Cómo diseñar un agente que no te dé sustos
- Alcance acotado. Un agente que resuelve bien un tipo de tarea vale más que uno que intenta todo.
- Permisos mínimos. Separa herramientas de lectura y de escritura. Si el agente solo necesita consultar, no le des permiso para modificar.
- Aprobación humana para lo irreversible. El agente prepara, una persona confirma.
- Registro de cada paso. Qué consultó, qué decidió y por qué. Sin eso, no puedes auditar ni mejorar.
- Límites de pasos y de gasto. Si una tarea supera cierto número de iteraciones, se detiene y escala.
- Pruebas antes de producción. Un conjunto de casos reales con el resultado esperado, que vuelves a correr cada vez que cambias algo.
Cuando un solo agente ya no alcanza y necesitas varios coordinados, integrados con tu ERP y con flujos de aprobación formales, el problema pasa a ser de arquitectura. Eso es lo que abordamos en Infraestructura de Procesos con IA.
¿Lo necesitas? Una regla práctica
Si puedes dibujar tu proceso como un diagrama con pocos caminos posibles, probablemente necesitas un flujo de trabajo con IA, no un agente. Es más barato, más predecible y más fácil de mantener.
Si cada caso requiere investigar de forma distinta, consultar varias fuentes y decidir sobre la marcha, un agente empieza a tener sentido. Y si estás partiendo, un buen asistente con el conocimiento de tu negocio suele ser el primer paso correcto: es lo que construimos en Asistentes de IA.
La pregunta no es si tu empresa debería tener agentes. Es qué tarea concreta quieres resolver, y cuál es la forma más simple de resolverla bien.
