↓Ir al contenido
  1. Categories/

Arquitectura

2026


El modelo no trabaja solo: por qué el harness importa tanto como la IA

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.

Dapr Agents en un juego conversacional con .NET: llevando D&D Copilot de demo a sistema distribuido

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.