Agentes de IA de Claude: cómo revisar la configuración con ant apply

Claude Managed Agents incorporó un cambio operativo muy concreto el 3 de septiembre de 2026: ant apply ya permite convertir archivos de un repositorio en agentes de IA, entornos, habilidades, almacenes de memoria y despliegues activos. El verdadero cambio es que la configuración de los agentes puede pasar por la misma revisión que el código antes de llegar a producción.

Agentes de IA con configuración revisable, no otro atajo de CLI

Claude Managed Agents es el sistema alojado de agentes de Anthropic para trabajos prolongados y asíncronos. Un agente define el modelo, el prompt, las herramientas y las habilidades. Un entorno determina dónde se ejecuta. Un despliegue permite programar la ejecución de ese agente.

No es lo mismo que un subagente de Claude Code guardado en .claude/agents/. Este cambio afecta a los recursos que sustentan el servicio de agentes gestionados de la API de Claude.

Cuando un equipo crea esos recursos desde la Console o mediante llamadas puntuales a la API, el estado útil queda repartido en dos lugares. El servicio remoto conserva el recurso real, mientras que un script, un documento o la memoria de algún compañero explica cómo llegó hasta allí. Cada traspaso obliga a volver a conectar ambas partes.

ant apply traslada esa responsabilidad al repositorio. Los recursos se describen en Markdown, YAML o JSON. La CLI compara los archivos con los recursos remotos, muestra un plan, solicita aprobación y aplica el cambio.

Así, el prompt de sistema, el acceso a herramientas, el entorno, el paquete de habilidades, el almacén de memoria y la programación quedan dentro de un pull request. Quien revisa puede ver qué cambiará antes de que la persona o el trabajo de CI con credenciales de despliegue lo lleve a producción.

Esta guía de trabajo está dirigida a equipos que ya valoran usar Managed Agents. Si solo se utiliza la aplicación Claude, Claude Code o un bucle propio sobre la Messages API, ant apply no modifica esa configuración.

El lockfile resuelve el traspaso

El archivo importante no es solo la definición del agente. También está claude-lock.json.

La primera ejecución correcta de apply escribe ese lockfile en el directorio desde el que se lanza el comando. Conviene ejecutarlo desde la raíz del repositorio e incluir después el lockfile en un commit junto con los archivos de recursos.

El lockfile registra el origen de la API, la organización, el espacio de trabajo y el ID remoto creado a partir de cada archivo local. También guarda un hash local y otro remoto. El hash local detecta cambios en un archivo; el remoto, cambios realizados sobre el recurso desde la Console u otra vía de la API.

Puede entenderse como una libreta de direcciones unida a un comprobante. El archivo de recursos declara el estado deseado. El lockfile indica qué objeto activo pertenece a ese archivo y cómo estaban ambos lados después del último apply.

Eso simplifica el relevo. La siguiente persona responsable o el siguiente runner de CI no tiene que adivinar qué ID de agente corresponde a agents/reviewer.md: lee el mapeo y actualiza el mismo recurso, en lugar de crear una copia nueva.

Los recursos pueden remitirse unos a otros mediante rutas relativas allí donde la API normalmente exigiría un ID. El comando apply calcula el orden de las dependencias, crea o actualiza cada recurso y completa los ID reales. Un agente puede apuntar al directorio de una habilidad. Un despliegue puede apuntar a su agente, entorno y almacén de memoria.

Las referencias a agentes y habilidades quedan fijadas en la versión aplicada durante esa ejecución. Si una habilidad procede de una URL de GitHub, se fija al commit resuelto hasta que se utiliza --upgrade. Así, la revisión tiene un objetivo concreto y no aquello que por casualidad se encuentre al final de una rama que sigue avanzando.

La cuenta económica está en el trabajo de traspaso

ant apply no elimina el costo de operar agentes. Lo mueve de una partida a otra.

Antes, la partida era la configuración repetida, la verificación y los traspasos. Ahora incluye preparar el repositorio, revisar pull requests, asignar la responsabilidad de CI y mantener el lockfile. Que resulte más barato depende de la frecuencia con la que cambie la configuración y de cuántos lugares deban recibir el mismo cambio.

El siguiente cálculo es un ejemplo identificado como tal, no un benchmark ni una afirmación de ahorro de Anthropic.

Supongamos que un equipo realiza cuatro cambios de configuración al mes en tres entornos de destino. Cada traspaso manual requiere 15 minutos por cambio y entorno.

El trabajo manual mensual es:

4 changes × 3 environments × 15 minutes = 180 minutes

Supongamos ahora que la vía del repositorio necesita 30 minutos de revisión por cambio, más 10 minutos para aplicar y comprobar cada entorno.

El trabajo mensual con el repositorio es:

4 changes × (30 review minutes + 3 × 10 apply minutes) = 240 minutes

Con esos datos, el flujo basado en el repositorio es 60 minutos más lento cada mes. Esa es la conclusión útil cuando el traspaso manual ya cuesta poco.

El punto de equilibrio está en 20 minutos por traspaso manual, antes de incluir la preparación y el mantenimiento. Si el traspaso manual medido requiere 30 minutos, esa misma vía manual pasa a 360 minutos, mientras que la del repositorio se mantiene en 240 minutos. La diferencia es de 120 minutos, pero seguirá siendo solo el resultado de una hoja de cálculo hasta que el equipo mida el trabajo real.

Hay que asignar a esos minutos el costo laboral total correspondiente. Después se suman la preparación inicial y el costo recurrente de revisar planes fallidos, resolver divergencias y mantener CI. La herramienta se justifica cuando esa cifra completa mejora el proceso existente, no cuando la demostración se ve ordenada.

Qué equipos obtienen valor de este flujo

Un equipo de plataforma concentra la revisión

La persona responsable de plataforma en una empresa de software puede reunir un agente, sus habilidades, su entorno, su almacén de memoria y su despliegue programado en un único pull request. Así, quienes revisan inspeccionan todo el cambio operativo de forma conjunta, sin comparar un archivo de prompt con capturas de una consola remota.

El beneficio es la trazabilidad. El equipo puede enlazar un cambio integrado con el plan de recursos y el estado posterior del lockfile.

Una agencia mejora el traspaso al cliente

La persona responsable de tecnología en una agencia puede conservar los archivos de cada cliente junto al lockfile de la organización y el espacio de trabajo correspondientes. Cuando otro operador asume el proyecto, el mapeo viaja con el repositorio.

El beneficio es reducir las dudas sobre la identidad de los recursos durante el traspaso. Eso no vuelve portátil un lockfile entre clientes. Apply rechaza credenciales vinculadas a otra organización u otro espacio de trabajo, que es precisamente el límite que la agencia debe conservar.

Un equipo de operaciones formaliza el paso de despliegue

La persona responsable de operaciones puede previsualizar un cambio en un pull request y aplicar el directorio después del merge, desde la rama predeterminada, con ant apply --yes .. Ese punto al final importa: un apply sin argumentos solo reconcilia recursos que ya figuran en el lockfile y puede omitir un archivo recién añadido.

El beneficio es contar con un paso de despliegue repetible. Aun así, necesita un único responsable durante la ejecución, porque apply no bloquea el lockfile. Dos trabajos simultáneos pueden competir por el mismo estado.

Un responsable de seguridad puede detener la divergencia

La persona responsable de seguridad puede usar el hash remoto para detectar una edición desde la Console antes de que el estado del repositorio la sobrescriba. El comando apply bloquea la operación si un recurso gestionado se editó, archivó o eliminó fuera de los archivos.

El beneficio es que obliga a tomar una decisión explícita: investigar y conciliar el cambio remoto, o usar --force para sobrescribirlo de forma deliberada. Los equipos que necesiten Zero Data Retention o cobertura de un HIPAA Business Associate Agreement deben esperar antes de usar Managed Agents, porque el servicio no reúne actualmente los requisitos para ninguno de los dos.

Un repositorio mínimo listo para aplicar

ant apply requiere la versión 1.30.0 de la CLI o una posterior. La guía oficial de inicio rápido documenta la instalación con Homebrew y el inicio de sesión mediante el navegador.

1. 1

   Instalar y autenticar

   Instale la CLI, compruebe la versión e inicie sesión:

   brew install anthropics/tap/ant
   ant --version
   ant auth login

2. 2

   Crear un archivo de agente

   Cree agents/summarizer.md con la definición mínima documentada:

   ---
   name: Summarizer
   model: claude-opus-5
   tools:
     - type: agent_toolset_20260401
   ---
   
   You are a helpful assistant that writes concise summaries.

3. 3

   Aplicarlo una vez desde la raíz del repositorio

   Ejecute el comando documentado para un solo archivo:

   ant apply agents/summarizer.md

   Revise el plan, solicite los detalles si hace falta ver la diferencia campo por campo y, después, apruébelo. Una ejecución correcta crea el agente remoto y escribe claude-lock.json junto al proyecto.

4. 4

   Separar la previsualización y la aplicación en trabajos distintos

   Use el comando documentado de previsualización en los pull requests:

   ant apply --dry-run .

   Después de integrar el cambio, serialice el trabajo de despliegue y aplique el directorio indicado:

   ant apply --yes .

   Incluya el lockfile actualizado en un commit al final, también después de un fallo parcial de apply, porque esa ejecución parcial puede haber creado recursos y haberlos registrado.

La trampa del código de salida en CI

Esto importa porque la divergencia remota forma parte del funcionamiento normal. Alguien puede editar un agente en la Console entre la revisión y la integración. La previsualización debe convertir esa situación en una decisión visible, no en una casilla verde que el trabajo de despliegue descubre más tarde.

Para el trabajo de apply, utilice Workload Identity Federation en lugar de una clave de API almacenada. Mantenga el trabajo ligado a la organización y al espacio de trabajo registrados en el lockfile y permita una sola ejecución de apply a la vez.

Los límites reales

Gestionar archivos como código no vuelve administrables todos los recursos remotos.

ant apply no puede adoptar un agente creado de forma independiente en la Console o con ant beta:agents create. Si los archivos y el lockfile proceden de la opción Export as code de la Console, apply sí puede actualizar esos recursos exportados. En cualquier otro caso, aplicar un archivo equivalente crea otro recurso.

La eliminación también es conservadora. Al quitar un archivo, el recurso remoto permanece y aparece una advertencia. --prune elimina el recurso remoto; cambiar el nombre de un archivo, en cambio, declara uno nuevo y conserva el anterior hasta que se elimine de forma explícita.

Por eso, --force y --prune son controles de producción, no simples atajos de limpieza. Ambos deben quedar sujetos a revisión. Un cambio de nombre incorrecto seguido de una poda automática puede eliminar el recurso que el despliegue aún espera encontrar.

El lockfile también se convierte en estado operativo compartido. Hay que incluirlo en un commit después de cada apply, proteger su rama y serializar las escrituras. Si una ejecución falla a mitad de camino, no se debe descartar el cambio del lockfile solo porque el trabajo esté en rojo.

Por último, el servicio sigue en fase beta. Claude Managed Agents está habilitado de forma predeterminada para las cuentas de la API de Claude, pero los equipos que necesiten Zero Data Retention o un HIPAA BAA se enfrentan a un impedimento del propio producto que la revisión desde el repositorio no resuelve.

Qué hacer el lunes

Conviene actuar esta semana si más de una persona modifica los mismos recursos de Managed Agents, si una misma configuración pasa por varios entornos o si los despliegues programados necesitan un responsable y un registro de revisión.

Conviene esperar si un único operador mantiene un experimento estable, si el costo medido del traspaso es menor que el de la nueva revisión o si la política de datos exige Zero Data Retention o cobertura de un HIPAA BAA.

Este cambio no afecta a los agentes que solo se ejecutan mediante Claude Code, la aplicación Claude o un bucle personalizado de la Messages API sin recursos de Claude Managed Agents.

El lunes, elija un agente que no esté en producción. Haga pasar su definición y su lockfile por un pull request real. Registre los minutos que requieren tanto el traspaso actual como la vía revisada. Después, introduzca un cambio remoto en ese entorno seguro y compruebe que la validación del pull request trate el plan bloqueado como tal. Solo después de esa prueba debería ejecutarse ant apply --yes . tras integrar los cambios.

Reciba en el boletín el próximo análisis práctico de flujos de trabajo con IA.