Arquitectura

En las últimas semanas he visto en LinkedIn comparaciones como «agentes vs. MCP», «skills vs. MCP» o «tools vs. MCP», como si fueran alternativas equivalentes. En bastantes de esos posts, me da la impresión de que se mezclan conceptos y se publica texto generado con IA sin revisarlo, lo que termina confundiendo a quien busca entenderlos.

Como diría el gran Javier Menéndez Pallo: «Ahora LinkedIn está lleno de expertos en IA; parece que das un paso y aplastas a un experto en IA». El chiste me hace gracia, aunque la confusión que señala no tanto. Estos conceptos tienen límites a veces difusos, pero algunas reglas nos ayudan a distinguirlos. Por eso escribo este artículo: tras explicar agentes, skills y subagentes, quiero mostrar cómo se combinan y dónde poner los límites.

Te piden automatizar la gestión de devoluciones. La primera propuesta suele sonar muy bien en una demo: «Dale un agente acceso al correo, al sistema de pedidos y a la API de reembolsos. Que lea la solicitud y resuelva el caso».

También puede salir bien. Hasta que el agente interpreta mal una política, encuentra dos pedidos parecidos y devuelve el dinero del equivocado. La pregunta importante no es si podemos construir ese agente. Es si necesitamos darle tanta libertad para resolver el problema.

El 28 de octubre GitHub anunció la disponibilidad general de Copilot Fusion. En vez de escoger un modelo para cada tarea, eliges Fusion y el sistema decide qué modelos y patrones de ejecución utilizar. La documentación de GitHub describe opciones como resolver con un modelo, escalar una respuesta para que otro la revise o generar una respuesta y pedir a otro modelo que la critique.

El modelo sigue importando, pero cambia la pregunta. Durante estos últimos años hemos comparado nombres y versiones: ¿cuál razona mejor?, ¿cuál escribe mejor código?, ¿cuál tiene más contexto? Ahora aparece otra pregunta, más arquitectónica: ¿qué sistema decide cómo usar modelos, datos y herramientas para completar el trabajo?

En un artículo anterior sobre qué es un harness y dónde vive, expliqué por qué dos herramientas con el mismo modelo pueden comportarse de forma distinta. Aquí quiero dar un paso más: ¿qué cambia cuando el propio sistema empieza a elegir y combinar modelos?

Cuando comparamos herramientas de IA solemos empezar por el modelo. Que si este modelo razona mejor, que si aquel tiene más contexto, que si el nuevo benchmark lo coloca tres puntos por encima del anterior. Es lógico: el nombre del modelo es la parte visible, la que aparece en la documentación, en los selectores y, por supuesto, en el marketing.

Pero hay una pregunta que cada vez me parece más importante: cuando dos herramientas utilizan el mismo modelo y producen resultados muy diferentes, ¿qué estamos comparando realmente?

La respuesta corta es que no estamos usando solo un modelo. Estamos usando un sistema completo alrededor de él: instrucciones, contexto, memoria, herramientas, permisos, formatos de entrada y salida, bucles de validación, reintentos y condiciones de parada. A ese andamiaje se le suele llamar harness.

Y ese harness puede convertir un modelo competente en una herramienta muy útil o en un compañero que lleva veinte minutos leyendo archivos irrelevantes con una seguridad en sí mismo francamente admirable.

La mayoría de demos con agentes funcionan muy bien hasta que aparece el primer problema real: hay que persistir contexto, exponer capacidades por HTTP, desacoplar eventos, aguantar reinicios y, además, mantener el sistema operable por un equipo backend normal.

Ahí es donde Dapr Agents resulta interesante. No tanto por la palabra “agent”, sino porque aterriza el problema sobre piezas de plataforma que ya conocemos: state stores, pub/sub, workflows, APIs y sidecars.

En este artículo voy a contar cómo encaja esa idea en un proyecto real: D&D Copilot, un juego conversacional con backend en ASP.NET Core, frontend en React y una capa de NPCs que ya adopta varios conceptos de Dapr Agents aunque la aplicación esté implementada en .NET.