Cómo construir automatizaciones de agentes efectivas

A medida que la IA acelera nuestro trabajo, resulta cada vez más difícil mantenerse al día. En Anthropic, las automatizaciones simples de agentes se usan con frecuencia como ayuda. A menudo se ejecutan según un horario, recopilan contexto en segundo plano y nos informan proactivamente de lo que necesitamos saber. Pero es difícil construir automatizaciones de agentes efectivas: pueden perder acceso a una fuente sin que nadie se dé cuenta o dejar de seguir nuestras preferencias.

Usando Claude Managed Agents (beta), creamos una implementación de referencia que lee fuentes personalizadas (por ejemplo, Slack y repositorios de GitHub) según un horario, realiza un seguimiento de qué cambió desde la última ejecución y publica lo que necesitas saber (por ejemplo, en Slack). En este artículo, repasamos cada paso, compartimos una implementación de referencia y proporcionamos un comando para ejecutar en Claude Code que configura el agente por ti.

OBTENER EL CÓDIGO

La implementación de referencia está aquí. Para un recorrido interactivo, ejecuta el siguiente comando en Claude Code. La claude-api skill puede ayudar a configurar el agente siguiendo las pautas de este artículo:

/claude-api managed-agents-onboard https://claude.dev/blog/building-effective-agent-automations/

Para esta implementación de referencia, necesitas una aplicación de Slack (créala desde el manifiesto) y un token de GitHub. Los archivos proporcionados (mostrados a continuación) son la configuración de los recursos de la API de Claude, incluyendo el agente, su entorno, los almacenes de memoria, el vault y el despliegue.

daily-brief/
├── agent.md                        model, tools, instructions
├── deployment.md                   schedule, time zone, budget, input message
├── environment.yaml                network allowlist
├── memory_store_preferences.yaml   user preferences
├── memory_store_state.yaml         the agent's bookmarks, ledger, notes, and run records
├── vault.yaml                      the vault that holds the credentials
├── claude-lock.json                resource IDs, written by ant apply
└── slack/manifest.yaml             one bot app

ant apply, un comando en la CLI de ant, lee estos archivos, crea los recursos en tu espacio de trabajo de la API de Claude (donde la plataforma los almacena y ejecuta) y registra los IDs en claude-lock.json.

Usaremos este comando en las secciones siguientes. Una vez configurado, la automatización se ejecuta según un horario en la infraestructura de Anthropic, por lo que no es necesario mantener nada en ejecución en tu máquina.

VISIÓN GENERAL

El agente que construiremos tiene seis componentes, cubiertos en este orden:

• Fuentes - Una lista nombrada de lugares para leer
• Destino - Un único lugar donde el agente puede escribir
• Agente - El modelo, las herramientas y los pasos de ejecución en agent.md
• Horario - Un cronograma de cron
• Memoria - Tus preferencias y la memoria propia del agente
• Salvaguardas - Acceso de solo lectura donde el agente solo lee, y un límite de gasto por ejecución

FUENTES

El agente lee dos fuentes predeterminadas: canales de Slack y pull requests de GitHub. Los canales y repositorios están listados en tu preferences archivo. La plantilla puede extenderse para usar otras fuentes.

Dale al agente sus propias credenciales con ámbito limitado

Con Managed Agents, las credenciales viven en bóvedas (vaults). El agente puede referenciar estas credenciales, pero los valores reales permanecen en la bóveda, fuera del sandbox donde se ejecuta el código de Claude (véase aquí y aquí):

• servidores MCP (GitHub). El agente llama a las herramientas de MCP a través de un proxy que se ejecuta fuera del sandbox. El proxy encuentra la credencial de la bóveda cuya URL coincide con la del servidor.

• El shell (Slack). El agente llama a la API de Slack con curl usando la herramienta bash dentro del sandbox. El sandbox solo contiene un marcador de posición opaco, $SLACK_BOT_TOKEN. A medida que la solicitud sale del sandbox, la plataforma inserta el token real para los hosts que permitas.

Crea la bóveda usando la ant CLI y el archivo de plantilla del repositorio:

ant apply vault.yaml

Esto crea la bóveda en tu espacio de trabajo de la API de Claude, donde la plataforma la almacena, y registra su ID en claude-lock.json. Luego añade cada credencial a la bóveda con el SDK de TypeScript. Aquí tienes un ejemplo que muestra cómo añadir la credencial de Slack:

const vaultId = process.env.VAULT_ID!; // the vault's ID, from claude-lock.json

await client.beta.vaults.credentials.create(vaultId, {
  display_name: "SLACK_BOT_TOKEN",
  auth: {
    type: "environment_variable",
    secret_name: "SLACK_BOT_TOKEN",
    secret_value: process.env.SLACK_BOT_TOKEN!,
    networking: { type: "limited", allowed_hosts: ["slack.com"] },
    injection_location: { header: true },
  },
});

Después de crear la bóveda y añadir cada credencial, adjunta la bóveda al despliegue. Copia el ID de la bóveda desde claude-lock.json hacia vault_ids en el archivo de despliegue, deployment.md.

Leer desde donde lo dejaste

Un error común es pedirle al agente que lea una ventana fija como "las últimas 24 horas." Una ejecución tardía deja un hueco y una ejecución temprana repite elementos. En su lugar, dale al agente un marcador por fuente. Al final de cada ejecución, el agente escribe en un archivo la marca de tiempo del elemento más nuevo que leyó de cada fuente, bookmarks.json, con una entrada por fuente: "slack": "2026-09-14T13:02:11Z".

La siguiente ejecución parte de esos marcadores, de modo que su ventana se estira o se encoge para cubrir todo lo ocurrido desde la última ejecución. Los marcadores viven en el almacén de memoria llamado state: una carpeta de archivos de texto que la plataforma monta en el sandbox de cada ejecución bajo /mnt/memory/ y conserva entre ejecuciones. El agente la lee y escribe en ella con sus herramientas de archivos ordinarias, y las instrucciones en agent.md le indican cómo.

No confundas una lectura fallida con un día tranquilo

Si un servidor MCP está caído o su token ha expirado, la ejecución igualmente arranca, solo que sin las herramientas de ese servidor. La sesión registra un error, pero el agente no ve nada de esa fuente e informa "nada nuevo".

Tres reglas en agent.md ayudan a corregir esto. Cuando una fuente falla, el agente: deja el marcador de la fuente donde está, redacta el resumen con las otras fuentes, y termina el resumen con una línea que indica qué no pudo leer ("pull requests no disponibles en esta ejecución"), para que el lector quede informado.

DESTINO

Nuestra plantilla publica en un canal de Slack, con una publicación fechada cada vez que se ejecuta.

El agente publica en Slack usando la herramienta bash en su sandbox, con el mismo token de bot con el que lee.

Nada tiene que aprobar la publicación. El agente la envía con un comando bash, y la herramienta bash integrada se ejecuta sin pedir aprobación por defecto. slack.com también está en la lista de permitidos del environmentdel agente, el sandbox en el que se ejecuta. La publicación es una sola petición:

curl -s https://slack.com/api/chat.postMessage \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
  -H "Content-Type: application/json; charset=utf-8" \
  -d '{"channel": "C0123456789", "text": "Daily brief, Tue Sep 15 ..."}'

Confirma que la publicación se realizó antes de registrarla

Una vez confirmada una publicación, el agente actualiza su registro de elementos reportados y sus marcadores. Si esos registros no coinciden con lo que realmente se publicó, pueden ocurrir dos cosas. Si el agente registra una publicación que nunca se concretó, los marcadores avanzan y esos elementos nunca se reportan. Si publica de nuevo porque no está seguro de que la primera publicación se haya realizado, los lectores reciben el mismo resumen dos veces.

Tres reglas en agent.md previenen esto. Primero, el agente busca el título de hoy en los mensajes recientes del canal y no publica si la edición ya está allí. Segundo, la publicación cuenta como enviada solo si Slack devuelve "ok": true y un ts de mensaje. Tercero, el agente actualiza el registro y los marcadores solo después de esa confirmación. Si el resultado no está claro, marca la ejecución como "quizás publicada" y no cambia nada más, de modo que no se pierde nada.

El agente mantiene un registro de ejecución en su almacén de memoria (runs/<date>.md). Marca la ejecución como "posting" antes de la publicación, luego "posted" con el ID del mensaje, o "maybe posted."

AGENTE

En Claude Managed Agents, un agent es una configuración versionada: un modelo, un system prompt y herramientas. Cada ejecución sigue sus pasos de ejecución y se detiene.

En nuestra implementación de referencia, la configuración del agente es agent.md:

---
name: Daily brief
model: claude-sonnet-5-5
mcp_servers:
  - type: url
    name: github
    url: https://api.githubcopilot.com/mcp/
tools:
  - type: agent_toolset_20260401
    configs:
      - name: web_search
        enabled: false
      - name: web_fetch
        enabled: false
  - type: mcp_toolset
    mcp_server_name: github
    default_config:
      permission_policy:
        type: always_allow
---

[Eight numbered run steps; the full text is in agent.md in the repo.]

El frontmatter proporciona el nombre del agente, el modelo, las herramientas y los servidores MCP. El cuerpo contiene las instrucciones del agente. Las herramientas MCP solicitan aprobación de forma predeterminada y no hay nadie presente para concederla, por lo que el conjunto de herramientas de GitHub está configurado en always_allow y el token de GitHub es read-only.

Mantén el informe breve

agent.md orienta a Claude hacia la brevedad:

4. Decide. An item earns a line when the reader would act on it today, or it changes a decision they are about to make. When unsure, leave it out. Most days that is a few items, sometimes none. A count ("12 open reviews") is not an item; link the ones that are blocked. An item already in the ledger and still open is carried as one marked line ("still waiting, day 3"), not re-reported; a closed item is dropped without comment. Do not bring back a topic the preferences file has retired.

Verifica de nuevo cualquier cosa que siga abierta justo antes de publicar

Los elementos pueden cambiar entre el momento en que el agente lee las fuentes y el momento en que publica. Justo antes de publicar, agent.md instruye al agente a volver a comprobar el estado en vivo de cada artículo:

5. Verify. The world moved while you read. For every item you will report, re-check its live source just before posting: resolved since you read it, drop it; still open but changed, fix the line; cannot confirm, drop it and list it in the run record's cuts. One stale "still waiting on you" costs more trust than ten missing items, so never hedge an item's status: assert it or drop it. Every link is copied from the source's own link field (a pull request's html_url, a Slack permalink), never assembled by hand.

HORARIO

Con Claude Managed Agents, el agente es solo un archivo de configuración; un despliegue lo ejecuta. El despliegue nombra al agente, el entorno y el primer mensaje de cada ejecución. También contiene el programa, el vault, los almacenes de memoria y el presupuesto. Cada vez que se activa el programa, la plataforma inicia un agente nuevo sesión.

En nuestra plantilla, la implementación se captura en deployment.md, con el primer mensaje como su cuerpo:

---
name: Daily brief
agent: ./agent.md
environment_id: ./environment.yaml
schedule:
  type: cron
  expression: "32 7 * * 1-5"
  timezone: America/New_York
vault_ids: [vlt_...]   # the vault you create under Sources
resources:
  - path: ./memory_store_preferences.yaml
    access: read_only
    instructions: The reader's preferences. Re-read them every run. Never write here.
  - path: ./memory_store_state.yaml
    access: read_write
    instructions: Your state. Bookmarks, ledger, notes, proposals, and run records.

---

Write today's brief.
The reader's time zone is America/New_York. Work out every date in that zone.

Follow your run steps in order. Today's edition is titled "Daily brief, <weekday> <month> <day>".

Esto crea el despliegue con el agente, el entorno y los almacenes de memoria que registra por ruta.

ant apply deployment.md

Para probarlo sin esperar a la programación, inicia una ejecución manualmente con ant beta:deployments run --deployment-id <id>, usando el ID de claude-lock.json.

Calcula las fechas en tu zona horaria

Un error común es que el agente llame a esta mañana "ayer" porque calcula las fechas en la zona horaria del servidor. En deployment.md, el campo timezone define cuándo se ejecuta la corrida y la segunda línea del cuerpo le indica al agente qué zona usar para las fechas.

MEMORY

Cada corrida comienza en un sandbox nuevo sin memoria de la anterior. Sin memoria, el feedback no se consolida. Sin embargo, una memoria desactualizada puede confundir al agente: informa que un elemento sigue pendiente después de haberse resuelto, u omite uno que sigue abierto porque fue "ya reportado."

Nuestra plantilla mantiene dos almacenes de memoria, las carpetas montadas bajo /mnt/memory/ (ver Fuentes):

• preferences (tuya, de solo lectura para el agente): qué canales y repos leer, qué omitir, el límite de longitud, el destino y cuándo detenerse.

• state (del agente, de lectura y escritura): los marcadores, un registro de lo que reportó, un expediente por corrida, los cambios que propone a tus preferencias y notas sobre cómo se comporta cada fuente ("devuelve solo los 50 elementos más recientes").

ant apply deployment.md crea el almacén de preferencias, pero no el archivo dentro de él. Antes de la primera corrida, escribe allí tu preferences.md con el scripts/seed-preferences.sh.

Relee tus preferencias al inicio de cada corrida

Un problema frecuente ocurre cuando una copia de las preferencias queda incrustada en el prompt, lo que sigue aplicando reglas que ya cambiaste. Haz que el agente lea el archivo de nuevo en cada corrida. Si no puede leer el archivo, debe detenerse y decirlo en lugar de ejecutarse con los valores predeterminados.

Lleva un registro de lo que ya reportaste, y reporta el cambio

El agente mantiene un registro, ledger.md, de cada elemento que ha reportado, para que el resumen no se repita. Cada línea anota cuándo se reportó el elemento, de dónde provino, un ID que no cambia (una marca de tiempo de un mensaje de Slack o un número de pull request) y su último estado conocido:

2026-09-09 slack:C0123456789 1788963600.000100 refund thread: customer waiting on a decision
2026-09-11 github 481 review blocked, day 2 (still waiting)
2026-09-11 slack:C0234567891 1789117333.000300 enterprise escalation: owner named, in progress

GUARDRAILS

Como nuestra automatización se ejecuta "en segundo plano" según un horario, establecemos límites sobre lo que el agente puede hacer y cuánto puede gastar.

Límites sobre lo que puede hacer

El agente lee mensajes e incidencias escritos por otras personas, y ese texto puede interpretarse como instrucciones. Limita lo que el agente podría hacer si las siguiera. En nuestro ejemplo, el token de GitHub y el almacén preferences son de solo lectura, y el entorno solo alcanza los hosts de su lista de permitidos. Una instrucción plantada aún puede cambiar lo que dice el resumen, incluso a través de las notas que el agente guarda entre corridas. No puede escribir en GitHub ni editar tus reglas.

Slack es la excepción: el mismo token publica, así que invita al bot solo donde necesite leer o publicar.

Fija el límite de gasto a partir de corridas reales

Un límite de gasto te protege de costos descontrolados. Empieza con tres a cinco veces el costo de una corrida normal y luego ajústalo a medida que veas números reales. Una corrida que alcanza su límite se pausa en lugar de fallar, así que un límite demasiado bajo se ve como un resumen que se quedó callado. El límite es el budget en deployment.md. Cada corrida recibe el monto completo, y una corrida que lo alcanza se pausa con un budget_reached motivo de parada:

budget:
  type: limit
  max_list_cost:
    amount: "500" # a string, in cents: "500" is $5.00
    currency: USD

PRIMEROS PASOS

Nuestra implementación de referencia se reduce a seis reglas:

• Lea cada fuente desde un marcador, no desde una ventana de tiempo fija.
• Informe una lectura fallida como ilegible, nunca como un día tranquilo.
• Vuelva a verificar cada elemento justo antes de publicarlo.
• Cuente una publicación como enviada solo cuando Slack lo confirme, y luego actualice los marcadores y el registro.
• Vuelva a leer sus preferencias en cada ejecución, desde un almacén que el agente no pueda editar.
• Dé al agente acceso de solo lectura donde solo necesite leer, y limite lo que cada ejecución puede gastar.

Claude Code puede guiarlo a través de las orientaciones proporcionadas en este artículo. Primero, actualice:

claude update

Luego, use la habilidad claude-api:

/claude-api managed-agents-onboard https://claude.dev/blog/building-effective-agent-automations/

La habilidad claude-api lee esta publicación, propone una configuración, escribe los archivos en una carpeta agents/ de tu proyecto y crea los recursos con ant apply. Trata esto como un punto de partida y personaliza el agente según tus fuentes, destino o preferencias de memoria.