← Todos los articulos

Agentes gestionados vs. arneses de agentes locales: qué conservar

From the guide: Codex CLI Comprehensive Guide

Anthropic y OpenAI están convirtiendo la infraestructura del runtime de agentes en una superficie de producto: sesiones alojadas, sandboxes, tracing, memoria, handoffs, rúbricas y flujos de eventos ahora viven más cerca del proveedor del modelo que de la carpeta privada de scripts de un equipo.12

¿Cuáles son las ideas clave?

  • Los agentes gestionados se están convirtiendo en la capa del runtime. Las sesiones, los sandboxes, las trazas, los eventos y la ejecución asíncrona pertenecen cada vez más a la infraestructura gestionada cuando el proveedor cumple con el listón de seguridad del equipo.12
  • Los arneses locales siguen importando. Conserva las partes que codifican el criterio, la evidencia, la integridad de la escritura pública, los límites de privacidad, la verificación de fuentes y la memoria del proyecto.
  • La unidad de migración es el trabajo, no el comando. Un comando de barra, una skill de Codex, un handoff de SDK, un servidor MCP o un resultado gestionado pueden cargar todos el mismo flujo si los criterios de aceptación sobreviven.
  • No publiques la maquinaria privada. Las publicaciones públicas deberían explicar el patrón y los criterios de aceptación, no los prompts privados, los cuerpos exactos de los hooks, los detalles de la cuenta o las reglas internas de puntuación.
  • La promoción necesita pruebas. Comienza de forma explícita, ejecuta una tarea real, registra el resultado y promueve solo cuando la ruta visible al usuario mejore.

Las plataformas de agentes gestionados deberían absorber el trabajo del runtime de uso común: ejecución en sandbox, sesiones con estado, flujos de eventos, tracing, ejecución de archivos y finalización asíncrona. Los arneses locales siguen importando, pero su tarea se vuelve más pequeña y más afilada. Conserva las partes que codifican el criterio del producto, las puertas de evidencia, la integridad de la escritura pública, los límites de privacidad, la verificación de fuentes y la memoria operativa específica del proyecto. Mueve las partes que solo existen porque nadie más había empaquetado todavía el runtime.

La mala migración consiste en eliminar tu arnés local porque un proveedor lanzó infraestructura gestionada. La segunda mala migración consiste en preservar cada comando local, hook y prompt porque alguna vez resolvió un problema real. La migración correcta hace una pregunta por componente: ¿esto codifica mis estándares, o esto opera la máquina?

Para conocer la arquitectura más amplia, lee la guía de Arquitectura de Agentes IA. Para el patrón de migración local detrás de esta publicación, lee la Guía de migración de Claude Code a Codex, Patrones de AGENTS.md y Filosofía de calidad Jiro.

Para el lado de las herramientas locales del reparto, Claude Code como infraestructura explica por qué crecen las capas privadas de runtime, y Claude Code vs Codex CLI 2026 compara las superficies de activación y seguridad.

¿Qué cambió con los agentes gestionados?

Claude Managed Agents ofrece a los desarrolladores un arnés de agente prediseñado que se ejecuta en infraestructura gestionada. Anthropic lo describe como una buena opción para tareas de larga duración y trabajo asíncrono, con conceptos centrales para agentes, entornos, sesiones y eventos.1 Los mismos documentos describen un entorno gestionado en el que Claude puede leer archivos, ejecutar comandos, navegar, ejecutar código, usar servidores MCP y persistir el historial de eventos del lado del servidor.1

El artículo de ingeniería de Anthropic deja más claro el punto arquitectónico que la documentación del producto. El equipo de Managed Agents separó el registro de la sesión, el arnés y el sandbox para que cada parte pueda fallar o cambiar de forma independiente.3 Esa separación importa porque convierte un frágil bucle de agente de un solo contenedor en un sistema con estado de sesión recuperable, entornos de ejecución reemplazables y un límite de seguridad más estrecho alrededor de las credenciales.3

OpenAI se mueve en la misma dirección a través del Agents SDK. Su actualización del 15 de abril de 2026 añadió un arnés nativo del modelo, ejecución nativa en sandbox, una abstracción de manifiesto para los espacios de trabajo y soporte para primitivos comunes como MCP, skills, AGENTS.md, ejecución de shell y aplicación de parches.2 Los documentos del SDK también exponen sesiones para memoria entre múltiples ejecuciones, tracing para generaciones de LLM, llamadas a herramientas, handoffs, guardrails y eventos personalizados, y handoffs para transferir trabajo entre agentes especialistas.456

Esa es la novedad. La pregunta estratégica es distinta: una vez que las plataformas envíen el runtime del agente, ¿qué debería seguir haciendo tu arnés local?

¿Cuál es la división entre runtime y criterio?

La mayoría de los arneses de agentes locales mezclan dos trabajos que no siempre deberían convivir.

El primer trabajo es la infraestructura del runtime. Un runtime inicia sesiones, otorga herramientas, prepara un espacio de trabajo, ejecuta comandos, almacena eventos, maneja interrupciones, reanuda el trabajo, transmite el estado y registra trazas. Ese trabajo se beneficia de la estandarización. También se beneficia de una ingeniería de seguridad que la mayoría de los equipos individuales no deberían reconstruir a menos que tengan una razón sólida.

El segundo trabajo es el criterio. El criterio dice cómo es un buen trabajo, qué afirmaciones públicas necesitan fuentes primarias, cuándo una guía está demasiado obsoleta para publicarse, cuándo un hook hace demasiado ruido para ser aplicado, cuándo un escaneo de fuentes debería convertirse en una nota en lugar de una publicación y cuándo un agente debería rechazar una salida técnicamente correcta pero indigna. Ese trabajo permanece local porque proviene del producto, del equipo y del lector.

La infraestructura gestionada puede ejecutar un mejor bucle. No puede decidir cuál debería ser tu criterio.

¿Qué debería trasladarse a los agentes gestionados?

Mueve los componentes que no codifican los estándares de tu producto.

Componente local Mejor hogar cuando la plataforma lo soporta Por qué
Configuración del sandbox Entorno gestionado o sandbox del SDK Los proveedores pueden mantener el aislamiento, la configuración, las reglas de red y los adaptadores de proveedor.
Persistencia de la sesión Registro de sesión gestionado o almacén de sesiones del SDK El trabajo de larga duración necesita un estado que sobreviva a las ventanas de contexto y a los fallos de los workers.
Flujos de eventos y webhooks Eventos gestionados o cola de tareas a nivel de aplicación La aplicación debería observar el estado sin sondear el estado privado del shell.
Tracing Tracing del proveedor o tu procesador de tracing La depuración del agente necesita spans estructurados para llamadas al modelo, herramientas, guardrails y handoffs.
Pegamento de ejecución de herramientas Herramientas gestionadas, MCP o adaptadores de herramientas del SDK La invocación de herramientas pertenece detrás de interfaces estables, no detrás de convenciones frágiles de prompts.
Fanout multi-agente Orquestación gestionada o handoffs del SDK La delegación necesita visibilidad, filtros de entrada y contratos de handoff claros.

La función Outcomes de Anthropic muestra hacia dónde va esta tendencia. El desarrollador define una rúbrica, el arnés gestionado provee un evaluador independiente y el agente itera contra la retroalimentación del evaluador.7 Eso no elimina los estándares locales. Le da a esos estándares una ranura de runtime.

El mismo patrón se aplica al tracing de OpenAI. El SDK traza por defecto la ejecución, los spans del agente, las generaciones, las llamadas a herramientas de funciones, los guardrails y los handoffs, con controles para deshabilitar el tracing y procesadores para otros destinos.5 Un script local puede aproximar eso. Un sistema en producción debería preferir habitualmente la traza estandarizada y enviarla a donde el equipo ya depura el trabajo.

¿Qué debería permanecer local?

Conserva los componentes que definen tus estándares, tu lector o tu contexto operativo privado.

Criterio del producto. Una plataforma puede ejecutar una tarea; no puede saber si el resultado mejora el producto en su conjunto. Conserva las reglas de criterio que rechazan la salida cargada, genérica o de baja dignidad.

Puertas de evidencia. Conserva las reglas que exigen evidencia de la sesión actual, verificación de la ruta del usuario, brechas nombradas y análisis de la causa raíz. Las trazas gestionadas te dicen qué pasó. Tu estándar decide si la evidencia es suficiente.

Integridad de la escritura pública. Conserva las reglas de citación, las reglas de niveles de fuente, las verificaciones de límites privados, las verificaciones de SEO/AIO y las puertas de publicación cerca del sitio. Un proveedor de modelos no debería decidir qué detalles privados del flujo de trabajo son seguros para publicar.

Memoria del proyecto. Conserva la doctrina concisa del proyecto, las decisiones de estilo, los riesgos conocidos, los límites de las versiones y los registros operativos donde el equipo pueda inspeccionarlos. Mueve solo la capa de almacenamiento cuando un almacén de sesiones gestionado mejore genuinamente la durabilidad.

Inteligencia de fuentes. Conserva la capa de enrutamiento editorial. Un escáner puede encontrar 14 buenos elementos y aun así no producir ninguna publicación si la jugada correcta es monitorear, dar mantenimiento a una guía o tomar una nota privada.

Política de promoción. Conserva las reglas de staging. Una skill puede comenzar solo en modo explícito, un hook puede ejecutarse en modo sombra y un plugin puede quedarse en piloto de instalación hasta que el trabajo real demuestre que ayuda más de lo que distrae.

Esa lista es el verdadero arnés. Los archivos y comandos son solo una de sus implementaciones.

¿Qué error de migración deberían evitar los equipos?

La forma más fácil de arruinar esta migración es preservar la forma en lugar del trabajo.

Los comandos de barra de Claude Code, las skills de Codex, las herramientas del SDK, los resultados gestionados y los servidores MCP no son sintaxis intercambiable para lo mismo. Son superficies de activación distintas. Un comando de barra puede convertirse en una skill. Una skill puede convertirse en una rúbrica de resultado gestionado. Un hook puede convertirse en un procesador de trazas. Un script local puede volverse innecesario una vez que la plataforma exponga sesiones o webhooks.

El artículo de Anthropic sobre agentes de larga duración expone el mismo punto desde la dirección opuesta: la compactación por sí sola no producía trabajo de calidad de producción, así que el patrón eficaz añadió listas de funciones, artefactos de progreso, un estado de handoff limpio y pruebas de extremo a extremo.8 Esas no son convenciones de UI. Son obligaciones de prueba.

La migración no debería preguntar: «¿Dónde pongo /scan-intel?». Debería preguntar: «¿Qué trabajo realizaba el flujo de inteligencia de fuentes?».

Para un escáner de fuentes, el trabajo no es «ejecutar un comando». El trabajo consiste en escanear las fuentes configuradas, demostrar la accesibilidad de las fuentes, puntuar candidatos, rechazar escrituras amplias de baja señal, conservar notas útiles de forma privada y enrutar las oportunidades públicas hacia la revisión editorial. La frase exacta de activación puede cambiar sin perder el flujo de trabajo.

La misma regla se aplica a la doctrina de calidad. No publiques un paquete de prompts privados. Convierte la doctrina en puertas de finalización observables: evidencia, verificación de la ruta del usuario, revisión de límites privados y el derecho a rechazar trabajo que debilite el producto.

¿Cómo se aplica esto a un escáner de inteligencia de fuentes?

Un escáner de inteligencia de fuentes hace que la división se vuelva concreta.

El lado del runtime puede moverse. Una plataforma gestionada puede ejecutar la tarea programada, almacenar la sesión, ejecutar herramientas de navegación o de obtención de feeds, emitir eventos y conservar trazas. Si un escaneo agota su tiempo, la sesión gestionada debería saber qué se ejecutó, qué fuentes fallaron y dónde debería reanudarse la siguiente ejecución.

El lado del criterio debería permanecer local. El escáner aún necesita un mapa privado de fuentes, umbrales de puntuación, verificaciones de duplicados, límites de volumen de escritura y una ruta editorial. Un escaneo que encuentre 14 candidatos no debería publicar automáticamente 14 notas o un artículo. La acción correcta puede ser una nota privada, una tarea de mantenimiento de guía, una cola de monitoreo o la negativa a escribir nada público.

Esa distinción convierte una automatización ruidosa en un flujo de trabajo útil:

Paso del escáner Capa gestionada Capa del arnés local
Obtener fuentes Herramientas de navegador, feed, búsqueda o MCP Mapa de fuentes y niveles de confianza
Persistir el estado de la ejecución Registro de sesión, eventos, trazas Libro mayor de temas y memoria de cobertura previa
Puntuar candidatos Pase opcional de modelo/herramienta Umbrales editoriales y reglas de criterio
Escribir salidas Herramienta de archivos o notas Puerta de volumen de escritura y verificación de límites privados
Enrutar la siguiente acción Evento, webhook o handoff Decisión de publicar, actualizar guía, monitorear o no hacer nada

La misma lógica se aplica a los flujos de programación, mantenimiento de guías, traducción y escritura pública. Mueve la mecánica de ejecución cuando una plataforma la haga mejor. Conserva el estándar que decide si la salida merece existir.

¿Qué lista de verificación deberían usar los equipos antes de mover un arnés?

Usa esta lista de verificación antes de mover cualquier componente del arnés local a una plataforma de agentes gestionados.

Pregunta Si sí Si no
¿El componente solo opera infraestructura del runtime? Muévelo hacia sesiones gestionadas, sandboxes, tracing o eventos. Mantenlo local o como propiedad del proyecto.
¿El componente codifica criterio, confianza o estándares editoriales? Mantén el estándar local; expón solo una rúbrica segura o criterios de aceptación. Considera retirarlo.
¿El componente toca secretos, estado de cuenta o prompts privados? Mantén los detalles privados fuera de los paquetes y artículos públicos. Puede ser publicable como un patrón genérico.
¿La plataforma puede expresar la misma puerta como una rúbrica, traza, hook o procesador? Pilota la versión nativa de la plataforma. Mantén la versión local solo en modo explícito.
¿Ha probado el comportamiento el trabajo real? Promueve de modo explícito a piloto o aplicado. Mantenlo en staging.
¿El componente genera ruido? Simplifícalo, ponlo en modo sombra o elimínalo. Sigue midiéndolo contra resultados reales.

La ruta de promoción debería seguir siendo aburrida:

  1. Inventaría el componente.
  2. Nombra el trabajo que realiza.
  3. Clasifícalo como runtime, criterio, memoria, publicación, inteligencia de fuentes o seguridad.
  4. Porta la versión útil más pequeña.
  5. Ejecútalo en una tarea real.
  6. Registra qué pasó.
  7. Promuévelo, revísalo o elimínalo.

Cualquier cosa más elaborada suele esconder incertidumbre.

¿Cómo deberían dividir los equipos un arnés real hoy?

Para una configuración seria de programación y escritura, yo haría esta división.

Capa del proveedor o gestionada:

  • creación de sandboxes
  • ejecución de archivos
  • sesiones persistentes
  • flujos de eventos
  • webhooks
  • trazas y spans
  • recuperación de workers de larga duración
  • delegación básica multi-agente
  • ejecución de rúbricas cuando el proveedor las soporte

Capa local o del proyecto:

  • AGENTS.md o política equivalente del proyecto
  • estándares de escritura pública
  • reglas de citación y de niveles de fuente
  • doctrina de calidad del producto
  • memoria operativa privada
  • verificaciones de SEO/AIO específicas del sitio
  • enrutamiento de inteligencia de fuentes
  • puertas finales de publicación
  • política de límites de versión para plugins y paquetes compartidos

La línea divisoria no es «gestionado contra autoalojado». La línea divisoria es «runtime de uso común contra criterio de producto».

¿Dónde necesitan todavía precaución los agentes gestionados?

Las plataformas de agentes gestionados no eliminan las partes difíciles. Las mueven.

Aún necesitas un modelo de seguridad para herramientas, archivos, acceso a la red y credenciales. La arquitectura de Anthropic separa explícitamente las credenciales del sandbox donde se ejecuta el código generado, lo cual es la dirección correcta, pero los equipos aún deben configurar correctamente los recursos, las bóvedas y los límites de acceso.3

Aún necesitas observabilidad. Una traza puede mostrar el grafo de llamadas; no puede decirte si el trabajo merecía enviarse. Un evaluador puede evaluar una rúbrica; no puede saber si la rúbrica expresa el criterio correcto.

Aún necesitas límites de contenido. Un artículo público de migración puede describir el patrón, pero no debería volcar prompts privados, internos exactos de hooks, rutas de archivos privadas, listas de fuentes, detalles de cuentas o puntuación editorial propietaria.

Aún necesitas staging. Anthropic señala que Managed Agents sigue en beta, con todos los endpoints requiriendo el encabezado beta managed-agents-2026-04-01, y algunas funciones requieren acceso preview.1 Un runtime en beta puede ser útil sin convertirse en la ruta predeterminada para cada flujo de trabajo.

¿Qué deberían llevarse los equipos?

Para líderes de ingeniería:

  • Mueve el trabajo del runtime hacia sesiones gestionadas, sandboxes, eventos y trazas cuando la plataforma cumpla con tu listón de seguridad.
  • Conserva los estándares locales para evidencia, calidad de fuentes, criterio del producto y límites de versión.
  • Trata las rúbricas gestionadas como ranuras de ejecución para tus estándares, no como un reemplazo de ellos.

Para constructores de agentes:

  • No portes los comandos uno a uno. Porta los trabajos por hacer.
  • Comienza solo en modo explícito, luego promueve después de que una tarea real demuestre valor.
  • Prefiere las trazas, los registros de sesión y los artefactos públicos sobre la arqueología de prompts privados.

Para escritores públicos:

  • Convierte el proceso privado en criterios de aceptación públicos.
  • Cita los documentos oficiales del producto para el comportamiento actual.
  • Rechaza el resumen cuando el mejor artículo sea el marco de decisión.

¿Cuál es el resumen rápido?

Las plataformas de agentes gestionados hacen al arnés local más pequeño, no irrelevante. Mueve el trabajo del runtime a sesiones, sandboxes, trazas, eventos y orquestación gestionados cuando la plataforma se gane esa confianza. Conserva los estándares locales que definen la calidad, la evidencia, la privacidad, la integridad de la escritura pública y qué trabajo merece enviarse.

Preguntas frecuentes: agentes gestionados y arneses locales

¿Los Managed Agents reemplazan un arnés de agente IA local?

No. Las plataformas gestionadas reemplazan más de la capa del runtime: sesiones, sandboxes, flujos de eventos, tracing y ejecución de herramientas. Los arneses locales siguen importando cuando codifican estándares de producto, puertas de evidencia, reglas de escritura pública, límites de privacidad, inteligencia de fuentes y memoria específica del proyecto.

¿Qué debería permanecer en AGENTS.md o CLAUDE.md?

Conserva ahí las reglas duraderas del proyecto: qué valora el producto, cómo se verifica la finalización, qué detalles privados no pueden publicarse, cómo se revisa la escritura pública y qué rutas visibles al usuario deben funcionar antes de que una tarea cuente como hecha. No metas salida transitoria de herramientas o cuerpos de prompts privados en archivos de instrucciones permanentes.

¿Cuándo debería un equipo usar una plataforma de agentes gestionados?

Usa la infraestructura gestionada cuando el trabajo necesite ejecución de larga duración, contenedores seguros, sesiones duraderas, flujos de eventos, finalización asíncrona, tracing u orquestación multi-agente gestionada, y cuando los controles de seguridad, costo y datos del proveedor encajen con el caso de uso.12

¿Qué no debería trasladarse a un paquete público de arnés?

No publiques prompts privados, cuerpos exactos de hooks, rutas de archivos sensibles, identificadores de cuenta, manejo de tokens, listas privadas de fuentes, reglas de puntuación propietarias o cualquier cosa que permita a un extraño reconstruir tu sistema operativo interno. Publica el patrón y los criterios de aceptación.

Referencias


  1. Anthropic, «Claude Managed Agents overview». Consultado el 7 de mayo de 2026. 

  2. OpenAI, «The next evolution of the Agents SDK», 15 de abril de 2026. 

  3. Anthropic Engineering, «Scaling Managed Agents: Decoupling the brain from the hands», 8 de abril de 2026. 

  4. OpenAI Agents SDK, «Sessions». Consultado el 7 de mayo de 2026. 

  5. OpenAI Agents SDK, «Tracing». Consultado el 7 de mayo de 2026. 

  6. OpenAI Agents SDK, «Handoffs». Consultado el 7 de mayo de 2026. 

  7. Anthropic, «Define outcomes». Consultado el 7 de mayo de 2026. 

  8. Anthropic Engineering, «Effective harnesses for long-running agents», 26 de noviembre de 2025. 

Artículos relacionados

Claude Code to Codex Migration Guide 2026

Claude Code to Codex migration guide: move AGENTS.md, skills, hooks, profiles, MCP, public-writing gates, and verified C…

29 min de lectura

Anatomía de una Garra: 84 Hooks como Capa de Orquestación

Karpathy identificó las 'Claws' como una nueva capa arquitectónica. Así es como lucen 84 hooks, 43 skills y 19 agentes c…

16 min de lectura

Code with Claude SF 2026: Lo que Anthropic realmente lanzó

Resumen de Code with Claude SF 2026: límites de tasa de Claude Code duplicados, el acuerdo con SpaceX Colossus 1, 10 pla…

12 min de lectura