Por Grego
Durante buena parte de la carrera de los coding agents discutimos la variable más visible: el modelo. Claude contra GPT, DeepSeek contra Gemini, open weights contra APIs propietarias. Pero si algo dejaron claro los últimos meses es que el modelo explica solamente una parte de cómo se comporta un agente.
El resto vive alrededor.
El agent loop. Las tools. La memoria. Cómo se construye el contexto. Cómo se persiste una sesión. Qué ocurre después de un tool call. Cuándo el agente vuelve a razonar y cuándo decide que terminó.
Todo eso forma el harness.
Y el 13 de agosto DeepSeek hizo una apuesta bastante interesante sobre esa capa: publicó DeepSeek Harness (dsh), un framework open source bajo licencia MIT cuyo principio arquitectónico central puede resumirse en cuatro palabras:
Everything is a Plugin.
No es solamente marketing. En dsh, incluso el propio agent loop puede reemplazarse.
Eso convierte al proyecto en algo bastante diferente de otro clon open source de Claude Code.
Primero: qué es exactamente un agent harness
Un modelo por sí solo no es un coding agent.
Podés darle código a un LLM y pedirle que genere un patch. Pero para que ese modelo pueda inspeccionar un repositorio, ejecutar comandos, leer resultados, modificar archivos, correr tests, volver a razonar y decidir qué hacer después necesitás una capa que coordine todo ese proceso.
Simplificando, el loop se parece a esto:
usuario
↓
modelo
↓
decide usar una tool
↓
runtime ejecuta la tool
↓
resultado vuelve al modelo
↓
modelo vuelve a razonar
↓
otra tool / respuesta final
Claude Code tiene uno.
Codex tiene uno.
Cursor tiene uno.
OpenCode tiene uno.
Y cada vez hay más evidencia de que las diferencias entre esos harnesses pueden ser tan importantes como las diferencias entre los modelos que corren adentro.
DeepSeek Harness lleva esa idea un paso más lejos: en vez de darte un harness monolítico que podés configurar, intenta convertir las piezas fundamentales del harness en componentes intercambiables.
“Everything is a Plugin”
La arquitectura de dsh está construida sobre Cordis, un framework modular basado en servicios y plugins.
DeepSeek divide el sistema en componentes que pueden registrarse y reemplazarse.
Entre ellos:
- adaptadores de modelos;
- registro y ejecución de tools;
- persistencia de sesiones;
- interfaces;
- capacidades adicionales;
- y el agent loop.
Ese último punto es el importante.
En muchos frameworks podés agregar tools al agente. Podés cambiar el modelo. Quizás podés conectar una implementación distinta de memoria.
Pero llega un punto donde tocás el núcleo del framework: así es como nuestro agente piensa y ejecuta; si querés otra cosa, empezá a modificar internals.
DeepSeek está intentando eliminar esa frontera.
El loop también es un plugin.
Por qué querrías reemplazar el agent loop
Porque no todos los agentes deberían trabajar igual.
Imaginá un coding agent sencillo. Puede usar un loop estilo ReAct:
razonar
→ ejecutar tool
→ observar
→ razonar
→ ejecutar tool
→ observar
Perfectamente razonable para muchas tareas.
Pero quizás estás construyendo un agente de code review y querés otra arquitectura:
analizar diff
→ buscar contexto
→ generar hipótesis
→ verificar cada hipótesis
→ descartar falsos positivos
→ producir review
O un agente para migraciones:
planificar
→ crear checkpoint
→ modificar módulo
→ ejecutar tests
→ verificar
→ continuar
→ rollback si falla
O quizás querés un sistema donde varios agentes trabajen en paralelo y un supervisor decida qué resultados aceptar.
Esos no son simplemente prompts diferentes.
Son loops diferentes.
Si el loop está hardcodeado dentro del framework, construirlos implica pelearte con el framework.
Si el loop es un plugin, se convierte en una decisión arquitectónica explícita.
Ahí está la parte realmente interesante de dsh.
El modelo también deja de ser el centro
El mismo principio aplica al provider.
Un model adapter es otro plugin.
Eso significa que la arquitectura no necesita estar conceptualmente casada con DeepSeek. Podés construir un profile donde el modelo sea una pieza sustituible del sistema, de la misma manera que cambiás una implementación de almacenamiento o una herramienta.
Esa separación importa especialmente para equipos que están construyendo infraestructura de agentes.
Durante los últimos dos años vimos demasiados sistemas donde la arquitectura completa termina reflejando las peculiaridades del API del proveedor elegido al principio.
Después aparece un modelo mejor o más barato y migrar resulta mucho más difícil de lo esperado.
Un harness realmente modular cambia esa relación:
Agent
├── Model Adapter
├── Tool Registry
├── Session
├── Agent Loop
├── Interface
└── Plugins propios
El modelo sigue siendo importantísimo.
Pero deja de ser la arquitectura.
Profiles y bundles: componer en lugar de forkear
Otra idea útil de dsh es separar la composición del agente del código del framework.
Los profiles describen qué combinación de componentes querés ejecutar.
Los bundles permiten agrupar conjuntos de plugins y configuraciones reutilizables.
Conceptualmente, esto permite tener algo como:
coding-agent
model
filesystem
git
terminal
coding-loop
security-agent
model
filesystem-readonly
scanner
security-loop
review-agent
model
git
diff-analyzer
review-loop
Todos pueden compartir la misma infraestructura sin convertirse en un único “super agente” lleno de condicionales.
Para platform teams, esta separación es especialmente atractiva.
En lugar de mantener forks distintos del runtime, mantenés composiciones distintas.
Cómo probarlo
DeepSeek Harness está publicado como proyecto open source y actualmente se encuentra en developer preview.
El repositorio oficial es:
deepseek-ai/deepseek-harness
La documentación del proyecto incluye el setup actualizado y ejemplos para levantar el harness y trabajar con sus profiles y plugins.
Y acá conviene respetar una advertencia del propio DeepSeek: esto todavía no es un framework estable de producción.
La API puede cambiar.
Los plugins pueden romper compatibilidad.
La estructura de configuración puede evolucionar.
Si lo vas a probar hoy, pensalo como una oportunidad para entender la arquitectura y construir experimentos, no como una dependencia que necesariamente quieras congelar inmediatamente dentro de infraestructura crítica.
El ecosistema ya empezó a aparecer
Quizás la señal más interesante llegó después del lanzamiento.
En apenas días comenzaron a aparecer proyectos comunitarios alrededor de dsh: plugins adicionales, interfaces, integraciones con containers y directorios para descubrir extensiones.
Es demasiado temprano para declarar que existe un ecosistema maduro.
Pero sí demuestra algo importante sobre la arquitectura.
Cuando un proyecto declara que “todo es un plugin”, la prueba real no está en el README. Está en si terceros pueden construir cosas interesantes sin modificar el core.
Las primeras señales indican que eso está ocurriendo.
Esto no significa que DeepSeek haya “resuelto” los agentes
Hay que separar una arquitectura interesante de un producto terminado.
DeepSeek Harness está en developer preview. Claude Code, Codex, Cursor y otros productos llevan muchísimo más tiempo acumulando optimizaciones alrededor de retrieval, tool use, permisos, sandboxing, context management, UX y comportamiento del agente.
Una arquitectura más abierta no implica automáticamente un agente mejor.
De hecho, la modularidad tiene un costo.
Cuantas más piezas permitís sustituir, más combinaciones necesitás probar. Un plugin puede asumir comportamientos que otro no garantiza. Dos loops distintos pueden requerir interfaces diferentes. La observabilidad y debugging se vuelven más importantes.
La flexibilidad arquitectónica siempre compra libertad a cambio de complejidad.
Pero dsh no necesita ganarle hoy a Claude Code como producto para resultar interesante.
La apuesta está en otro lugar.
El harness se está convirtiendo en el producto
Hace dos años, muchas herramientas de AI coding podían describirse aproximadamente así:
UI bonita
+
API de un frontier model
Eso cambió.
Los productos más avanzados ahora tienen enormes cantidades de ingeniería alrededor del modelo: context retrieval, memory, sandboxes, tool orchestration, subagents, permission systems, compaction, hooks, skills y loops especializados.
El modelo se está convirtiendo progresivamente en un componente dentro de una máquina mucho más grande.
DeepSeek Harness lleva esa conclusión hasta su extremo lógico:
si el harness importa tanto, hacelo programable.
Y si realmente querés hacerlo programable, no alcanza con permitir que alguien agregue una tool.
Tenés que permitirle cambiar cómo funciona el agente.
Por qué esto importa para equipos en Iberoamérica
Hay un ángulo especialmente interesante para los equipos que no quieren construir toda su infraestructura alrededor de un único proveedor.
Un harness abierto y modular permite experimentar con combinaciones distintas de modelos, tools y runtimes sin empezar de cero cada vez.
Eso puede significar usar un modelo comercial para determinadas tareas, un modelo open-weight self-hosted para otras y loops especializados para workloads donde el comportamiento importa más que la inteligencia general.
No todos los equipos necesitan construir su propio coding agent.
Probablemente la mayoría no debería.
Pero las empresas que sí están construyendo agentes internos —para ingeniería, operaciones, seguridad, soporte o workflows específicos de negocio— empiezan a necesitar exactamente este tipo de abstracción.
No un chatbot.
No otro wrapper.
Una capa de ejecución de agentes que puedan controlar.
La señal que vale la pena seguir
Durante mucho tiempo preguntamos:
¿Qué modelo usa tu agente?
Después empezamos a preguntar:
¿Qué tools tiene?
La pregunta siguiente probablemente sea:
¿Qué harness corre debajo?
DeepSeek parece haber llegado a esa conclusión temprano.
dsh todavía es joven, experimental y probablemente va a cambiar bastante. Pero la idea detrás del proyecto es mucho más importante que su versión actual.
DeepSeek no open-sourceó simplemente otro coding agent.
Open-sourceó las piezas con las que podés construir el tuyo.
Y cuando hasta el agent loop se convierte en un plugin, el modelo deja definitivamente de ser el único lugar donde ocurre la innovación.