# Cómo debe programar un agente: zonas horarias, envíos escalonados y no saturar cuarenta páginas a las 9:00

_2026-09-18 · Cómo debe programar un agente de IA en muchas cuentas: offsets ISO 8601, zonas horarias y horario de verano, escalonado, grupos por día y cancelaciones._

Una buena estrategia de programación para un agente se resume en tres reglas: enviar siempre las horas en ISO 8601 con un offset explícito calculado a partir de la zona horaria del cliente, dejar que la plataforma escalone el envío cuenta por cuenta en lugar de dispararlo todo a la vez, y repartir las listas grandes de cuentas en publicaciones y horarios separados en vez de hacer una sola tanda gigante. Primero el borrador, la programación como paso aparte, y que cancelar sea fácil.

Todo lo que sigue sirve para aterrizar esas reglas, con los campos exactos que espera Shager.

## ¿Por qué los agentes se equivocan con la hora?

A los modelos de lenguaje se les dan mal los relojes. No saben qué hora es si no se lo dices, escriben sin problema `2026-11-02T09:00:00` sin offset y convierten entre zonas horarias de cabeza. Cada una de esas cosas puede hacer que una publicación salga a las 7:00 en lugar de a las 9:00.

Shager cierra una puerta rechazando la ambigüedad: `schedule_at` tiene que estar en ISO 8601 con offset, por ejemplo `2026-10-20T09:00:00+03:00`. Una marca de tiempo sin `Z` ni offset no pasa la validación. Ese formato es el perfil definido en el [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339), y vale la pena nombrarlo así en las instrucciones de tu agente.

La otra puerta es el propio offset. `+03:00` es correcto para Israel en octubre e incorrecto en diciembre. Los offsets cambian con el horario de verano, y las fechas de cambio son distintas en Israel, la Unión Europea y Estados Unidos. El agente nunca debe fijar un offset a mano. Debe resolver el nombre de la zona del cliente con la [base de datos de zonas horarias de la IANA](https://www.iana.org/time-zones), que incluye cualquier lenguaje de programación habitual, y calcular el offset para esa fecha concreta.

```python
from datetime import datetime
from zoneinfo import ZoneInfo

local = datetime(2026, 11, 2, 9, 0, tzinfo=ZoneInfo("Europe/Berlin"))
print(local.isoformat())   # 2026-11-02T09:00:00+01:00
```

Cada espacio de trabajo de Shager tiene además una `timezone`, un nombre de zona IANA que se define al crearlo (por defecto, `Asia/Jerusalem`). Haz que el agente la lea y la use. Cuando trabajas con [un agente para muchos clientes](/en/blog/one-agent-many-clients), no todos van a estar en la misma zona, y el espacio de trabajo es el único lugar que registra en qué zona vive cada cliente.

## Primero el borrador, después la programación

`create_post` puede programar en el acto si le pasas `schedule_at`. En trabajos para clientes, casi nunca dejo que los agentes lo hagan. El patrón más seguro son dos llamadas:

1. `create_post` sin `schedule_at`, que guarda un borrador.
2. `schedule_post` con el ID de la publicación y la hora, cuando una persona o una regla lo haya autorizado.

```json
{
  "tool": "schedule_post",
  "arguments": {
    "workspace_id": "ws_example",
    "post_id": "pst_example",
    "schedule_at": "2026-10-20T09:00:00+03:00"
  }
}
```

También hay un motivo de permisos. En Shager, programar requiere el permiso `publish` en la clave de API, mientras que para redactar alcanza con `write`. Una persona otorga `publish` de forma explícita al reclamar el entorno de prueba de un agente, y puede crear claves sin ese permiso. Esa división te permite darle mucha libertad a un agente que redacta y dejar el último paso en manos de una persona. Los detalles están en [claves de API, permisos y auditoría](/en/blog/api-keys-scopes-and-audit).

`schedule_post` además hace algo útil cuando falla: si alguna cuenta rechazaría la publicación, o si se requiere la aprobación del cliente y falta, devuelve un error con un motivo claro en lugar de programar una tanda que va a fallar a medias.

## ¿Cuánto dura de verdad una tanda escalonada?

Shager publica cuenta por cuenta, con una pausa aleatoria entre cuentas de la misma red. El campo `stagger_seconds` define ese rango, por defecto `[30, 90]`. Las redes corren en paralelo, así que la duración de una tanda la marca la red con más cuentas.

La cuenta es tan sencilla que el agente puede hacerla antes de elegir la hora:

| Cuentas en la red más grande | Escalonado | Espera media | Duración aproximada |
|---|---|---|---|
| 10 | [30, 90] | 60 s | unos 9 minutos |
| 40 | [30, 90] | 60 s | unos 39 minutos |
| 40 | [60, 180] | 120 s | unos 78 minutos |
| 120 | [30, 90] | 60 s | unas 2 horas |

La última fila es la que sorprende. Si un cliente dice "todo tiene que estar publicado antes de las 10:00" y tienes 120 páginas de Facebook, programar a las 9:00 no alcanza. O empiezas antes o divides la tanda.

No respondas a un plazo reduciendo el escalonado a `[0, 5]`. La pausa existe para que una tanda masiva no parezca una ráfaga desde una sola fuente. Nuestro artículo sobre [cómo evitar bloqueos por spam al publicar a escala](/en/blog/avoid-spam-blocks-when-posting-at-scale) explica por qué el ritmo importa más que cualquier texto individual.

## Divide por grupo, no por hora

Para clientes grandes, el patrón más sólido es una publicación por grupo de cuentas, cada una con su propio horario. Una cadena de tiendas con 90 páginas de sucursales puede estar agrupada por región. El agente crea tres publicaciones, una por cada grupo regional, programadas en mañanas distintas o repartidas a lo largo del día.

```json
{
  "tool": "create_post",
  "arguments": {
    "workspace_id": "ws_example",
    "group_ids": ["grp_north"],
    "caption": "Winter hours start Sunday at every northern branch.",
    "per_channel": [
      { "channel_id": "ch_fb_haifa", "caption": "Haifa branch: winter hours start Sunday. We open at 8:30." }
    ],
    "campaign": "winter-hours",
    "stagger_seconds": [60, 150]
  }
}
```

Los grupos se crean con `create_group`, que recibe un nombre y una lista de `channel_ids`. Cuando apuntas a un grupo, se suman todos sus canales activos.

## Límites de las redes que el agente debe respetar

Las propias redes ponen un tope a lo que una cuenta puede publicar a través de sus API. Meta documenta un límite por cuenta de publicaciones de Instagram hechas por API en una ventana móvil de 24 horas, y ofrece un [endpoint content_publishing_limit](https://developers.facebook.com/docs/instagram-platform/content-publishing) para consultar el uso actual. YouTube asigna cuota de API por proyecto, con un [valor por defecto de 10.000 unidades por día](https://developers.google.com/youtube/v3/getting-started), y las subidas están entre las operaciones más caras.

Shager se encarga del envío, pero la planificación es cosa del agente. Una cuenta que recibe seis publicaciones en un día es un problema de estrategia antes que un problema de API. A mis agentes les doy una regla sencilla: no más de una publicación en el feed por cuenta y por día, salvo que una persona diga lo contrario.

## Calendarios, festivos y días tranquilos

El calendario de Shager incluye los días festivos de Israel, algo importante para clientes israelíes, porque una publicación programada para la víspera de una fiesta importante le llega a un público desconectado. Para clientes de otros lugares, pon en las instrucciones del agente el calendario propio del cliente, con sus cierres y eventos. Los modelos saben más o menos cuándo caen los festivos nacionales; no saben que el almacén de este cliente cierra por inventario el último viernes de cada trimestre.

## Cancelar y mover

`cancel_post` desprograma una publicación que todavía no empezó a publicarse. No la elimina: vuelve a ser un borrador aprobado, así que el agente puede llamar otra vez a `schedule_post` con una hora nueva. Cancelar sirve para publicaciones que siguen en espera; una vez que empezó la publicación, `cancel_post` ya no aplica.

Antes de mover cualquier cosa, el agente debería llamar a `list_posts` con `status` en `SCHEDULED` para ver qué hay ya en la cola de ese espacio de trabajo. Dos tandas programadas que caen sobre las mismas cuentas en la misma hora es el error autoinfligido más común que veo.

## Preguntas frecuentes

### ¿Qué zona horaria usa Shager si el agente envía UTC?

Una marca de tiempo con `Z` no es ambigua, así que Shager la programa en ese instante exacto. La zona horaria del espacio de trabajo importa para cómo ven las personas la programación en el calendario y para el propio razonamiento del agente. Enviar la hora local con el offset correcto hace que los registros del agente sean legibles para las personas que los revisan.

### ¿Puede el agente programar distintas cuentas a distintas horas en una sola publicación?

Una publicación tiene un solo `schedule_at`, y después las cuentas salen en la secuencia escalonada. Para horarios realmente distintos, crea publicaciones separadas, normalmente una por grupo. Eso además ordena los informes, porque cada publicación puede llevar su propio `label`.

### ¿Cuál es un escalonado razonable por defecto?

El valor por defecto, `[30, 90]`, es razonable para la mayoría de las tandas. Para video y para tandas de más de unas 50 cuentas en una red, lo amplío a algo como `[60, 150]` y empiezo antes. El costo es tiempo, no alcance.

## Por dónde seguir

Pon estas reglas en las instrucciones fijas de tu agente en lugar de repetirlas en cada tarea. El artículo de [prompts para un agente de contenido](/en/blog/prompts-for-a-content-agent) tiene un bloque de programación que puedes pegar tal cual.

---
Source: https://shager.ai/es/blog/scheduling-strategy-for-agents