7 min de lectura
"Agente" es la palabra que más ruido hace en el mercado de IA este año. Una llamada a un modelo desde un script, un chatbot con memoria, tres prompts encadenados o un sistema autónomo con acceso a bases de datos aparecen todos etiquetados como "agentes" dependiendo de quién lo cuenta. Tener una definición operativa útil permite distinguir cuándo hace falta una arquitectura de este tipo y cuándo un flujo lineal de prompts alcanza.
Qué distingue a un agente de un prompt
Un prompt es una instrucción. El modelo la recibe, genera una respuesta. No hay estado que se mantenga entre llamadas, ni ejecución de nada más allá de la generación de texto. Un agente, en cambio, tiene dos propiedades concretas que un prompt no tiene: autonomía sobre sub-decisiones dentro de su alcance (dentro del rol asignado, decide cómo cumplir la tarea) y responsabilidad por el resultado que produce (su output puede ser evaluado, aceptado o rechazado, y existe un mecanismo explícito para hacerlo).
Un ejemplo práctico. Un flujo que le pide a un modelo que resuma un documento es un prompt. Un agente encargado de la síntesis de un informe tiene un rol más amplio: decide qué documentos son relevantes y en qué orden abordarlos, cuándo ha reunido información suficiente, y qué presentar al final. Otro agente puede revisar ese informe con criterios propios, marcar lo que no cumple y devolver el borrador para ajuste.
El modelo que hay debajo puede ser el mismo en ambos casos. Lo que cambia es cómo se descompuso el trabajo y qué responsabilidades se le asignaron a cada parte. Un modelo pequeño con un rol bien definido y un mecanismo de evaluación claro puede comportarse como un agente útil; un modelo grande al que se le pide todo en un solo prompt puede no serlo.
¿Cuándo tiene sentido usar más de un agente?
Multi-agente es una arquitectura con un costo específico, más que una mejora automática sobre el agente único: más latencia, más piezas que coordinar, más superficie donde algo puede fallar. Ese costo se justifica cuando el trabajo tiene fases con criterios de éxito contradictorios entre sí.
Escribir y criticar son criterios contradictorios. Un modelo que escribe está optimizando para generar contenido coherente con la instrucción recibida. Un modelo que critica está optimizando para encontrar problemas en un texto ya escrito. Pedirle al mismo modelo que haga las dos cosas seguidas produce un texto que tiende a aprobarse a sí mismo, porque el criterio de la crítica termina alineándose con el de la escritura reciente.
Un agente que investiga un tema y un agente que decide si la investigación es suficiente tienen objetivos en tensión similar. El primero tiende a seguir buscando información. El segundo tiende a cerrar antes de perder demasiado tiempo. La tensión entre los dos produce una decisión que ninguno tomaría solo, la de usar la información disponible cuando es suficiente, no cuando es exhaustiva.
Cuando el trabajo no tiene esta clase de tensión interna, agregar agentes no agrega calidad. Un pipeline donde cada agente pasa su salida al siguiente sin criterios contradictorios es un sistema más complejo con los mismos resultados que un agente único bien diseñado.
¿Cuándo no tiene sentido?
Hay tres situaciones donde alguien monta multi-agente y termina con un sistema peor que la alternativa más simple.
La primera es cuando el proceso ya se puede describir como una secuencia determinista. Si el flujo es "extraer un campo, validar el formato, guardar en base de datos, enviar una notificación", eso es un pipeline de reglas. Meter un agente en cada paso lo hace más lento y menos predecible sin agregar nada a la calidad del resultado.
La segunda es cuando la descomposición en agentes es artificial. A veces se separan tareas que un modelo puede resolver de una sola pasada para que el sistema tenga más piezas y parezca más sofisticado. El resultado típico es un agente principal que realiza el trabajo real y varios agentes accesorios cuya función efectiva no está clara ni es medible. El sistema asume toda la complejidad de coordinar múltiples agentes sin obtener ninguna de las ventajas que esa coordinación tendría que traer.
La tercera es cuando el problema requiere baja latencia. Multi-agente introduce coordinación, y la coordinación cuesta tiempo. Un asistente que responde en tiempo real en una interfaz de conversación generalmente necesita ser un solo agente; la coordinación entre varios vuelve la respuesta demasiado lenta para ese caso de uso.
¿Cómo fallan los sistemas multi-agente?
Los patrones de fallo del multi-agente son distintos a los de un solo modelo, y hay que anticiparlos en el diseño antes de que aparezcan en producción.
El primero es la acumulación de errores. Un agente pasa datos ligeramente equivocados al siguiente; el siguiente construye sobre esos datos, agregando su propio ruido. Después de varios pasos, la salida del sistema no se parece a ninguna intención original. Detectar dónde empezó el problema es posible. Pese a que cada agente hizo algo razonable a partir de lo que recibió, y los errores son menos visibles a simple vista, la separación de tareas nos permite ver qué hizo cada agente y trackear el origen del error.
El segundo es la ausencia de checkpoints humanos en el punto de mayor incertidumbre. Un sistema multi-agente puede procesar cientos de casos sin que nadie vea muestras de lo que está produciendo. Sin un mecanismo explícito que lleve la salida a revisión humana en el punto crítico, los errores se acumulan y se descubren semanas después, en lote.
El tercero es la ilusión de descomposición. A veces la separación en agentes es cosmética. Todos los agentes están tomando decisiones tan correlacionadas entre sí que colapsan en un solo agente distribuido. El sistema asume el costo de coordinar múltiples agentes con la latencia y la complejidad operativa que eso implica, sin que haya diversidad real de criterios que justifique esa arquitectura.
Anticipar estos patrones cambia el diseño desde el principio. La construcción de sistemas con arquitecturas de agentes requiere definir el criterio de éxito de cada agente, dónde están los checkpoints humanos y qué condición manda un caso a revisión. Sin esa definición previa, el sistema funciona en el escenario controlado del desarrollo y falla cuando entra en producción.
Las tres preguntas antes de arrancar
Antes de decidir que un proyecto necesita arquitectura multi-agente, conviene responder tres preguntas.
La primera es si el trabajo se descompone en fases con criterios de éxito distintos y potencialmente contradictorios entre sí. Si es así, multi-agente puede aportar algo real. Si el trabajo es una secuencia lineal donde cada paso construye sobre el anterior sin tensión entre criterios, un solo agente bien diseñado va a ser más simple y más confiable.
La segunda es sobre latencia. Si el sistema tiene que responder en tiempo real, multi-agente rara vez es la respuesta correcta. Si el sistema procesa en diferido, la calidad puede justificar el tiempo adicional de coordinación.
La tercera es sobre validación: dónde va a estar el humano y qué muestras va a revisar, con qué frecuencia y en qué punto del flujo. Un sistema multi-agente sin este diseño desde el principio no falla el primer día. Falla dos meses después, cuando alguien pregunta por qué el resultado de esta semana no se parece al de la anterior y el equipo no tiene una explicación que pueda articular.
"Agente" seguirá siendo la palabra de moda. El trabajo de diseño útil empieza antes de elegir la arquitectura: verificar que hay tensión real entre criterios, que la latencia lo permite y que el flujo humano está definido. Sin ese trabajo previo, el sistema se convierte en una demo que funciona en condiciones controladas y falla cuando entra en producción con casos reales.