Uno no es suficiente, así trabajan los equipos de agentes

Contar personas en un streaming las 24 horas con un modelo gigante de lenguaje funciona, pero es matar moscas a cañonazos: pagas una capacidad que no usas y encima el resultado es peor que el de un modelo pensado para eso. Esa idea fue el hilo de la charla que dieron nuestros compañeros Javier Carnero y Rodrigo Cabello, del equipo de innovación (R&D) de Plain Concepts, el miércoles 30 de septiembre en Espacio RES (Sevilla), en un encuentro organizado por la comunidad IA Generativa Sevilla con la colaboración de SevillaDotNET. Allí explicaron cómo se monta un equipo de agentes de IA que trabajan juntos.

Aquí repasamos lo que contaron: qué es un agente de verdad, cuándo hace falta un coordinador, tres demos con visión por computador y 3D, y cómo probarlo todo sin volverte loco. Y si prefieres escucharlo de primera mano, te invitamos a ver la charla completa.

Un agente es un modelo, unas instrucciones de sistema, unas herramientas y una memoria. Las herramientas son los datos que consulta (con RAG, por ejemplo), las acciones que puede ejecutar y los conectores con otros sistemas. El modelo tampoco tiene que ser de texto: puede ser uno de visión-lenguaje, que mira una imagen y razona sobre ella.

Montar un agente sencillo con habilidades propias lleva pocas líneas de Python con Microsoft Agent Framework, que es open source, conectado a un modelo local en Ollama. Después lo integras en la aplicación que quieras, sea Python o C#.

Ahora lo incómodo. Los sistemas agénticos no son deterministas, alucinan, y en producción los costes se disparan si los montas sin criterio. La automatización clásica sigue siendo válida, y lo sensato es combinarla con los agentes en lugar de jubilarla.

Cuando la tarea es visual (detectar, segmentar o contar objetos, o sacar un objeto 3D de una foto) los modelos específicos de computer vision dan más calidad y cuestan mucho menos. Hasta Karpathy o LeCun admiten que los LLM basados en tokens de texto se quedan cortos para entender el espacio.

Los LLM siguen siendo la herramienta para lo suyo, que es conversar, interpretar instrucciones y decidir qué toca hacer a continuación. Nosotros repartimos el trabajo para que cada modelo haga aquello en lo que rinde mejor. Un modelo pequeño, de tipo clasificador o JEPA, encaja muy bien en el triaje y en las decisiones de orquestación, donde nadie necesita que se escriba un ensayo.

En cuanto hay varios agentes toca decidir quién manda. Estos son los tres patrones que hemos probado.

• Secuencial. La salida de un agente es la entrada del siguiente. Es determinista y se sigue bien. Nuestra recomendación número uno es empezar siempre aquí y complicar el diseño solo cuando el camino feliz funcione.
• Group chat con coordinador central. Das más control, pero el coordinador lee todo lo que pasa y gasta más tokens.
• Handoff. Cada agente decide a quién pasa el testigo, sin coordinador. Con la misma tarea gastó claramente menos tokens que el group chat, y lo medimos con telemetría y trazas. A cambio cuesta más controlarlo, a veces pide modelos más potentes y rinde mejor cuando las responsabilidades de cada agente están bien separadas.

Un consejo práctico: monta primero el flujo en group chat y pasa después a handoff, porque en código el cambio es pequeño. Existen más patrones (red, supervisor, jerárquico o a medida), pero estos tres bastan para empezar.

Y un detalle que ahorra dinero. El contexto que el framework comparte entre agentes no es lo mismo que lo que se envía al LLM, así que conviene mandar solo lo necesario: ahorras tokens, ventana de contexto y presupuesto.

La primera es de vídeo. Montamos un flujo handoff con un agente de triaje, uno de comprensión de vídeo (un modelo visión-lenguaje en Azure Foundry) y otro de manipulación de vídeo, que usa un modelo pequeño en local con Foundry Local, una skill de FFmpeg y acceso a Blob Storage. El encargo era elegir el fotograma más representativo de un vídeo y guardarlo como captura. Funcionó: el agente decidió el momento, llamó a FFmpeg con los parámetros y dejó la imagen en el almacenamiento. Para depurar usamos la web de desarrollo del framework, que dibuja el grafo de agentes.

La segunda parte de un caso de cliente. Nos manda la foto de un sofá de su catálogo y quiere verlo en 3D en su web. El triaje pasa el testigo al agente de segmentación: Grounding DINO localiza «un sofá» a partir de lenguaje natural y devuelve la caja, y SAM la convierte en una máscara exacta. Ese servicio va desplegado como API en Azure Container Apps con GPU T4 y descrito con OpenAPI, de modo que el agente lo usa como una herramienta más. Después entra el agente 3D, con SAM 3D y un ajuste ligero para varios objetos, también en Container Apps, con un volumen para los pesos y scale to zero, así que se apaga cuando nadie lo usa. Cierra un agente web con Gemma en local vía Ollama, compatible con el contrato de OpenAI, que genera una web estática con el visor 3D y la sube a un storage para que puedas dar la vuelta al sofá.

El resultado es más fiel y mucho más barato que pedirle el GLB directamente a un LLM generalista, que lo que hace es escribir un script que genera la malla y no entiende el asset 3D.

La tercera va de mundos. Con Open Code, skills y subagentes, partimos de una imagen y generamos un mundo 3D navegable con World Labs (gaussian splatting), detectamos los objetos más representativos, los generamos con SAM 3D y les añadimos colisiones: sillas, bancos, farolas, cubos de basura, calles, habitaciones. Los LLM actuales entienden bien una imagen para casos puntuales, pero en el resultado fino mandan los modelos de visión específicos. Y en dominios muy concretos, como maquinaria industrial o un modelo de farola determinado, toca ajustar con ejemplos, porque el SAM 3D genérico flojea.

En un agente parte del comportamiento se programa en texto, y escribir a mano las instrucciones y las tools da peor resultado que partir de tests de comportamiento. Pides, por ejemplo, «dame el primer fotograma de este vídeo», compruebas que lo devuelve y vas iterando las instrucciones hasta que el test pasa, como en TDD. Vigila que el modelo no haga trampa colando instrucciones específicas para ese test.

Estos tests tienen premio extra: puedes cambiar de modelo o de versión del framework sin miedo, y también puedes probar workflows enteros.

Para el resto, tira de enfoque híbrido. Pon puntos de aprobación humana o de equipo (human in the loop), hooks antes de acceder a datos sensibles y tests automáticos después de generar código. Y no des nunca a un agente un sandbox sin límites.

Creemos que un equipo de agentes especializados rinde mejor que un único modelo gigante, igual que mandas a estudiar a personas distintas disciplinas distintas. Lo vemos por coste, por el límite de contexto, por seguridad (modelos propios para tu negocio y datos que no salen de casa) y por energía.

Los modelos irán mejorando y a veces uno sustituirá a dos: Grounding DINO más SAM pasó a ser SAM 3 a secas. Cambiará una pieza y la arquitectura se mantendrá.

Si quieres probarlo, empieza con un flujo secuencial de dos o tres agentes y un test de comportamiento que defina qué significa «funciona». Cuando el camino feliz pase, mide el gasto de tokens y solo entonces plantéate un handoff.