# Come un agente deve programmare i post: fusi orari, invii scaglionati e quaranta pagine che non escono tutte alle 9:00

_2026-09-18 · Come un agente IA deve programmare post su molti account: offset ISO 8601, fusi orari e ora legale, calcolo degli scaglionamenti, gruppi divisi e annullamenti._

Una buona strategia di programmazione per un agente si riduce a tre regole: inviare sempre gli orari in ISO 8601 con un offset esplicito calcolato sul fuso orario del cliente, lasciare che sia la piattaforma a scaglionare gli invii account per account invece di sparare tutto insieme, e dividere le liste di account più lunghe in post e orari separati anziché in un'unica campagna gigantesca. Prima la bozza, poi la programmazione come passaggio a parte, e annullare deve costare poco.

Tutto quello che segue serve a rendere concrete queste regole, con i campi esatti che Shager si aspetta.

## Perché gli agenti sbagliano gli orari?

I modelli linguistici non vanno d'accordo con l'orologio. Non sanno che ore sono finché non glielo dici, scrivono tranquillamente `2026-11-02T09:00:00` senza offset e convertono i fusi orari a mente. Ognuna di queste abitudini può far uscire un post alle 7:00 invece che alle 9:00.

Shager chiude una porta rifiutando l'ambiguità: `schedule_at` deve essere in ISO 8601 con un offset, per esempio `2026-10-20T09:00:00+03:00`. Un timestamp senza `Z` o senza offset non supera la validazione. Quel formato è il profilo definito in [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339), e conviene citarlo per nome nelle istruzioni dell'agente.

L'altra porta è l'offset stesso. `+03:00` è corretto per Israele a ottobre e sbagliato a dicembre. Gli offset cambiano con l'ora legale, e le date del cambio sono diverse tra Israele, Unione europea e Stati Uniti. L'agente non deve mai scrivere un offset fisso nel codice. Deve risolvere il nome del fuso del cliente tramite il [database dei fusi orari IANA](https://www.iana.org/time-zones), incluso in tutti i linguaggi più diffusi, e calcolare l'offset per quella data specifica.

```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
```

Ogni cliente in Shager ha anche un `timezone`, un nome di fuso IANA impostato quando lo si crea (il default è `Asia/Jerusalem`). Fai in modo che l'agente lo legga e lo usi. Quando usi [un solo agente per molti clienti](/en/blog/one-agent-many-clients), non tutti i clienti saranno nello stesso fuso, e il cliente in Shager è l'unico posto in cui è registrato dove vive ciascuno.

## Prima la bozza, poi la programmazione

`create_post` può programmare subito se gli passi `schedule_at`. Nel lavoro per i clienti lo lascio fare agli agenti di rado. Lo schema più sicuro prevede due chiamate:

1. `create_post` senza `schedule_at`, che salva una bozza.
2. `schedule_post` con l'ID del post e l'orario, quando una persona o una regola ha dato il via libera.

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

C'è anche un motivo legato ai permessi. In Shager, per programmare serve lo scope `publish` sulla chiave API, mentre per creare bozze basta `write`. Una persona concede `publish` in modo esplicito quando rivendica l'ambiente di prova di un agente, e può anche creare chiavi che non ce l'hanno. Questa separazione ti permette di lasciare ampia libertà a un agente che scrive bozze e di tenere l'ultimo passaggio nelle mani di una persona. I dettagli sono in [chiavi API, scope e audit](/en/blog/api-keys-scopes-and-audit).

`schedule_post` è utile anche quando qualcosa non va: se un account rifiuterebbe il post, o se serve l'approvazione del cliente e manca, fallisce con un motivo chiaro invece di programmare una campagna che andrà a buon fine solo a metà.

## Quanto dura davvero una campagna scaglionata?

Shager pubblica un account alla volta, con una pausa casuale tra gli account dello stesso social. Il campo `stagger_seconds` stabilisce l'intervallo, di default `[30, 90]`. I social procedono in parallelo, quindi la durata di una campagna dipende dal social con più account.

Il calcolo è abbastanza semplice da poterlo far fare all'agente prima che scelga un orario:

| Account sul social più numeroso | Scaglionamento | Pausa media | Durata approssimativa |
|---|---|---|---|
| 10 | [30, 90] | 60 s | circa 9 minuti |
| 40 | [30, 90] | 60 s | circa 39 minuti |
| 40 | [60, 180] | 120 s | circa 78 minuti |
| 120 | [30, 90] | 60 s | circa 2 ore |

È l'ultima riga a sorprendere. Se un cliente dice "tutto deve essere online entro le 10:00" e hai 120 pagine Facebook, programmare alle 9:00 non basta. O parti prima o dividi la campagna.

Non reagire a una scadenza riducendo lo scaglionamento a `[0, 5]`. La pausa esiste perché una campagna di massa non sembri una raffica partita da un'unica fonte. Il nostro articolo su [come evitare i blocchi per spam quando pubblichi su larga scala](/en/blog/avoid-spam-blocks-when-posting-at-scale) spiega perché il ritmo conta più di qualsiasi singolo testo.

## Dividi per gruppo, non per ora

Per i clienti grandi, lo schema migliore è un post per ogni gruppo di account, ognuno con il suo orario. Una catena di negozi con 90 pagine di punti vendita può essere divisa per area. L'agente crea tre post, uno per gruppo, programmati in mattine diverse o distribuiti nell'arco di una giornata.

```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]
  }
}
```

I gruppi si creano con `create_group`, che riceve un nome e un elenco di `channel_ids`. Quando punti a un gruppo, vengono inclusi tutti i suoi canali attivi.

## I limiti dei social che l'agente deve rispettare

Sono i social stessi a limitare quanto un account può pubblicare tramite le loro API. Meta documenta un limite per account sui post Instagram pubblicati via API in una finestra mobile di 24 ore e mette a disposizione un [endpoint content_publishing_limit](https://developers.facebook.com/docs/instagram-platform/content-publishing) per controllare l'uso attuale. YouTube assegna la quota API per progetto, con un [default di 10.000 unità al giorno](https://developers.google.com/youtube/v3/getting-started), e i caricamenti sono tra le operazioni più costose.

Shager si occupa dell'invio, ma la pianificazione spetta all'agente. Un account che riceve sei post in un giorno è un problema di strategia prima ancora che di API. Agli agenti do una regola interna semplice: non più di un post nel feed per account al giorno, a meno che una persona non dica diversamente.

## Calendari, festività e giorni tranquilli

Il calendario di Shager include le festività israeliane, cosa importante per i clienti israeliani: un post programmato alla vigilia di una festa importante arriva a un pubblico che non è online. Per i clienti di altri paesi, metti nelle istruzioni dell'agente il calendario di chiusure ed eventi del cliente. I modelli sanno più o meno quando cadono le festività nazionali, come Ferragosto; non sanno che il magazzino di quel cliente chiude per inventario l'ultimo venerdì del trimestre.

## Annullare e spostare

`cancel_post` toglie dalla programmazione un post che non ha ancora iniziato a essere pubblicato. Non lo elimina: il post torna a essere una bozza approvata, quindi l'agente può richiamare `schedule_post` con un nuovo orario. L'annullamento vale per i post ancora in attesa; una volta iniziata la pubblicazione, `cancel_post` non si applica più.

Prima di spostare qualsiasi cosa, l'agente dovrebbe chiamare `list_posts` con `status` impostato su `SCHEDULED` per vedere cosa c'è già in coda per quel cliente. Due campagne programmate che colpiscono gli stessi account nella stessa ora sono l'errore autoinflitto più comune che vedo.

## Domande frequenti

### Che fuso orario usa Shager se l'agente invia l'ora in UTC?

Un timestamp con `Z` non è ambiguo, quindi Shager lo programma esattamente in quell'istante. Il fuso orario del cliente conta per come le persone vedono la programmazione nel calendario e per il ragionamento dell'agente. Inviare l'ora locale con l'offset corretto rende i log dell'agente leggibili per chi li controlla.

### L'agente può programmare account diversi a orari diversi nello stesso post?

Un post ha un solo `schedule_at`, e poi gli account escono in sequenza scaglionata. Per orari davvero diversi, crea post separati, di solito uno per gruppo. Così anche i report restano più puliti, perché ogni post può avere il suo `label`.

### Qual è uno scaglionamento di default sensato?

Il default `[30, 90]` va bene per la maggior parte delle campagne. Per i video e per le campagne oltre i 50 account circa su un solo social, lo allargo a qualcosa come `[60, 150]` e parto prima. Il prezzo è il tempo, non la copertura.

## Da dove continuare

Inserisci queste regole nelle istruzioni permanenti dell'agente invece di ripeterle a ogni attività. L'articolo sui [prompt per un agente di contenuti](/en/blog/prompts-for-a-content-agent) contiene un blocco sulla programmazione che puoi incollare così com'è.

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