Harness unificado para coding agents: 4 patrones 2026

TL;DR: El mercado de agentes de código converge hacia harnesses unificados capaces de orquestar Claude Code, Codex, VS Code Agents o modelos locales bajo la misma interfaz. Extraigo 4 patrones (contexto aislado, herramientas declarativas, ejecución sandbox y memoria explícita) que puedes copiar hoy en tu setup de Claude Code sin esperar a que tu equipo migre de herramienta.

Contexto del Problema: Cada Agente su Propio Mundo

Configurar un agente de código serio ya no es solo elegir modelo. En un flujo real mezclas Claude Code en terminal, Codex para tareas largas, VS Code Agents para el editor y, a veces, un modelo local para cosas sensibles. Cada uno con su formato de configuración, su gestión de permisos y su manera de manejar contexto.

La señal de 2026 es clara: VS Code anunció una experiencia unificada para todos los coding agents, OpenAI lanzó la siguiente evolución del Agents SDK y repositorios como oh-my-openagent empaquetan varios harnesses bajo una única capa. El patrón que emerge no es nuevo framework, es estructura compartida.

El problema práctico: si tu flujo depende de prompts sueltos y configuraciones ad-hoc, cada migración entre herramientas te cuesta días. Un harness unificado no elimina ese coste, pero lo reduce a editar cuatro capas bien delimitadas.

¿Qué es un Harness para Coding Agents?

Un harness es la capa que envuelve al modelo: gestiona el prompt del sistema, las herramientas disponibles, la ejecución de código, la memoria entre turnos y los límites de seguridad. El modelo decide; el harness ejecuta y recuerda.

Cuando el harness es unificado, esas responsabilidades están separadas de la herramienta concreta. Puedes cambiar Claude Code por Codex y solo tocas el adapter de modelo. El resto (skills, memoria, permisos) permanece.

Según el proyecto Everything Claude Code, la separación por capas reduce la superficie de error cuando el agente trabaja en tareas largas. En mi experiencia con separación de responsabilidades en arquitectura de software, el principio es el mismo: cada capa tiene una razón única para cambiar.

Patrón 1: Contexto Aislado por Tarea

Idea clave: el agente no necesita ver todo tu repositorio. Necesita ver lo relevante para la tarea actual. Los harnesses unificados introducen un gestor de contexto que decide qué archivos se cargan por turno.

En Claude Code esto se traduce en un CLAUDE.md minimalista más skills específicas por tarea. En Codex, se parece a sus subagentes locales. En VS Code Agents, es el workspace selector.

{
  "name": "context-loader",
  "scope": "task",
  "include": ["src/**/*.py", "tests/**/*.py"],
  "exclude": ["**/node_modules/**", "**/.venv/**"],
  "max_tokens": 8000
}

El efecto en producción es directo: menos tokens por turno, menos alucinaciones por contexto irrelevante y tiempos de respuesta más predecibles.

Patrón 2: Herramientas Declarativas y Versionadas

Idea clave: las herramientas que el agente puede usar no viven en el prompt, viven en archivos versionados. Los harnesses unificados copian esto del enfoque que ya aplica el ecosistema de skills y subagentes reutilizables.

En la práctica, cada herramienta es un archivo declarativo con su schema, su descripción y sus límites. El harness lo carga cuando el agente lo necesita, no antes.

Enfoque	Dónde vive	Versionado	Reutilizable
Prompt suelto	Conversación	No	No
Tool inline	Código del harness	Parcial	Dentro del proyecto
Skill declarativa	Archivo YAML/JSON	Sí (git)	Entre proyectos y equipos

Un detalle honesto: no todas las skills se comparten bien entre Claude Code y Codex todavía. El formato SKILL.md es compatible, pero las herramientas expuestas dependen del runtime. A 23/04/2026 el estándar todavía no cubre el 100%.

Patrón 3: Ejecución Sandbox con Permisos Explícitos

Idea clave: el agente ejecuta código en un entorno aislado con permisos declarados. Nunca acceso abierto al sistema.

El harness unificado separa tres cosas que suelen mezclarse:

Qué comandos puede ejecutar el agente (allowlist explícita)
Dónde los ejecuta (contenedor, worktree, VM ligera)
Qué puede ver del sistema de archivos y red

Un ejemplo en configuración Python con un adapter sobre el Agents SDK:

# Declaramos permisos de ejecución antes de lanzar el agente
from harness import Sandbox, ToolRegistry

sandbox = Sandbox(
    allowed_commands=["pytest", "ruff", "git status"],
    workdir="/tmp/agent-workspace",
    network=False,
    max_runtime_seconds=120,
)

tools = ToolRegistry.load("./skills/")
agent = sandbox.run(model="claude-opus-4-7", tools=tools)

Este patrón conecta directamente con el enfoque defensivo frente a paquetes falsos en MCP: si el sandbox limita la red, un paquete malicioso no filtra nada aunque se instale.

Patrón 4: Memoria como Capa Explícita

Idea clave: la memoria del agente no es el historial del chat. Es una capa separada, consultable y con permisos propios.

Los harnesses unificados de 2026 incorporan memoria persistente con observabilidad. Proyectos como GrayMatter reportan reducciones de uso de tokens cercanas al 97% al evitar recargar contexto repetido. La cifra depende del flujo, pero el orden de magnitud se mantiene.

Un patrón práctico que uso en Claude Code a través de plugins de memoria MCP que salvan sesiones:

Memoria de usuario: preferencias estables (estilo de commits, stack, idioma)
Memoria de proyecto: decisiones arquitectónicas, bugs resueltos, convenciones
Memoria de sesión: estado temporal que se descarta al cerrar

El harness decide qué capa consulta según la tarea. El agente no tiene acceso libre a todo el historial.

En Producción

Aplicar estos patrones en un setup real implica trade-offs honestos.

Rendimiento: cargar skills y memoria desde archivos añade latencia inicial (200-500 ms por turno en repositorios medianos). Se compensa con menos tokens gastados en contexto redundante.

Coste: un flujo mal calibrado puede consumir 30-50€ al mes en APIs solo por recargar contexto. Con contexto aislado y memoria explícita, lo he bajado aproximadamente a la mitad en proyectos personales. No es escala enterprise, pero el efecto relativo es el mismo.

Escalabilidad: el patrón funciona bien hasta equipos de 5-10 personas compartiendo skills. Más allá, necesitas gobernanza real sobre quién modifica qué skill y cómo se aprueba. No lo he probado con equipos de más de 15 personas.

Manejo de errores: el harness debe tener una salida cuando el agente entra en bucle. Un timeout de 2-3 minutos por tarea y un límite de turnos (20-30) evita costes descontrolados.

Errores Comunes y Depuración

Error: el agente ignora una skill recién añadida. Causa: el registro de herramientas está cacheado. Solución: reiniciar sesión o forzar recarga del registry.
Error: la memoria crece sin límite. Causa: no hay política de rotación. Solución: definir TTL por tipo de memoria y podar observaciones viejas.
Error: el sandbox bloquea comandos legítimos. Causa: allowlist demasiado estricta. Solución: empezar en modo permisivo registrando qué pide el agente, luego restringir.
Error: el contexto se corta a mitad de tarea. Causa: max_tokens del loader inferior al tamaño real. Solución: dividir la tarea en subtareas con contexto más pequeño.

Preguntas Frecuentes

¿Un harness unificado sirve si solo uso Claude Code?

Sí. Aunque no migres a otras herramientas, separar contexto, skills, sandbox y memoria en capas te da un setup más mantenible. El coste de adoptarlo desde Claude Code puro es bajo y previene bloqueo si decides cambiar en el futuro.

¿Qué diferencia hay entre un harness y un framework de agentes?

Un framework (como CrewAI o LangGraph) define cómo escribir el agente. Un harness define el entorno donde corre cualquier agente: permisos, memoria, herramientas. Puedes tener un framework dentro de un harness, no al revés.

¿Los harnesses unificados sustituyen a MCP?

No. MCP es un protocolo para exponer herramientas y datos al agente. El harness usa MCP u otros protocolos para cargar esas herramientas bajo su gestión de permisos y contexto. Son capas complementarias.

Cierre: Menos Prompts Sueltos, Más Capas Claras

Hemos visto cómo los harnesses unificados empiezan a estandarizar lo que antes era configuración ad-hoc. La clave está en tratar contexto, herramientas, sandbox y memoria como capas independientes, no como detalles del prompt. Ese cambio es lo que permite que tu flujo sobreviva a la siguiente migración de herramienta sin rehacerlo desde cero.

¿Has montado un harness así sobre Claude Code u otro agente? ¿Qué capa te ha dado más dolores de cabeza? Cuéntamelo en los comentarios o en Twitter @sergiomarquezp_. En el próximo post entro en cómo versionar skills entre equipos sin romper la compatibilidad entre Claude Code y Codex.