Un modelo que escribe código solo produce texto. Algo tiene que leer el proyecto, elegir qué ve el modelo, ejecutar los comandos que pide, consultarte antes de los pasos riesgosos y mantener la sesión. Ese programa es el (el "arnés") del , y define el resultado tanto como el modelo.

Esta lección cubre cuatro ideas: de qué está hecho un harness, cómo darle instrucciones sin confundir consejo con control, cómo ejecutarlo sin nadie delante y cómo evitar que tu proceso quede atado a un solo producto.

Qué es un harness de código

En cada turno, las cuatro capas trabajan juntas así:

Modelopide una acción
Permisospermitida, consultada o rechazada
Herramientasleer, editar, ejecutar un comando
Resultadose suma a lo que el modelo ve después

vuelve al modelo, hasta terminar la tarea

Un turno de un harness de código. El modelo solo pide; el harness decide qué se ejecuta y qué ve el modelo después.

La idea general está en Tool calling y harness. Los productos cambian rápido; lo que perdura es dónde corren, si su código es abierto y si te atan a un proveedor de modelos (verificado en septiembre de 2026):

Producto	Dónde corre	Código abierto	Modelos
Claude Code (Anthropic)	terminal, IDE, escritorio, web	no, licencia comercial	familia Claude
Codex CLI (OpenAI)	terminal; también IDE y nube	sí, Apache-2.0	OpenAI; proveedores configurables
Gemini CLI (Google)	terminal	sí, Apache-2.0	Gemini
OpenCode	terminal, IDE, escritorio	sí, MIT	varios proveedores
Cursor	editor propio	no	varios proveedores
Copilot coding agent (GitHub)	nube, sobre GitHub Actions	no	los que ofrece GitHub

Consejo frente a reglas

Todo harness te permite enseñarle cómo es tu proyecto. Para cada pieza, pregúntate: ¿es un consejo que el modelo lee o una regla que el harness hace cumplir?

Los archivos de instrucciones son consejo. es un formato abierto: un archivo Markdown en la raíz del repositorio con lo que un agente necesita para trabajar ahí (comandos, convenciones, restricciones). Lo leen Codex, Cursor, Gemini CLI, Copilot y otros, y desde fines de 2025 lo custodia la Agentic AI Foundation de la Linux Foundation, junto con . Claude Code lee CLAUDE.md, y su documentación sugiere que ese archivo importe AGENTS.md para tener una sola fuente. Estos archivos son contexto, no control: el modelo intenta seguirlos, y nada más.

Las skills son consejo que se carga cuando hace falta. Una skill es una carpeta con un archivo SKILL.md (un nombre, una descripción breve e instrucciones paso a paso) y, opcionalmente, scripts y referencias. Al iniciar, el agente lee solo el nombre y la descripción de cada skill, como los lomos de los libros en un estante, y abre el resto cuando una tarea coincide. Esta (progressive disclosure) hace que las skills sin usar casi no cuesten nada. Anthropic creó el formato y lo publicó como estándar abierto (agentskills.io); entre quienes lo adoptan están Codex, Gemini CLI, OpenCode, Cursor y GitHub Copilot.

Los y los permisos son reglas. Un hook es un comando que el harness ejecuta ante un evento fijo, como el inicio de sesión o antes de usar una herramienta, quiera o no el modelo. Los permisos deciden qué puede hacer el agente en absoluto.

La regla práctica: lo que aplica siempre va en el archivo de instrucciones; un procedimiento para ciertas tareas va en una skill; lo que debe cumplirse sin excepción va en un hook o un permiso.

Archivo de instruccionessiempre cargado
- Consejo que el modelo lee
Skillse carga si la tarea coincide
- Consejo, por etapas
Hook o permisolo hace cumplir el harness
- Una regla que se cumple

Solo la tercera columna obliga al agente. Las dos primeras son contexto que el modelo intenta seguir.

En docket

Archivo de instruccionesse lee en cada sesión
Skillsse abren cuando la tarea las pide
Notas detalladas de skillssolo para el caso en curso
Hook de inicioal iniciar, al reanudar y tras condensar

docket mantiene pequeño lo que se carga siempre y deja el detalle para lo que se carga solo cuando hace falta. El hook corre quiera o no el modelo, y restaura un resumen breve del estado del trabajo. Fuente: Development harness and context policy

Ejecutar sin nadie delante

Para automatizar un harness, por ejemplo en un pipeline, se ejecuta en (sin interfaz): entra una tarea y sale un resultado legible por máquina. Claude Code, Codex y Gemini CLI lo ofrecen; Codex usa por defecto un de solo lectura.

Sin nadie presente, nadie responde "¿puedo ejecutar este comando?". Decide de antemano qué está permitido y qué pasa con lo demás: se deniega, se detiene la ejecución o queda en espera hasta que alguien lo apruebe desde otro canal. Nunca ejecutes en modo headless con permisos amplios fuera de un sandbox (Sandboxing y seguridad de agentes).

Varios harness detrás de una interfaz

Si tu plataforma lanza agentes de código, conecta cada harness a una interfaz propia y registra qué puede garantizar cada uno, porque no son iguales. Nuestros dos productos toman caminos opuestos.

Un harness cerrado decide por su cuenta qué hacer con tu política, y eso no se arregla desde afuera.

Riesgos frecuentes

En la práctica

Elige a propósito entre un harness o varios. Uno solo simplifica soporte, licencias y auditoría, a cambio de depender del ritmo, los precios y los modelos de un proveedor.
Mantén las instrucciones portables. AGENTS.md y las skills en formato abierto te acompañan si cambias de herramienta; hooks y configuraciones suelen reescribirse por producto.
Pon cada regla obligatoria en permisos, hooks o un sandbox, nunca solo en un archivo de instrucciones.
Prueba cada adaptador si automatizas varios harness, y deja escrito qué garantiza cada uno.

Fuentes

Para profundizar

La documentación de docket muestra estas ideas aplicadas, y la de Tack muestra cómo es lanzar varios harness en la práctica (en inglés):

Development harness and context policy explica las cuatro capas de contexto que docket usa para su propio desarrollo y cómo las lee cada harness: Codex, Claude Code y OpenCode.
ADR 0002: Own the loop, rent the protocols registra por qué docket ejecuta su propio bucle de agente en vez de apoyarse en un framework de agentes.
ADR 0001: harness mode describe cómo docket ejecuta un agente, sin preguntas que responder, dentro de un espacio de trabajo que provee otro programa.
Agent Runners & Fleet Execution compara los harness que Tack puede lanzar: qué mide cada uno, si puede pausar para consultarte y cuánto de la política de permisos de Tack respeta.

Para llevar

Un harness de código es el bucle, las herramientas, los permisos y el contexto alrededor de un modelo.
Instrucciones y skills son contexto, no control: lo obligatorio va en permisos, hooks o un sandbox.
Las skills se cargan por etapas, así que sirven para procedimientos; audítalas como software.
Una ejecución headless necesita cada permiso decidido de antemano.
Si usas varios harness, ponlos detrás de una interfaz que declare qué garantiza cada uno.

Comprueba lo aprendido

¿Por qué una regla crítica no debería vivir solo en AGENTS.md?

El modelo recibe el archivo como texto que intenta seguir, no como una restricción, así que puede malinterpretarlo, olvidarlo o ser convencido de ignorarlo. Una acción que nunca debe ocurrir se bloquea con permisos, hooks o aislamiento.

¿Por qué un proyecto puede tener decenas de skills sin que cada sesión se vuelva más lenta?

Al iniciar, el agente lee solo el nombre y la descripción de cada skill. Las instrucciones completas y las referencias se cargan solo cuando una tarea las necesita.

Tu plataforma lanza dos harness distintos. ¿Por qué registrar qué garantiza cada uno?

Porque difieren en aspectos que importan para la seguridad, como si cancelar una ejecución detiene de verdad todo lo que inició. Si la plataforma supone que ambos se comportan igual, una falla en uno pasa inadvertida.