Una especialidad puede necesitar instrucciones y acceso a herramientas, o requerir autonomía y contexto propio. Separar esas necesidades ayuda a decidir cuándo incorporar otro agente y cuándo basta con cargar una skill en el orquestador.
El patrón documentado
Tommaso Stocchi publicó el 16 de septiembre de 2026 una comparación entre agentes especialistas y skills distribuidas mediante MCP. El ejemplo mantiene servicios separados y lleva las instrucciones del especialista al orquestador, junto con acceso a sus operaciones.
En tres pares de ejecuciones, el camino de skills empleó menos llamadas al modelo y presentó menor latencia observada, pero consumió aproximadamente un 22 % más de tokens totales. Las diferencias de caché, inicialización y trabajo realizado impiden atribuir el resultado únicamente a la arquitectura. El artículo tampoco demuestra menor costo facturable ni calidad equivalente. Artículo original y limitaciones del experimento.
Una decisión basada en responsabilidades
| Necesidad | Alternativa a evaluar | Pregunta de control |
|---|---|---|
| Procedimiento acotado con herramientas conocidas | Skill en el orquestador | ¿Puede resolverse con instrucciones y resultados tipados? |
| Autonomía y ciclo de trabajo independiente | Agente especialista | ¿Necesita decidir y progresar sin intervención continua del orquestador? |
| Contexto o permisos propios | Servicio o agente con frontera explícita | ¿Dónde se valida la autorización y qué información cruza la frontera? |
| Proceso determinista | Herramienta o workflow convencional | ¿Aporta valor introducir razonamiento del modelo? |
Estos criterios son una propuesta de evaluación. Una skill no constituye por sí misma una frontera de seguridad: disponer de instrucciones para una operación no concede permiso para ejecutarla.
Cómo reproducir y adaptar el ejemplo
El repositorio del autor contiene un escenario de estación de esquí, proveedores MCP .NET, orquestación Python y ejecución con Aspire. Es una demostración, no una integración terminada con D365FO. Para reproducir los resultados del artículo debe utilizarse el commit 56f453a indicado por el autor y seguir sus requisitos, en lugar de asumir que la rama principal conserva el mismo comportamiento.
La adaptación propuesta para un asistente de documentación consiste en limitar la primera prueba a documentos públicos o sintéticos y una consulta de lectura. El despliegue inicial puede realizarse en un ambiente aislado, con credenciales de desarrollo y registro de versiones.
Qué medir
- Preparar las mismas preguntas, documentos y respuestas esperadas para ambos diseños.
- Evaluar exactitud, citas y comportamiento cuando falta información.
- Separar pruebas con caché fría y caliente.
- Medir latencia y consumo de todo el sistema, incluidos especialistas y herramientas.
- Registrar fallos, reintentos, rechazos de permisos e instrucciones maliciosas en documentos.
- Calcular costo con las tarifas efectivas de cada tipo de token y servicio.
Un criterio de aceptación útil exige calidad comparable y mejora medible en una dimensión prioritaria, sin pérdida de autorización ni trazabilidad. Una respuesta rápida pero incompleta no supera ese criterio.
Condiciones para reutilizar
No quedó confirmada una licencia explícita de reutilización del repositorio durante esta revisión. Antes de incorporar código a un producto debe aclararse ese punto. También deben verificarse las API experimentales, la compatibilidad de los proveedores y la retención de trazas. Los modelos y recursos Azure tienen sus propios requisitos de acceso y consumo.
Recomendación: probar el patrón en una tarea pequeña y medible. Mantener el caso en evaluación hasta disponer de evidencia funcional y condiciones claras para reutilizar su implementación.