Quales Aura
Qué es un agent harness y por qué tus agentes de código necesitan uno
Agent HarnessAgentes de códigoQuales CodeProductividad de desarrolloGobernanza de IA
Quales Group·Preguntale a diez ingenieros qué es un agente de código y la mayoría va a describir un modelo: Claude, GPT, Gemini. Preguntales por qué el mismo modelo se comporta de manera brillante en un producto y errática en otro, y la conversación gira hacia algo completamente distinto: el bucle que llama al modelo, las herramientas que tiene permitido usar, los permisos que debe respetar, el entorno en el que corre. Ese "algo distinto" tiene nombre. Es el harness.
Este artículo define el término, explica por qué una llamada pelada a un modelo no alcanza para trabajo de código autónomo dentro de una empresa, introduce la idea de meta-harness y muestra cómo la aplica Quales Code.
Una llamada a un modelo frente a un harness
Una llamada cruda a la API no tiene estado: entra un prompt, sale texto. Todo lo que hace útil a un agente vive alrededor de esa llamada.
| Aspecto | Llamada pelada al modelo | Harness |
|---|---|---|
| Herramientas | Ninguna; el modelo solo puede describir acciones | Shell, edición de archivos, búsqueda, tests, servidores MCP, subagentes |
| Permisos | Ninguno | Qué herramientas, qué rutas, qué comandos, con o sin aprobación |
| Estado | Una petición | Una sesión con historial, tareas pendientes, artefactos, reanudable más tarde |
| Entorno | Ninguno | Un directorio de trabajo, un worktree de git, un sandbox, un host remoto |
| Revisión | Ninguna | Revisión del diff, agentes revisores, puertas de aprobación humana |
| Observabilidad | Tu propio logging | Transcripción completa, cada llamada a herramienta, contabilidad de tokens y costos |
| Control de costos | Ninguno | Presupuestos, límites de llamadas, enrutamiento de modelos |
| Colaboración | Ninguna | Sesiones compartidas, traspaso entre personas y dispositivos |
El harness es el runtime alrededor del modelo. Claude Code, Codex y Cursor son todos harnesses: cada uno envuelve un modelo con su propio bucle, herramientas, pedidos de permiso y formato de sesión. Cuando alguien dice que un agente "programa mejor" que otro con el mismo modelo, casi siempre está comparando harnesses.
Por qué los agentes de código en una empresa necesitan más
Un desarrollador que corre un agente en su laptop puede darse el lujo de improvisar. Una organización de ingeniería, no. En el momento en que los agentes tocan repositorios compartidos, las siguientes preguntas se vuelven bloqueantes:
Acceso a repositorios. ¿Qué repos puede clonar el agente? ¿Con las credenciales de quién? ¿Puede hacer push, o solo abrir una rama? Un token de acceso personal pegado en un archivo de configuración no es una respuesta que un auditor acepte.
Secretos. Los agentes leen archivos .env, configuraciones de CI y código de infraestructura. Sin un intermediario que mantenga las credenciales fuera del entorno del agente, cada sesión es una fuga potencial.
Revisión. Un agente que escribe código y lo mergea es un pasivo. Alguien o algo tiene que revisar el diff, e idealmente ese revisor no debería compartir los puntos ciegos del autor. Si el mismo modelo escribe y revisa, tenés un sello de goma.
Reproducibilidad. "Funcionó en mi sesión" es peor que "funcionó en mi máquina". Las sesiones tienen que grabarse, reanudarse y bifurcarse para que un colega pueda seguir donde dejaste o reproducir qué salió mal.
Sesiones en paralelo. Los equipos quieren varios agentes sobre el mismo repositorio a la vez, cada uno en su propia rama, sin pisarse los archivos. Eso es un problema de gestión de worktrees, no de prompts.
Costo. Los bucles autónomos pueden correr durante horas. Sin presupuestos por sesión, topes de llamadas a herramientas y visibilidad de quién gastó qué, la primera factura termina con el experimento.
Aislamiento. Un agente con acceso a la shell puede llegar a todo lo que el host alcanza: redes internas, endpoints de metadatos de la nube, archivos de otras personas. Un sandbox real a nivel de sistema operativo no es opcional.
Cada harness de proveedor resuelve algunas de estas cuestiones para su propio producto. Ninguno resuelve el problema transversal: tu empresa va a usar varios harnesses, de varios proveedores, y necesita un único lugar desde donde gobernarlos.
La idea del meta-harness
La observación clave es que el agente y el harness son cosas distintas. Un agente es una definición: sus instrucciones, las herramientas que puede usar, las políticas que debe respetar, los subagentes en los que puede delegar. Un harness es el motor que ejecuta esa definición con un modelo dado.
Un meta-harness separa ambos. Declarás el agente una vez y lo corrés en cualquier harness: Claude Code hoy, Codex mañana, una mezcla de los dos en la misma sesión. El meta-harness agrega la capa de gobernanza que les falta a las herramientas de cada proveedor: políticas uniformes, aprobaciones, sandboxing, intermediación de credenciales, sesiones compartidas y auditoría, independientemente de qué modelo o qué CLI haga el trabajo.
Acá importan dos estilos de ejecución:
- Headless. El meta-harness maneja directamente el SDK del proveedor, es dueño del bucle de mensajes y ve cada llamada a herramienta antes de que ocurra. Máximo control; ideal para aplicar políticas.
- Nativo. El meta-harness maneja la CLI real del proveedor dentro de una terminal, reflejando su transcripción. Fidelidad total al producto que los desarrolladores ya conocen, a costa de no ser dueño del bucle, y por eso tiene que combinarse con sandboxing a nivel de sistema operativo.
Un meta-harness te permite elegir por agente, e incluso por subagente.
Cómo ayuda Quales Code
Quales Code es un meta-harness declarativo para agentes de código, construido exactamente alrededor de la separación anterior.
Los agentes son archivos YAML cortos. Un agente declara su nombre, prompt, ejecutor (harness, modelo, credencial), herramientas, políticas y subagentes opcionales. Los ejecutores soportados incluyen Claude Code (SDK y nativo), Codex (SDK y nativo), Cursor, Pi, el Agents SDK de OpenAI y Google Antigravity. Cada subagente puede usar un harness distinto, y los agentes pueden crearse desde el chat.
Sesiones, hosts y worktrees. Una sesión es una conversación más un agente más un runner más un host. Un host es cualquier máquina que se registra en el servidor mediante un WebSocket saliente, de modo que una laptop detrás de un firewall corporativo puede correr sesiones lanzadas desde el navegador sin abrir ningún puerto. Las sesiones pueden pedir una rama de git al crearse y el host crea un worktree aislado, que es como varios agentes trabajan en paralelo sobre un mismo repositorio. Las sesiones se pueden compartir (ver en vivo), adjuntar (co-conducir en la misma máquina) o bifurcar (clonar y continuar de forma independiente), desde la terminal, el navegador, el móvil o la aplicación de escritorio.
Agentes revisores y ejecutores. El orquestador multiagente de referencia, Polly, planifica una tarea, delega la implementación en subagentes de código en worktrees paralelos, y envía cada diff a un agente revisor de un proveedor distinto del que lo escribió. Los comentarios de revisión hechos en el panel del workspace vuelven al agente como un único mensaje, al estilo de un PR.
Políticas en tres niveles. Reglas para todo el servidor definidas por los administradores, reglas por agente en el YAML y reglas por sesión, evaluadas en ese orden. Las integradas incluyen pedir confirmación antes de ejecutar comandos de shell o escribir archivos, máximo de llamadas a herramientas por sesión, presupuestos de costo con umbrales de aviso, restricciones de directorio de trabajo y puntuación de riesgo. Las aprobaciones pendientes de todas las sesiones caen en una única bandeja de entrada.
Sandboxing y credenciales. Los harnesses nativos corren bajo sandboxes del sistema operativo (bubblewrap en Linux, seatbelt en macOS) con seccomp y control de egreso. Las sesiones también pueden correr en sandboxes en la nube (Modal, Daytona, Docker, pods de Kubernetes por usuario y otros). Las credenciales de git y OAuth nunca salen del servidor: los intermediarios le entregan al agente solo tokens efímeros.
Marketplace de skills y MCP. Las skills y los blueprints se instalan con un clic y se sincronizan con todos los runners, apareciendo como comandos de barra en Claude Code, Codex y Pi. Los servidores MCP personalizados se gestionan desde el panel de control y pueden pasar por el motor de políticas como proxy.
Aplicación de escritorio y CLI. La CLI quales_work (también disponible como omni) ejecuta, reanuda y se adjunta a sesiones, registra hosts y gestiona sandboxes; quales_work setup detecta las CLI ya instaladas y adopta las credenciales existentes. La aplicación de escritorio envuelve la misma interfaz web con notificaciones del sistema operativo.
Identidad y roles. El modo multiusuario soporta cuentas locales, OIDC (Google, GitHub, Okta, Microsoft) y un modo gateway. Desplegado como parte de la suite Quales, Quales Code toma el SSO y los roles de Quales AuthOne en modo enforce, con roles de plataforma (owner, developer, user) y niveles de permiso por sesión desde lectura hasta propietario.
Cualquier modelo, en tus términos. Las credenciales pueden ser una clave de API, una suscripción a Claude o ChatGPT, un gateway (LiteLLM, OpenRouter, Ollama, vLLM, Azure) o Databricks, para que el agente corra contra el endpoint que tu empresa realmente contrató.
Por dónde empezar
Si tu equipo ya usa Claude Code o Codex, la pregunta no es si adoptar un harness: ya tenés uno por proveedor. La pregunta es si podés gobernarlos: una capa de políticas, una pista de auditoría, una forma de compartir y reanudar sesiones, un intermediario de credenciales, sin importar el proveedor.
Ese es el hueco que llena un meta-harness. Quales Code está disponible como producto autoalojado bajo licencia Apache-2.0, y Quales Group ayuda a las organizaciones de ingeniería a diseñar sus definiciones de agentes, políticas y bucles de revisión antes de que aterrice el primer pull request autónomo.