Introducción
Las publicaciones recientes de Anthropic sobre Agent Harness merecen atención.
Han empujado el campo hacia delante de forma discreta: de "cómo escribo un loop más inteligente" a "cómo diseño un runtime que sobreviva en producción".
Este artículo recorre la práctica más reciente: Session, Harness, Sandbox, Credentials, Tool Protocol, Context Builder, Trace y Eval.
Cómo cambió la forma de pensar
Anthropic no decidió de un día para otro que los Agents necesitaban un Runtime. El centro de gravedad se movió varias veces durante los últimos años.
Fase 1: el contexto largo como palanca principal
Al principio, Anthropic hablaba mucho de long context.
Aparecieron ventanas de contexto de 100K y luego 200K. Claude podía leer más documentos, sostener conversaciones más largas y manejar materiales más complejos. Muchos problemas todavía se planteaban como prompt engineering: cómo meter información, cómo hacer que el modelo encontrara la pieza correcta dentro de una ventana larga y cómo reducir omisiones.
Tenía sentido en ese momento. Cuando la ventana crece de golpe, todos quieren lanzar dentro el estado de la tarea, los documentos y el historial de chat.
Pero el trabajo real con Agents demostró una idea simple: un espacio de trabajo más grande no es lo mismo que una memoria fiable.
Por larga que sea la ventana, sigue siendo un conjunto de tokens que el modelo ve en una sola llamada. Se vuelve caro. Se degrada. Se comprime. Se contamina con ruido.
Fase 2: separar Agents en workflow y loop autónomo
En la etapa de Building Effective AI Agents, Anthropic empezó a trazar una línea clara entre workflow y agent.
Un workflow tiene un proceso definido y rutas controlables. El modelo toma decisiones en ciertos nodos.
Un agent es un loop abierto. El modelo planifica, llama herramientas, lee resultados y sigue actuando por cuenta propia.
Esta distinción importa más de lo que suele reconocerse. La mayoría de productos no necesitan un Agent altamente autónomo.
Los procesos de negocio estables son más baratos, más fiables y más fáciles de depurar como workflows. Forzar un Agent suele convertir un proceso controlable en una caja negra incontrolable.
La conclusión de esa fase sigue vigente: empieza simple. Recurre a mayor autonomía solo cuando la tarea realmente exija decisiones abiertas.
Fase 3: herramientas, contexto y seguridad pasan al centro
Después de 2025, las publicaciones de Anthropic giraron con fuerza hacia los detalles de ingeniería.
think tool: da espacio para razonar dentro de llamadas complejas a herramientas.
Multi-agent research system: búsqueda paralela y división del trabajo para tareas pesadas de investigación.
Context engineering: selección, compresión, recorte y carga dinámica del contexto.
Agent Skills: conocimiento procedural de dominio, cargado bajo demanda.
Claude Code sandboxing: delimitar ejecución de código, sistema de archivos, red y credenciales.
MCP, code execution with MCP y advanced tool use: conectar herramientas, descubrirlas y evitar que la expansión de definiciones de herramientas y los resultados intermedios destruyan el contexto.
Parecen temas dispersos. Todos apuntan a lo mismo:
Cuando un Agent empieza a hacer trabajo real, la pregunta deja de ser "puede responder el modelo" y pasa a ser "puede el sistema sostener las acciones del modelo".
Demasiadas herramientas → el contexto explota.
Tareas demasiado largas → el historial de chat se queda sin camino.
Ejecución demasiado libre → la frontera de seguridad colapsa.
Multi-Agent demasiado agresivo → se acumulan coste y sobrecarga de coordinación.
Los modelos mejoran demasiado rápido → las suposiciones antiguas del harness caducan.
Fase 4: elevar el problema a la capa Runtime
En la publicación más reciente sobre Managed Agents, Anthropic dejó de discutir cómo escribir un harness concreto. Empezó a hablar de una interfaz estable para un Agent Runtime.
El sistema se divide en Session, Harness y Sandbox.
Claude + harness = el brain. Sandbox y entorno de ejecución = las hands.
Session vive fuera de la ventana de contexto.
Las credenciales viven fuera del sandbox.
Los entornos de ejecución pueden fallar, reemplazarse y reconstruirse.
Ese es el arco completo del pensamiento de Anthropic:
Long context → Tool loop → Context engineering → Safe execution → Recoverable runtime
La idea central de Managed Agents: interfaces estables, estrategias reemplazables
Managed Agents se resume en una frase: no atornilles entre sí las cosas que van a seguir cambiando.
Los modelos cambian. Las estrategias del Harness cambian. Las herramientas cambian. Las formas del Sandbox cambian. Las estrategias de contexto cambian. Los entornos de despliegue de clientes cambian. Los requisitos de seguridad también cambian.
Si metes todo eso en un contenedor, un loop y una pila de prompts, en un año tendrás un bloque difícil de reemplazar.
Harnesses encode assumptions that go stale as models improve.
Un harness codifica las debilidades del modelo actual. ¿El modelo no planifica tareas largas? Añade un planner. ¿El modelo se salta comprobaciones? Añade un evaluator. ¿El modelo cierra demasiado pronto cuando se acerca al límite de contexto? Añade context reset. ¿El modelo falla en llamadas a herramientas? Añade lógica elaborada de retry.
Estas estrategias funcionan en una generación del modelo. En la siguiente, pueden convertirse en peso muerto.
Anthropic dio un ejemplo preciso: Claude Sonnet 4.5 tendía a cerrar tareas antes de tiempo cerca del límite de contexto, así que el harness añadió un context reset. Con Claude Opus 4.5, ese comportamiento desapareció y la lógica de reset se convirtió en sobrecarga.
La lección:
No conviertas los defectos del modelo de hoy en la arquitectura del sistema de mañana.
Las interfaces centrales que Managed Agents extrae se parecen a esto:
Session: qué ocurrió durante la tarea
Harness: qué hacer después
Sandbox: dónde se ejecutan las acciones
Tool interface: cómo se llaman las acciones
Credential boundary: si las acciones están autorizadas
Context builder: qué ve el modelo en este turno
Trace / Eval: cómo se revisa la ejecución
El objetivo no es llegar a un Agent loop fijo y elegante.
El objetivo es que, cuando cambien los modelos, las herramientas y los entornos de ejecución, el sistema pueda seguir evolucionando.
Eso es lo que realmente vale la pena tomar de Managed Agents.
Idea clave 1: desacoplar Brain / Hands
El corte más importante en Managed Agents es separar brain de hands.
Brain = Claude + harness.
Hands = sandbox, MCP server, herramientas externas, dispositivos, navegador, entorno de ejecución de código.
La opción inicial habitual era meter el brain dentro de las hands. Un contenedor ejecutaba el harness, guardaba la session, ejecutaba herramientas y se sentaba sobre el sistema de archivos, a veces incluso con credenciales dentro.
En producción, esto crea un problema clásico: el contenedor se convierte en un pet server.
No puedes descartarlo. No puedes reiniciarlo con facilidad. Si falla, tienes que rescatarlo. Para depurarlo, tienes que entrar por SSH.
Datos de usuario, estado de ejecución, llamadas a herramientas y fronteras de credenciales quedan mezclados.
El enfoque posterior de Anthropic: sacar el harness del sandbox. El harness se convierte en un plano de control relativamente sin estado. El sandbox se convierte en un recurso de ejecución invocable y reconstruible.
Ambos se comunican mediante una interfaz muy simple:
execute(name, input) -> string
El harness no necesita saber si al otro lado hay un contenedor, un servicio remoto, un MCP server o un entorno de herramientas dentro del VPC de un cliente. Llama la acción. Recibe el resultado.
Lo que obtienes con esto:
- Si el Sandbox muere, la tarea no muere.
- El Brain puede empezar a trabajar y el sandbox puede cargarse después.
- Un brain puede llamar a muchas hands.
Idea clave 2: diseño de Session
La otra decisión importante en Managed Agents:
Session is not Claude's context window.
Muchos sistemas de Agents mezclan session, historial de chat, memory y ventana de contexto. Las tareas cortas sobreviven a eso. Las largas se rompen.
La ventana de contexto son solo los tokens que el modelo ve en una llamada de inferencia. Es un espacio de trabajo.
La session debería ser el registro duradero de lo que ocurrió, algo más cercano a un event log.
Una session seria debería capturar al menos:
user_input
model_response
tool_call
tool_result
file_change
error
retry
approval
checkpoint
Cada vez que el harness llama al modelo, toma información de la session y ensambla un contexto para ese turno.
Esta separación es el punto central: Prompt es el espacio de trabajo. Session es el libro contable.
Un espacio de trabajo se organiza, se comprime, se recorta y se reordena. Un libro contable permanece tan completo, consultable y recuperable como sea posible. Si vuelcas todo el historial al contexto, el coste explota y el modelo se ahoga en ruido. Si dependes solo de resúmenes, el detalle que descartaste puede convertirse en el error crítico de mañana.
La estructura que aguanta es esta:
Raw events kept long-term
↓
Context Builder picks dynamically
↓
This model call sees a high-signal context
Aquí también se separan context engineering y durable state.
Context engineering decide qué ve el modelo en este turno.
Session event log registra qué ocurrió realmente en el sistema.
Los Agents de larga duración que se saltan esta capa lo pagan después: resume, trace, eval y debug se vuelven dolorosos.
Idea clave 3: diseño de Sandbox
Sandbox es una de las piezas más subestimadas en un sistema de Agents.
Muchos equipos empiezan dándole al Agent una shell. Puede ejecutar comandos, leer archivos y editar código. Parece suficiente.
Está bien para demos. En producción, el sandbox es tu frontera de seguridad, tu frontera de ejecución y una fuente significativa de coste y latencia.
Lo que Anthropic enfatizó en Claude Code sandboxing y Managed Agents:
- Los sandboxes aíslan sistema de archivos y red. Trata el código generado por el modelo como código no confiable. El sandbox necesita limitar el acceso al sistema de archivos y el alcance de red. De lo contrario, un prompt injection puede convencer al Agent de leer archivos que no debería, tocar servicios que no debería y exfiltrar el resultado.
- Los sandboxes no deberían contener credenciales de larga duración. Cada token de GitHub, clave de base de datos o secreto cloud dentro del sandbox es algo que un atacante puede intentar filtrar a través del Agent.
- Los sandboxes deben ser reconstruibles y recuperables. Los Agents de larga duración van a encontrar fallos. Si atas demasiado el sandbox a una session, el fallo se lleva por delante toda la tarea. Mejor: hacer que el sandbox sea reconstruible, recuperable e idealmente capaz de snapshot/resume. Es Brain / Hands decoupling tomado en serio.
Resumen: arquitectura Anthropic Agent Harness 2026
Si unimos todo el pensamiento de 2026, aparece esta imagen:
Lo importante aquí es la frontera de responsabilidad de cada pieza.
Harness es el plano de control: agenda modelos, contexto, herramientas y estrategias.
Session event log es estado duradero: no está atado a ningún contenedor.
Context Builder: ensambla un contexto de alta señal desde session, memory, skills y resultados de herramientas.
Tool Router: despacha acciones a MCP, al entorno de ejecución de código, al sandbox o a otras hands.
Sandbox ejecuta acciones: puede fallar y puede reconstruirse.
Credential Proxy / Vault guarda credenciales: los entornos de ejecución no confiables nunca reciben el token bruto.
Trace / Eval atraviesa toda la ejecución para revisar, hacer regresiones y comparar cambios del harness.
Harness de investigación vs harness de producción
Muchas demos de Agents se ven muy potentes y luego se vuelven pesadas, caras e imposibles de depurar en producción.
La razón: un harness de investigación y un harness de producción tienen objetivos distintos.
Un harness de investigación persigue el techo de capacidad. Gasta más tokens, lanza más subagents, apila más evaluators, ejecuta otra ronda. Si la tasa de éxito de la tarea sube, el experimento valió la pena.
Un harness de producción persigue retornos estables. Tiene que contar coste, vigilar latencia, controlar permisos, recuperarse de fallos, ser observable, desplegar gradualmente y revertir limpio.
| Dimensión | Harness de investigación | Harness de producción |
|---|---|---|
| Objetivo | Empujar el techo de éxito de tareas | Entrega estable bajo restricciones de coste, latencia y seguridad |
| Estado | Transcript, archivos locales, progress files temporales | Session log externo, checkpoints, event history |
| Contexto | Dar al modelo todo lo posible | Conjunto de contexto más pequeño y de mayor señal |
| Herramientas | Conectar tantas como se pueda | Descubrimiento dinámico, carga bajo demanda, permisos acotados |
| Multi-Agent | Probar primero paralelismo y división de roles | Activarlo solo en tareas de alto valor y paralelizables |
| Seguridad | Confirmación manual, aislamiento ligero | Sandbox, proxy, vault, scoped credentials |
| Recuperación de fallos | Reintento o traspaso humano | Resume, replay, checkpoint, trace |
| Evaluación | Si la demo final funcionó | Outcome eval, trace analysis, regression suite |
| Iteración | Añadir módulos, estrategias y agents | Ejecutar ablations y borrar estrategias que ya no compensan |
Una frase de las publicaciones de Anthropic se queda grabada: las estrategias del harness se revaloran cada vez que el modelo se actualiza.
El planner de hoy ayuda. Mañana ralentiza el sistema. El evaluator de hoy detecta errores. Mañana solo añade coste. El context reset de hoy es un parche necesario. Mañana es peso muerto.
Por eso un harness de producción no puede limitarse a añadir cosas. También tiene que borrar cosas. Ese es el sentido de las ablations.
Cada actualización de modelo debería volver a medir: ¿memory sigue aportando? ¿El critic? ¿Tool search? ¿Multi-agent fanout? ¿Context reset?
En ingeniería de Agents, la capacidad de borrar complejidad obsoleta es una habilidad propia.
Cierre
Los productos basados en Agents seguirán volviéndose más complejos. Pero esa complejidad no debería vivir toda dentro del prompt y del loop. Pertenece al runtime:
Session: durable state
Harness: control plane
Context Builder: context scheduling
Tool Router: action dispatch
Sandbox: isolated execution
Credential Proxy: credential boundary
Trace: process record
Eval: outcome judgment
Esa es la base real para Agents en producción.
Las configuraciones multi-agent seguirán evolucionando. El ecosistema MCP seguirá creciendo. Las ventanas de contexto seguirán alargándose. Los modelos seguirán mejorando en llamadas a herramientas, planificación y autorreparación.
Pero nada de eso suaviza el problema central. Lo vuelve más claro: tu sistema tiene que poder reemplazar estrategias antiguas.
Una plataforma de Agents que codifica todo en prompts, contenedores y un loop fijo se vuelve más difícil de mantener cada trimestre.
Un sistema que dibuja fronteras claras entre estado, ejecución, credenciales, contexto y evaluación es el que puede evolucionar junto con el modelo.
Referencias
- Anthropic, Scaling Managed Agents: Decoupling the brain from the hands
www.anthropic.com/engineering/managed-agents - Anthropic, Harness design for long-running application development
www.anthropic.com/engineering/harness-design-long-running-apps - Anthropic, Effective harnesses for long-running agents
www.anthropic.com/engineering/effective-harnesses-for-long-running-agents - Anthropic, Effective context engineering for AI agents
www.anthropic.com/engineering/effective-context-engineering-for-ai-agents - Anthropic, Making Claude Code more secure and autonomous with sandboxing
www.anthropic.com/engineering/claude-code-sandboxing - Anthropic, Code execution with MCP: building more efficient AI agents
www.anthropic.com/engineering/code-execution-with-mcp - Anthropic, Introducing advanced tool use on the Claude Developer Platform
www.anthropic.com/engineering/advanced-tool-use - Anthropic, Equipping agents for the real world with Agent Skills
www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills - Anthropic, Building Effective AI Agents
www.anthropic.com/engineering/building-effective-agents