Arneses de agentes: cinco capas y cómo construir el tuyo

TL;DR

Un arnés (harness) es todo el software que rodea al modelo y lo convierte en algo que hace cosas en vez de contestar mensajes. La fórmula que se ha impuesto en 2026 es corta: agente = modelo + arnés. Casi toda la atención pública se la lleva el primer sumando; casi toda la ventaja defendible está en el segundo. Este artículo mapea las cinco capas de un arnés, compara los arneses abiertos y cerrados más potentes del momento, y muestra por qué los verticales que mejor funcionan —Harvey y Legora en legal, Rogo y Hebbia en finanzas— no ganaron entrenando un modelo mejor, sino construyendo el arnés de su industria. Termina con la ruta concreta para construir el de la tuya.

El arnés es el producto, no el modelo

Hay un dato de este mismo año que ordena toda la discusión. Cuando OpenAI presentó GPT-6 Astra, la cifra que se citó en todas partes fue el 99,9% en ARC-AGI-3. Ese número se midió con un provider adapter: un arnés modificado, no un modelo modificado. Sin ese arnés, el mismo modelo saca alrededor del 70%. Lo contamos con detalle en nuestro análisis de GPT-6 Astra.

Treinta puntos porcentuales de diferencia sobre pesos idénticos. Esa brecha es el tamaño del espacio donde vive la ingeniería de arneses, y es la razón por la que la pregunta «¿qué modelo usamos?» se ha vuelto mucho menos interesante que «¿qué le damos de ver, qué le dejamos tocar y cómo comprobamos que terminó?».

La definición de trabajo más útil es la de Databricks: «un arnés de agente de IA es la infraestructura de software que envuelve a un modelo de lenguaje y le permite actuar sobre tareas, no solo responder a prompts». El arnés decide qué ve el modelo, qué herramientas puede llamar, dónde se guarda el estado, cómo vuelven las observaciones, cuándo se valida, cómo se recupera de un fallo, cuándo tiene permiso para parar y cómo se organizan una o varias llamadas al modelo.

Anatomía: las cinco capas

La literatura académica de 2026 converge en una arquitectura por capas. El survey Natural-Language Agent Harnesses (arXiv 2603.25723) las ordena así, y es el esqueleto que conviene tener en la cabeza al diseñar uno propio:

Sobre ese esqueleto, Databricks enumera los ocho componentes que tienen que existir en alguna parte: prompts de sistema, herramientas y su ejecución, sandboxes, sistema de archivos duradero, gestión de memoria y contexto, bucles de verificación, guardarraíles con humano en el circuito, y observabilidad. La capa donde los pongas es decisión de arquitectura. Que falte alguno no es decisión: es una deuda que se cobra en producción.

Todo esto gira en un bucle ReAct: el modelo razona, el arnés ejecuta, el resultado vuelve como observación y el ciclo se repite hasta que algo decide que se terminó. Ese «algo» —la condición de parada— es la pieza que más se subestima y la que más distingue a un arnés serio de un while con una llamada a la API dentro.

El mapa de 2026: abierto y cerrado

El campo se ha poblado rápido. Estos son los arneses que hoy marcan el estado del arte, con la característica de arquitectura por la que vale la pena mirarlos.

Abiertos

Cerrados

Dos señales de que la capa está madurando y conviene no ignorar. La primera: la Linux Foundation levantó en 2026 una Agentic AI Foundation sobre tres donaciones —el Model Context Protocol de Anthropic para herramientas, AGENTS.md de OpenAI para instrucciones, y Goose—. La segunda: Zed, OpenHands y DeepSeek Harness hablan el Agent Client Protocol, o sea que se conducen entre ellos. Las interfaces entre capas se están estandarizando, y eso significa que construir el tuyo ya no es empezar de cero.

Lo que separa un arnés serio de un bucle while

Si se comparan los arneses de arriba, las diferencias no están en el prompt. Están en siete decisiones:

• Permisos por operación. Leer no es escribir, escribir no es borrar, y borrar en staging no es borrar en producción. Cline pide aprobación por edición; Claude Code la pide por tipo de operación. Un arnés sin gradación de permisos solo tiene dos modos: inútil o peligroso.
• Aislamiento real. Un sandbox de verdad es nsjail o un contenedor, no una lista de comandos prohibidos. La diferencia se nota el día que el agente compone un comando que no está en tu lista.
• Puntos de retorno. Los commits automáticos de Aider y los worktrees aislados de Muse Code resuelven el mismo problema: poder deshacer sin reconstruir a mano lo que el agente tocó en 40 turnos.
• Verificación que el agente pueda ejecutar. En código son los tests: el agente sabe si terminó porque algo se pone verde. Esta es la pieza que hay que inventar en cada industria, y es la que decide si el proyecto funciona.
• Gestión de contexto. Compactar, resumir, recuperar, olvidar. Un agente que llena su ventana de resultados de herramientas deja de razonar mucho antes de quedarse sin tokens.
• Subagentes. Delegar una subtarea a una copia con su propio contexto evita que el trabajo de lectura contamine el hilo principal. Antigravity, Claude Code y Muse Code lo hacen; Hebbia lo hace en finanzas separando recuperación de redacción.
• Observabilidad. Trazas por acción, no logs por sesión. Sin esto no hay depuración, y en sector regulado tampoco hay defensa.

Los verticales ya llegaron: finanzas y legal

Aquí está la parte que conviene mirar despacio, porque es la evidencia de que esto no es una idea sino un mercado.

Legal

Harvey ejecuta bucles autónomos con la forma clásica: planifica, ejecuta subtareas, evalúa resultados intermedios, ajusta y sigue hasta cumplir el objetivo; el agente decide qué herramientas usa, qué documentos prioriza y cuándo su propia salida necesita revisión. Su ventaja declarada no es el modelo: es profundidad de plataforma, con del orden de 25.000 agentes personalizados y un Agent Builder con el que los propios despachos arman los suyos.

Legora atacó por el lado de la interfaz de dominio. Su Tabular Review convierte una carpeta de cientos de contratos en una rejilla interactiva para comparar cláusulas y extraer datos a escala. En 2026 compró Walter AI para automatización de flujos nativa de agentes y Qura para investigación legal. Lo que ambas venden por debajo es lo mismo: herramientas construidas para trabajo legal —revisión tabular, integración con el gestor documental del despacho, redlining, investigación—, aprobación humana en los puntos que importan y trazas completas donde cada acción del agente es rastreable, revisable y defendible.

Finanzas

Rogo es el caso más literal: una compañía vertical con la pila entera —desde los modelos hasta la interfaz— construida para profesionales de finanzas. Su agente, Felix, ejecuta flujos financieros multipaso: cribado de operaciones, generación de CIM, comparables, construcción de modelos, preparación de pitchbooks, síntesis de resultados y memorandos de diligencia. Trae de fábrica integraciones con Pitchbook, Capital IQ y Datasite, plantillas financieras y registro de cumplimiento por operación. Ese último punto es el argumento comercial explícito frente a un modelo generalista: un LLM de propósito general no produce trazas de auditoría presentables ante un regulador, desglosadas por deal.

Hebbia resuelve otra pieza con una decisión de arquitectura interesante: subagentes especializados que separan la recuperación del formateo de la salida, y una rejilla de datos donde cada celda enlaza con su cita de origen. Por eso los despachos, las consultoras y los equipos de diligencia de private equity la usan para analizar data rooms.

Nótese lo que ninguna de las cuatro hizo: ninguna ganó entrenando un modelo mejor que el de frontera. Ganaron construyendo las capas 3, 4 y 5 para un oficio concreto.

Traducir las capas a tu industria

La tesis práctica del artículo es esta: las cinco capas son genéricas, pero el contenido de tres de ellas es específico de tu oficio, y ahí es donde está tu ventaja, no en el bucle.

La fila que decide el proyecto es la del medio. En código, la verificación viene regalada: hay tests, hay compilador, hay linter, y el agente puede ejecutarlos sin pedir permiso a nadie. Por eso los arneses de código llegaron primero, no porque programar sea más fácil que litigar.

Y la buena noticia es que en la mayoría de los procesos de oficina esa comprobación existe, solo que hoy la ejecuta una persona con una lista. Conciliar una cuenta, cuadrar un balance, verificar que un contrato no se desvía del playbook, comprobar que cada cifra de un informe aparece en la fuente: todas son reglas explícitas que alguien aplica a mano. Escribirlas como código es el trabajo, y es trabajo que no caduca cuando sale el siguiente modelo.

Por qué construir el tuyo en vez de comprarlo

Hay tres razones, y ninguna es «sale más barato».

1. Tu proceso no es el proceso medio de tu sector. Harvey y Rogo venden el flujo modal de un despacho grande o de un banco de inversión. Cuanto más se parezca tu operación al promedio, más sentido tiene comprar. Cuanto más específica sea —y las operaciones que dan margen suelen ser las específicas—, menos cubre el producto genérico.
2. El arnés es donde vive tu conocimiento, y no se deprecia. Los pesos del modelo se reemplazan cada pocos meses. Las reglas de verificación de tu oficio, las integraciones con tus sistemas y tu definición de «terminado» sobreviven a ese recambio. Por eso conviene que sean tuyas.
3. Los datos y la traza no salen. En sector regulado esto suele dejar de ser preferencia y pasar a ser requisito. OpenHands existe precisamente para ese caso.

Cómo empezar sin quemar seis meses

El error habitual es empezar por la capa de control —el bucle, los subagentes, el planificador— porque es la parte divertida. Es también la parte que ya está resuelta y que puedes tomar prestada. El orden que funciona es el inverso:

1. Elige un proceso con final comprobable. Repetitivo, con volumen, y con una comprobación que pueda ejecutar una máquina. Si no la tiene, elige otro o construye la comprobación primero.
2. Escribe la verificación antes que el agente. En código son tests. En tu oficio es un script que responde sí o no a «esto está bien». Sin esto no tienes arnés, tienes un chat.
3. Envuelve tus sistemas como herramientas, no como prompts. Un servidor MCP por sistema, con contratos tipados, idempotencia y errores predecibles. Sobre esto escribimos aparte en plantillas MCP para chatbots empresariales y MCP desde cero.
4. Toma prestada la capa de control. Empieza con un arnés existente antes de escribir un bucle. Si vas a autoalojarlo, OpenHands. Si quieres leer uno mínimo para entenderlo, Pi.
5. Instrumenta desde el primer día. Trazas por acción. Sobre memoria y trazabilidad publicamos el patrón de memoria en capas con Langfuse y Redis.
6. Pon los permisos antes que la autonomía. Aprobación humana en las acciones irreversibles desde el principio, y se va soltando con evidencia, no con optimismo.
7. Mide con evals, no con demos. Una suite de casos reales que corra en CI. Lo detallamos en evals de agentes en CI/CD.

arnes-conciliacion/
├── tools/                 # capa de ejecución: un servidor MCP por sistema
│   ├── erp.ts             # leer asientos, no escribirlos
│   ├── banco.ts           # extractos, solo lectura
│   └── ledger.ts          # escritura, con idempotencia y operation_id
├── verify/                # la capa que decide si terminó
│   ├── cuadre.ts          # suma de partidas == extracto, al centavo
│   └── reglas_fiscales.ts # lo que hoy revisa una persona con una lista
├── policy/                # permisos: qué puede tocar sin preguntar
├── traces/                # supervisión: una traza por acción, no por sesión
└── evals/                 # 40 cierres reales del año pasado, con su resultado

Fíjate en lo que no aparece en ese árbol: el bucle. Es deliberado. El bucle lo pones prestado y lo cambias sin dolor; los otros cinco directorios son el activo.

Lo que sale mal

• Verificación que el agente puede engañar. Si la comprobación es débil, el agente optimiza la comprobación en vez del trabajo. Es el mismo fenómeno que un test que pasa borrando la aserción.
• Autonomía antes que trazas. Soltar al agente antes de poder reconstruir lo que hizo convierte cualquier incidente en una investigación arqueológica.
• Herramientas demasiado potentes. Un único ejecutar_sql es cómodo y es una bomba. Herramientas estrechas con contratos explícitos envejecen mejor.
• Confundir el piloto con el sistema. La demo funciona porque el caso se eligió; producción trae el 20% de casos raros que es donde vive todo el coste.
• Comprar el vertical y no cambiar el proceso. El arnés no arregla un proceso que nadie ha escrito. Si la definición de «terminado» vive en la cabeza de una persona, ese es el primer entregable.

Fuentes

• Databricks — ¿Qué es un arnés de agente de IA? (definición y los ocho componentes)
• arXiv 2603.25723 — Natural-Language Agent Harnesses (arquitectura en cinco capas y taxonomía)
• explainx.ai — Top 10 agent harnesses, abiertos y cerrados 2026
• Legora — 2026, el año de los agentes en IA legal
• Rogo (Felix) — agente de análisis para banca de inversión y comparación Rogo / Hebbia