La dinámica de los agentes de IA: orquestación, fallos y producción

Tiempo de lectura: 10 minutos

En el primer artículo vimos de qué está hecho un agente: un motor que razona, una memoria que le dice lo que sabe y unas manos con las que actúa, girando en un bucle. Con eso ya se distingue un agente de un chatbot o de un workflow.

Esta segunda parte va de lo otro: qué pasa cuando el agente se pone a funcionar. Cómo se reparte el trabajo entre varios, cómo falla, cómo se sabe si sigue funcionando y qué hay que montar antes de dejarlo suelto en producción. Es la parte que separa una demo que impresiona de un sistema en el que se puede confiar.

En resumenPor qué te importa: la demo de un agente casi siempre funciona; lo que decide si sirve es cómo se comporta al repetirse mil veces y qué pasa el día que se equivoca. Qué aporta este artículo: cuándo repartir el trabajo entre subagentes o varios agentes (y cuándo eso solo añade coste), los cuatro modos de fallo típicos con el freno que corresponde a cada uno, y las cuatro piezas que hay que montar antes de producción: evals, observabilidad, permisos y control de coste. Qué te llevas: las preguntas concretas que hacer antes de aprobar un agente, y el criterio para decidir cuánta autonomía darle.

Cuándo repartir el trabajo entre varios agentes

Lo primero que se pregunta todo el mundo al pasar de un agente a algo más grande es si conviene tener varios. La respuesta corta: casi siempre menos de los que parece.

Cuándo repartir el trabajo entre agentes: un agente cuando los pasos van encadenados y cada uno necesita el anterior; subagentes cuando una tarea ensucia el contexto del principal, que delega y recibe un resultado limpio; multiagente con orquestador cuando las piezas apenas se hablan entre sí y pueden ir en paralelo

Un solo agente: cuando los pasos van en fila

Si cada paso necesita el resultado del anterior, repartir no ayuda. Pulso, el agente del curso que convierte comentarios de socios en oportunidades priorizadas, hace justo eso: lee, agrupa, cuenta, prioriza y redacta. Poner un agente por paso solo añadiría cinco conversaciones de coordinación a un trabajo que un flujo lineal hace de un tirón.

Dentro de ese agente único hay dos patrones que conviene conocer por su nombre. ReAct (razonar y actuar) es el bucle básico: pensar, usar una herramienta, mirar el resultado, volver a pensar. Y la reflexión: el agente revisa su propia salida antes de darla por buena ("¿cada oportunidad cita respuestas reales?, ¿me he dejado un tema con muchas menciones?") y la corrige si algo falla. Los dos dan flexibilidad y los dos cuestan vueltas de bucle, es decir, tokens y tiempo.

Subagentes: delegar para no ensuciar el contexto

Un subagente es un agente al que otro le encarga una tarea acotada. El principal delega, el subagente trabaja en su propia conversación (su propio contexto, sus propias herramientas) y devuelve solo el resultado.

Aquí está el malentendido más común: casi todo el mundo llega a los subagentes buscando paralelismo, "hacer cinco cosas a la vez". Ese es el beneficio menor, y el que más decepciona, porque muchas tareas no son paralelizables. El beneficio real es aislar el contexto. Si una tarea requiere revisar cuarenta documentos para sacar tres datos, hacerlo en el hilo principal deja esos cuarenta documentos ocupando la ventana de contexto durante el resto del trabajo. Delegarlo a un subagente devuelve los tres datos y tira el resto.

Recordando la primera parte: la ventana de contexto es finita y todo lo que entra compite por el mismo espacio. Un contexto lleno de material intermedio hace peor trabajo. Los subagentes son, sobre todo, una herramienta de higiene.

Multiagente: varios roles y un orquestador

Un sistema multiagente son varios agentes con roles distintos, coordinados normalmente por un orquestador que reparte el trabajo y junta los resultados. Un agente busca fuentes, otro verifica que las cifras cuadran, otro redacta.

Suma cuando las subtareas son de verdad independientes y cada rol necesita un foco muy distinto. La señal a buscar es esa: piezas que apenas se hablan entre sí. Y cuesta siempre, porque coordinar cuesta: cada agente extra suma tokens, latencia y un punto más donde uno puede malinterpretar a otro. Con dos lo controlas; con siete pasas más tiempo depurando quién entendió mal a quién que resolviendo el problema.

La regla que uso: los menos que resuelvan. No es una preferencia estética, es que cada traspaso entre agentes es un sitio donde se pierde información.

Para compartirCasi nadie llega a los subagentes por el motivo correcto. No son para hacer cinco cosas a la vez: son para que el trabajo sucio no ocupe el contexto del agente principal.

Cómo fallan los agentes

Un agente no falla como falla el software normal. El software se rompe y lo sabes: hay un error, una traza, algo que no se ejecuta. Un agente entrega algo plausible y sigue adelante. Estos son los cuatro modos de fallo que aparecen una y otra vez.

Los cuatro modos de fallo de un agente y su freno: alucinación (afirma con seguridad algo falso) se frena con fuentes citadas y revisión humana; bucles (da vueltas sin avanzar) con límite de pasos y corte por tiempo; coste (cada vuelta son tokens) con tope de gasto por ejecución; latencia (varios pasos tardan) eligiendo si el caso va en directo o en diferido. Ninguno se arregla con un modelo mejor

Alucinación. El modelo rellena huecos: inventa una cifra, atribuye una cita a quien no la dijo, "detecta" un patrón que no está en los datos. Lo peligroso es el tono, porque lo falso suena igual de seguro que lo cierto. Se frena obligando a citar la fuente de cada afirmación y poniendo revisión humana donde el coste de equivocarse es alto.

Bucles. El agente intenta algo, no le sale, lo vuelve a intentar casi igual, y otra vez. El bucle se atasca porque observa mal y no cambia de estrategia. Cada vuelta cuesta dinero y no mejora el resultado. Se frena con un límite de pasos y un corte por tiempo, decididos de antemano.

Coste. Un agente no es una llamada, son muchas: leer, razonar, usar herramientas, volver a razonar. Un agente mal acotado puede costar diez veces lo que costaría bien diseñado. Y el coste no se ve en la demo (un café), se ve en la factura de fin de mes multiplicada por cada ejecución.

Latencia. Lo mismo, en tiempo. Un chatbot responde en segundos; un agente que da ocho pasos y llama a tres herramientas puede tardar minutos. Para un proceso en segundo plano da igual. Para un agente que atiende a un cliente en directo, esos minutos son la diferencia entre útil e inservible.

Ninguno de los cuatro se arregla con un modelo mejor. Se arreglan con límites que alguien decide y escribe.

Los guardarraíles: quién decide qué

Un guardarraíl no es una restricción técnica: es una decisión de negocio hecha explícita. Tres son suficientes para empezar.

El humano en el bucle. Antes de montar nada hay que decidir en qué acciones el agente pide confirmación y en cuáles no. Esa decisión sale del coste de equivocarse: leer un documento y responder mal produce una respuesta mala; enviar un correo, borrar un registro o hacer un pago produce un problema real. Por eso las herramientas de lectura se dan con libertad y las de acción se dan una a una.

Los límites duros. Máximo de pasos por ejecución, tope de gasto, tiempo máximo. Son la red que evita que un fallo de bucle se convierta en una factura. Un agente sin límite de pasos es un agente que puede girar indefinidamente.

Las credenciales acotadas. El agente actúa con permisos de alguien. Si le das las credenciales de un administrador, tienes un administrador automático que a veces alucina. Lo que corresponde es una identidad propia, con acceso solo a lo que necesita, y un registro de lo que hizo.

Sobre este punto conviene ser directo, porque es donde más veces he visto que se salta el paso: un agente con permisos amplios y sin registro no es un riesgo teórico, es un incidente pendiente de fecha. Si tu organización aún no tiene una política de uso de IA, en legalidad de la IA en la empresa está el marco y en la plantilla de política de uso el punto de partida.

Para compartirUn guardarraíl no es una restricción técnica: es una decisión de negocio escrita. Qué puede tocar el agente sin preguntar, cuánto puede gastar y quién responde si se equivoca.

Cómo se sabe si funciona: evals y observabilidad

Aquí está la diferencia más grande entre una demo y un sistema.

Evals: el detector de regresiones

Una eval es un criterio sobre el comportamiento del agente, escrito de forma que se pueda ejecutar solo, tantas veces como haga falta, y que devuelve un veredicto o una nota. Es la versión ejecutable y repetible de "esto está bien hecho".

Y hace falta por un motivo que sorprende a casi todo el mundo: un agente se rompe aunque nadie lo toque. El proveedor actualiza el modelo, alguien añade una herramienta nueva, el repositorio crece y lo que antes cabía en contexto ya no cabe, una dependencia cambia sus mensajes de error y el agente los interpreta distinto. El comportamiento cambia sin que se haya modificado nada suyo.

Por eso las evals no son un examen final que se pasa una vez: son el detector de regresiones que se ejecuta cada vez que algo cambia. Sin ellas, la primera noticia de que el agente ha empeorado la da un cliente.

Observabilidad: poder reconstruir qué pasó

Cuando un agente hace algo raro, la pregunta es siempre la misma: ¿qué vio, qué decidió y por qué? Responderla exige haber guardado la traza de cada ejecución: qué entró, qué herramientas usó, qué devolvieron, cuántos pasos dio, cuánto costó y cómo terminó.

No es un volcado de todo. Es un puñado de campos que permiten reconstruir la historia después. Y un panel corto: cinco cifras que se miran una vez por semana en cinco minutos (cuántas ejecuciones, cuántas fallaron, coste medio, latencia, cuántas necesitaron intervención humana) valen más que un cuadro de mandos con veinte gráficas que nadie abre.

De la demo a producción

Con lo anterior montado, quedan dos cosas que solo aparecen al multiplicar.

El coste a escala. Lo que en la demo era un café, en producción se multiplica por el número de ejecuciones. La cuenta hay que hacerla antes: coste por ejecución × volumen esperado, comparado con lo que cuesta hacerlo hoy. Si no sale, no sale; y saberlo antes es barato.

El aislamiento. Cuando varios agentes trabajan a la vez sobre las mismas cosas, un fallo puede contaminar al resto. La regla es que cada ejecución trabaje en su propio espacio y que el resultado se integre solo cuando está verificado, no mientras se produce.

Y una consecuencia organizativa que no es técnica pero llega siempre: cuando parte del trabajo lo hace un agente, cambia qué hace la gente. Alguien tiene que revisar, decidir los límites y responder de lo que sale. Eso es trabajo nuevo, no trabajo que desaparece. Es la misma idea de la última milla: la tecnología entra rápido, el rediseño del trabajo va detrás y es lo que decide si hubo impacto.

Qué preguntar antes de aprobar un agente

Si en el primer artículo las preguntas eran sobre las piezas, estas son sobre el comportamiento:

Tema	Pregunta	Lo que revela
Reparto	¿Por qué hay varios agentes y no uno?	Si el reparto responde a subtareas independientes o a una moda cara.
Fallos	¿Qué pasa cuando se equivoca, y cómo nos enteramos?	Si alguien ha pensado en el fallo o solo en el caso feliz.
Límites	¿Cuál es el máximo de pasos, de tiempo y de gasto por ejecución?	Si hay red de seguridad o el sistema puede correr sin freno.
Autonomía	¿Qué acciones ejecuta sin preguntar?	El riesgo real, en una frase.
Evals	¿Cómo sabremos dentro de tres meses que sigue funcionando igual?	Si hay detector de regresiones o se descubrirá por una queja.
Trazas	Si hoy hiciera algo raro, ¿podríamos reconstruir por qué?	Si es auditable o es una caja negra.
Coste	¿Cuánto cuesta una ejecución, y cuánto multiplicado por el volumen real?	Si el caso se sostiene fuera de la demo.
Permisos	¿Con qué credenciales actúa y qué alcance tienen?	El tamaño del incidente posible.

Las dos últimas filas son las que más veces se quedan sin respuesta, y son las dos que se pagan.

Por dónde empezar

Si estás montando el primero, el orden que funciona es corto: elige un caso donde el fallo sea barato, dale solo herramientas de lectura al principio, escribe tres evals antes de que nadie lo use, guarda trazas desde el primer día y pon límites de pasos y gasto aunque parezcan innecesarios. Añadir autonomía después es fácil; quitarla tras un incidente es caro y deja huella.

Y una recomendación de fondo: no empieces por el caso más ambicioso. Empieza por el que te permita aprender cómo falla tu organización con un agente, que es lo que de verdad no sabes todavía.

Preguntas frecuentes

¿Cuándo conviene usar varios agentes en lugar de uno? Cuando las subtareas son de verdad independientes y cada rol necesita un foco distinto, de forma que puedan ir en paralelo sin hablarse mucho. Si los pasos van encadenados y cada uno necesita el anterior, un solo agente bien diseñado hace mejor trabajo y cuesta menos. La regla práctica: los menos agentes que resuelvan.

¿Qué es un subagente y para qué sirve de verdad? Es un agente al que otro le encarga una tarea acotada; trabaja en su propio contexto y devuelve solo el resultado. Su beneficio principal no es el paralelismo, sino aislar el contexto: evita que el material intermedio de una tarea ocupe la ventana del agente principal y empeore el resto del trabajo.

¿Qué es una eval de un agente de IA? Un criterio sobre el comportamiento del agente, escrito para poder ejecutarse solo tantas veces como haga falta y devolver un veredicto. Sirve como detector de regresiones, porque un agente cambia de comportamiento aunque nadie lo modifique: basta con que cambie el modelo, una herramienta o el volumen de datos.

¿Cómo se controla el coste de un agente de IA? Con un tope de gasto y un límite de pasos por ejecución, midiendo el coste real por ejecución y multiplicándolo por el volumen esperado antes de escalar. El coste de un agente no se ve en la demo: aparece en la factura mensual multiplicado por cada uso.

¿Qué permisos hay que dar a un agente? Los mínimos para su tarea, con identidad propia y registro de lo que hace. Las herramientas de lectura pueden darse con libertad; las que actúan (enviar, borrar, pagar, publicar) se conceden una a una y con el nivel de autonomía decidido para cada una.

¿Qué es la observabilidad de un agente? Guardar la traza de cada ejecución (qué entró, qué herramientas usó, qué devolvieron, cuántos pasos dio, cuánto costó y cómo acabó) para poder reconstruir después qué pasó. Sin traza, un comportamiento raro es imposible de diagnosticar.

Si quieres decidir si un caso concreto merece un agente antes de entrar en todo esto, el árbol de decisión está en ¿Cuándo un agente de IA aporta valor de verdad?. Y si prefieres empezar construyendo, tu primer agente sin programar recorre Pulso de principio a fin.

FormaciónEsta segunda parte es el contenido de Agentes de IA en producción: repartir trabajo y subagentes, evals y observabilidad, permisos y credenciales, coste y fallos a escala. Si aún no tienes la base, empieza por Introducción a los agentes de IA, donde se construye el agente completo sin programar. Y si la IA todavía es terreno nuevo en tu organización, el gratuito Fundamentos de IA en la práctica es el punto de partida.

Recursos relacionados