Hay una palabra que cambió de significado tres veces en los últimos doce meses: "agente". A principios de 2025 era casi una promesa especulativa. Hacia mediados de año se llenó de marketing y empezó a aplicarse a cualquier flujo automatizado con IA. Hoy, en mayo de 2026, ya hay productos reales operando en producción que merecen el nombre, y hay también decenas de productos que se autodenominan agentes y son otra cosa. Para un Product Manager, esa confusión vuelve casi imposible una conversación seria con el equipo técnico, con stakeholders o con un cliente.
Aclarar qué cuenta como agente y qué no, cuándo conviene diseñar uno y cuándo conviene quedarse en una solución más simple, qué decisiones específicas le toca tomar al PM, qué riesgos operacionales aparecen cuando un sistema actúa por su cuenta. Esa es la conversación que hace falta ahora, antes de que los equipos sigan invirtiendo meses en arquitecturas agénticas que solucionan problemas que no tenían.
Este artículo cubre qué es un agente de IA con una definición que sirva, el espectro completo desde automatización tradicional hasta sistemas multi-agente, en qué tipo de problemas un agente es la respuesta correcta (y cuándo es overkill), los frameworks de diseño que están dominando la práctica, y los desafíos específicos del rol de PM cuando el producto empieza a actuar por su cuenta.
Qué es un agente de IA
Hay tantas definiciones de "agente" como influencers de IA. La que más sirve en el día a día con equipos de producto: un agente de IA es un sistema que, ante un objetivo dado, decide por su cuenta qué pasos seguir, elige qué herramientas usar en cada paso, ejecuta esas acciones contra sistemas externos y ajusta su plan según los resultados que va obteniendo.
Esa definición tiene cuatro componentes que vale la pena desarmar. Primero, un objetivo: alguien le pide al agente que logre algo, en lugar de pedirle que ejecute una secuencia de instrucciones. Segundo, autonomía de plan: el agente decide la secuencia de pasos, sin seguir una secuencia preprogramada por un humano. Tercero, uso de herramientas: tiene acceso a APIs, funciones, bases de datos o aplicaciones externas y elige cuál invocar en cada momento. Cuarto, adaptación: lee el resultado de cada acción y, según lo que encuentra, reformula el siguiente paso.
Cuando alguno de esos cuatro componentes falta, conviene usar otra palabra. Un chatbot que responde preguntas se queda corto frente a esa definición porque no toma acciones contra sistemas externos. Una automatización que ejecuta cinco pasos predefinidos tampoco entra, porque el plan está fijo desde el inicio. Un sistema que llama a una API por cada pregunta queda fuera cuando la API a invocar está cableada por el desarrollador y no la elige el modelo.
Esta precisión importa porque cada componente trae consigo una clase de riesgo. Un sistema con autonomía de plan puede tomar caminos que nadie anticipó. Un sistema con uso de herramientas puede hacer cosas con consecuencias reales en el mundo: cobrar, enviar correos, modificar datos. Un sistema que adapta su plan a resultados puede entrar en loops o repetir intentos costosos. Cuando un equipo dice "estamos construyendo un agente", esa frase implica asumir esos riesgos a la vez.
El espectro: automatización, asistente, agente, multi-agente
La forma más útil de entender los agentes es ubicarlos en un espectro que arranca con sistemas determinísticos y termina con sistemas multi-agente complejos. Cada escalón agrega autonomía y agrega riesgo. Para un PM, saber en qué escalón vive su producto (o su próxima feature) cambia cómo se diseña, cómo se evalúa y cómo se opera.
Automatización tradicional
El primer escalón son los flujos automatizados clásicos: Zapier, Make, n8n sin LLM, scripts de integración entre sistemas. Hay reglas explícitas, condicionales claras y un resultado predecible. Si el input es A, pasa B. Si es C, pasa D. Confiables, baratos, fáciles de testear. Funcionan perfectamente para procesos repetitivos con casuística acotada.
Asistente conversacional
El segundo escalón aparece cuando se agrega un LLM al medio. El sistema entiende lenguaje natural, mantiene contexto de la conversación y puede responder con un nivel de flexibilidad muy superior. Es lo que típicamente llamamos "chatbot inteligente" o "copiloto". El usuario sigue siendo quien dirige: pide cosas, el sistema responde, el usuario decide si lo que recibe le sirve. El sistema no actúa por su cuenta contra el mundo exterior.
Asistente con herramientas (tool-use)
El tercer escalón se cruza cuando el modelo recibe la capacidad de invocar funciones, APIs o búsquedas. Sigue habiendo un humano dirigiendo el intercambio, pero ahora el modelo puede consultar una base de datos antes de responder, buscar en internet, traer información en vivo, hacer cálculos. Muchos sistemas que se venden como "agentes" en realidad viven acá: usan herramientas, la persona sigue marcando el ritmo y el sistema no toma decisiones de varios pasos sin supervisión.
Agente (single-agent)
En este escalón empieza la categoría que justifica el nombre. El usuario da un objetivo de cierto nivel de abstracción ("organiza esta agenda", "investiga este lead", "prepárame el reporte de la semana") y el sistema decide qué pasos seguir, ejecuta cada uno, ajusta según resultados y devuelve el outcome. Hay un ciclo iterativo de razonamiento, acción, observación y nueva acción. El usuario interviene si quiere, sin que su intervención sea necesaria para que el agente complete la tarea.
Sistema multi-agente
El último escalón es el más sofisticado. Varios agentes especializados coordinan entre sí, cada uno con su rol, sus herramientas y a veces hasta su propio modelo de fondo. Hay un agente coordinador que delega, agentes ejecutores que cumplen subtareas, y mecanismos de comunicación entre ellos. Resuelven problemas que un solo agente no resolvería bien, pero suben significativamente la complejidad de diseño, costo y evaluación.
Para un PM, la regla operativa importa más que las definiciones: siempre conviene resolver el problema en el escalón más bajo del espectro que lo resuelva bien. Saltar a multi-agente cuando una automatización lo resolvía es una de las formas más caras de demostrar que se entendió mal el problema.
Cuándo un agente es la respuesta correcta (y cuándo no)
Antes de preguntarse cómo construir un agente, conviene preguntarse si este problema realmente lo necesita. La respuesta honesta, en la mayoría de los casos, es que no. Esta es la decisión que más equipos se saltan, y la que más caro sale cuando se decide mal.
Un agente tiene sentido cuando se cumplen, simultáneamente, varias condiciones. La primera: el espacio de soluciones es demasiado amplio para mapearlo a reglas. Si pudieras enumerar las quince formas en que el sistema debería responder a las quince situaciones posibles, te alcanza con una automatización con condicionales: hace el trabajo más barato, más predecible y más fácil de mantener. Los agentes brillan cuando la combinatoria de situaciones es alta y nadie quiere dedicar tiempo a especificar cada rama.
La segunda condición: hay tareas reales que ejecutar contra sistemas externos. Si lo único que necesitas es procesar información y devolver una respuesta, te alcanza con un caso de uso conversacional sin necesidad de agente. Los agentes justifican su costo cuando reservan turnos, modifican registros, envían comunicaciones, mueven plata o coordinan acciones que tienen impacto en el mundo. Sin acciones, el agente queda como overkill.
La tercera condición: el costo de un error es tolerable o detectable a tiempo. Un agente, por definición, va a equivocarse de maneras que nadie anticipó. Si cada error se traduce en una transacción financiera incorrecta, en un correo enviado a la persona equivocada o en un acceso otorgado sin permiso, los riesgos pueden superar al beneficio. Hay maneras de mitigarlo (human-in-the-loop, guardrails, sandboxing), aunque esas mitigaciones tienen su propio costo y a veces eliminan el valor que justificaba el agente.
La cuarta condición: tienes paciencia y presupuesto para iterar. Los agentes no funcionan bien al primer intento, casi nunca. Requieren ajustes constantes de prompts, herramientas, criterios de éxito y observabilidad. Si la organización espera "lo lanzo y olvido", el proyecto va a fallar incluso si el primer prototipo se ve impecable.
Cuando alguna de esas condiciones no se cumple, conviene quedarse en un escalón más bajo. Una automatización con LLM al medio resuelve la mayoría de los casos de uso reales que vemos en producto. Cuando un equipo nos dice "queremos hacer un agente para esto", la primera pregunta que hacemos suele ser: "¿qué pasa si lo haces con una automatización inteligente que llama a tres herramientas?". Más veces de las que esperarías, esa solución alcanza, cuesta menos y es operable por humanos comunes.
Frameworks de diseño agéntico
Cuando la decisión es seguir adelante con un agente, hay tres patrones de diseño que conviene conocer. No son los únicos, aunque cubren la enorme mayoría de los sistemas que están en producción hoy.
ReAct (Reasoning + Acting)
ReAct es el patrón más extendido y, en muchos sentidos, el patrón fundacional. El agente alterna entre "pensar" y "actuar" en ciclos cortos. Recibe un objetivo, razona sobre el siguiente paso, elige una herramienta, ejecuta, lee el resultado, vuelve a razonar, y así hasta cumplir el objetivo o reconocer que no puede.
Funciona bien para tareas donde el plan emerge del contexto. El agente no necesita un mapa completo desde el inicio: va resolviendo a medida que descubre información. Falla cuando el espacio de decisiones es demasiado abierto y el modelo entra en loops, o cuando una sola acción mal elegida arrastra al resto del proceso.
Tool-use con planificación previa
La variante con planificación arma un plan completo antes de empezar a ejecutar. El agente recibe el objetivo, descompone la tarea en una secuencia de pasos, y después ejecuta cada paso. Algunos sistemas replanifican cuando un paso falla; otros simplemente abortan.
Es más predecible que ReAct, más fácil de mostrarle al stakeholder ("este es el plan que va a seguir") y suele dar mejor resultado en tareas donde la secuencia se puede anticipar razonablemente. Pierde flexibilidad: si el mundo cambia a la mitad del plan, el agente necesita lógica adicional para adaptarse.
Coordinator-subagent (multi-agente jerárquico)
Cuando el problema es demasiado grande para un solo agente, aparece el patrón coordinador-ejecutores. Un agente principal divide la tarea, delega cada parte a un sub-agente especializado, recibe los resultados parciales y compone la respuesta final. Cada sub-agente tiene su propio prompt, sus propias herramientas, y a veces hasta su propio modelo.
Es la arquitectura más poderosa y también la más cara y la más difícil de evaluar. Cuando algo falla, hay que decidir si falló el coordinador (delegó mal), el sub-agente (ejecutó mal) o la comunicación entre ellos. Las suites de evaluación necesarias para sostener un sistema así son significativamente más complejas. Conviene reservarlo para casos donde un solo agente claramente no alcanzaba.
Hay otros patrones que vale la pena seguir (reflection, debate, swarm), aunque la regla práctica para un PM es elegir el patrón más simple que resuelva el caso y subir de complejidad solo cuando la evidencia lo justifica. La complejidad arquitectural casi siempre se paga en costos y en deuda operativa.
Los desafíos específicos del PM agéntico
Diseñar un agente cambia la lista de decisiones que el rol de PM tiene que tomar. Cuatro de esas decisiones aparecen en cada proyecto agéntico que vemos, y son las que más diferencian a un PM que sabe operar este tipo de productos de uno que aprende sobre la marcha.
Guardrails: definir qué puede y qué no puede hacer el agente
Un agente con autonomía completa termina siendo ingenuo o peligroso, según el caso. La primera decisión de producto es delimitar el espacio de acción: qué herramientas tiene disponibles, sobre qué datos puede operar, qué acciones requieren confirmación humana, qué tipos de output son aceptables. Estas son decisiones de producto, con dueño en el PM, según el riesgo del caso de uso. Cuando esas decisiones se delegan al equipo de ingeniería, suelen resolverse por la vía más fácil de implementar, y el riesgo queda del lado equivocado.
Un buen guardrail responde a una pregunta concreta: "¿qué es lo peor que puede pasar si el modelo se equivoca acá?". Si la respuesta es "nada grave", el guardrail puede ser laxo. Cuando la respuesta involucra dinero, datos sensibles, comunicaciones externas o acciones irreversibles, la respuesta tiene que incluir un humano en el loop o validaciones estrictas antes de cada acción.
Gobernanza: quién es responsable cuando algo sale mal
Los agentes ejecutan acciones contra sistemas reales. Si el agente envía un correo equivocado, si modifica un registro que no debía, si aprueba un acceso sin permiso, alguien tiene que ser responsable de esa decisión, incluso cuando la tomó un modelo. La gobernanza define quién es ese alguien y bajo qué criterios.
Para un PM, esto se traduce en políticas explícitas: logging de todas las acciones del agente, trazabilidad del razonamiento que llevó a cada decisión, mecanismos de reversión para acciones críticas, escalation cuando el agente detecta incertidumbre. Estas piezas casi nunca aparecen en el roadmap inicial. Cuando aparecen tarde, suelen aparecer después de un incidente que las hace inevitables.
Costos: por qué los agentes son caros y cómo controlarlo
Los agentes consumen más tokens de los que la mayoría de los equipos espera. Cada ciclo de razonamiento, cada llamada a herramientas, cada reevaluación de plan acumula. Un agente que para un humano toma diez segundos puede haber consumido varias llamadas al modelo. Multiplicado por usuarios reales, el costo escala rápido.
Un PM agéntico tiene que pensar en costos como parte del diseño, en lugar de tratarlos como problema de infraestructura. Eso implica decisiones concretas: cuándo usar un modelo grande y cuándo uno más barato, qué tareas conviene resolver sin llamada a modelo (usando código clásico), cuántos turnos máximos permitir antes de cortar, cuándo cachear resultados. Las arquitecturas más elegantes en el paper suelen ser inviables económicamente en producción.
Evaluación: cómo saber si el agente funciona
Acá aparece el desafío que más subestiman los equipos en su primer agente. Evaluar un sistema agéntico es mucho más complejo que evaluar un LLM en una tarea acotada. No alcanza con medir si la respuesta final es correcta: hay que medir si el agente eligió las herramientas correctas, si las usó bien, si el plan tenía sentido, si manejó bien los errores intermedios, si llegó al objetivo con un costo razonable.
Las técnicas para evaluar agentes son una disciplina propia que crece rápido: evaluación de trayectoria (ver el camino completo, paso por paso), comparación de planes entre distintos modelos, métricas de eficiencia (cuántos pasos, cuántos tokens, cuánto tiempo), evaluación de uso correcto de herramientas. Estas técnicas las cubrimos en profundidad en el pillar Qué son los AI Evals y son uno de los temas centrales del lab EVA.
Sin una práctica de evaluación seria, los agentes terminan operando en producción sin que nadie sepa qué tan bien funcionan, hasta que un usuario reporta el primer fallo público. Para un PM, esta es probablemente la decisión más importante de todas: no shipear un agente sin un eval que respalde la decisión. Esta misma disciplina conecta directamente con la práctica que cubrimos en qué hace un AI Product Manager, donde el criterio cuantitativo sobre comportamiento probabilístico aparece como la habilidad menos opcional del rol.
Cómo empezar con agentes (sin construir un Frankenstein)
Si llegaste hasta acá y la idea de meter manos en un agente te resulta atractiva, la pregunta práctica es por dónde empezar. La trampa más común es saltar directamente al caso de uso más ambicioso. Funciona mejor seguir el orden inverso: empezar chico, sentir el material y escalar cuando entendiste cómo se comporta.
Construir un primer agente simple, end-to-end. Algo que tome un objetivo acotado, use dos o tres herramientas, y devuelva un resultado. Una hora de trabajo con n8n y OpenAI alcanza para tener algo funcional. La experiencia de ver al agente "razonar" en vivo cambia cualquier intuición previa sobre cómo se diseñan. Para esto, el Flash Workshop Agentic AI Essentials (AGE) está pensado exactamente como puerta de entrada: cuatro horas, construir un agente desde cero, llevártelo funcionando.
Aprender a evaluar antes de aprender a escalar. Antes de construir un sistema multi-agente, conviene saber cómo medir si un solo agente está haciendo lo correcto. Sin esa capacidad, todo lo demás es teatro: equipos que escalan complejidad sin saber si están mejorando o empeorando. El programa de AI Evals es el punto de entrada con práctica que se hace en modo lab.
Tomar un proyecto real con stakes acotados. Un caso interno, un proceso operativo de la propia empresa, una automatización personal. Algo donde puedas iterar libremente, equivocarte sin consecuencias caras y construir intuición. La intuición agéntica no se transfiere por lectura: se construye operando.
Si quieres acelerar este proceso con estructura, comunidad y mentoría sobre casos reales, nuestro programa Certified Agentic AI Product Manager (AAPM) está diseñado exactamente para esto. Son ocho semanas que cubren desde la diferencia entre automatización inteligente y agentes y los frameworks de diseño agéntico (ReAct, multi-agent), pasando por memoria y RAG para agentes, construcción de un agente funcional con n8n y arquitecturas multi-agente, hasta evals, guardrails, gobernanza y manejo de costos en producción. El prerrequisito es haber completado el Certified AI Product Manager (AIPM) o tener experiencia equivalente, porque la base de Product Management para IA es lo que permite tomar las decisiones de diseño con criterio.
La adopción de agentes en producto se va a acelerar en los próximos doce meses. Los equipos que empiecen ahora con cuidado, con buena base de evals y con criterio para decidir cuándo un agente es la respuesta correcta van a tener una ventaja difícil de recuperar. Los agentes van a ser parte de tu producto en algún momento. Lo que cambia entre equipos es qué tan preparado va a estar cada uno cuando llegue ese momento.