# Agendamento para agentes: fusos horários, envio escalonado e nada de inundar quarenta páginas às 9h

_2026-09-18 · Como um agente de IA deve agendar posts em muitas contas: offsets ISO 8601, fusos e horário de verão, cálculo do escalonamento, grupos em dias e cancelamentos._

Uma boa estratégia de agendamento para um agente se resume a três regras: sempre enviar os horários em ISO 8601 com um offset explícito, calculado a partir do fuso horário do cliente; deixar a plataforma escalonar o envio por conta, em vez de disparar tudo de uma vez; e dividir listas grandes de contas em posts e horários separados, em vez de uma única execução gigante. Primeiro o rascunho, depois o agendamento como etapa separada, e cancelar tem que ser fácil.

Tudo o que vem abaixo serve para tornar essas regras concretas, com os campos exatos que o Shager espera.

## Por que os agentes erram o horário?

Modelos de linguagem são ruins com relógio. Não sabem que horas são a menos que você diga, escrevem tranquilamente `2026-11-02T09:00:00` sem offset e fazem a conversão entre fusos de cabeça. Cada um desses hábitos é uma fonte de posts saindo às 7h em vez das 9h.

O Shager fecha uma porta ao recusar ambiguidade: `schedule_at` precisa estar em ISO 8601 com offset, por exemplo `2026-10-20T09:00:00+03:00`. Um timestamp sem `Z` ou sem offset falha na validação. Esse formato é o perfil definido na [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339), e vale a pena citá-lo pelo nome nas instruções do seu agente.

A outra porta é o próprio offset. `+03:00` está certo para Israel em outubro e errado em dezembro. Os offsets mudam com o horário de verão, e as datas de mudança são diferentes em Israel, na União Europeia e nos Estados Unidos. O agente nunca deve fixar um offset no código. Ele deve resolver o nome do fuso do cliente pela [base de fusos horários da IANA](https://www.iana.org/time-zones), que vem embutida em toda linguagem popular, e calcular o offset para a data específica.

```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 workspace do Shager também tem um `timezone`, um nome de fuso IANA definido na criação do workspace (o padrão é `Asia/Jerusalem`). Faça o agente ler esse campo e usá-lo. Quando você roda [um agente para muitos clientes](/en/blog/one-agent-many-clients), nem todos estão no mesmo fuso, e o workspace é o único lugar que registra em qual fuso cada cliente vive.

## Primeiro o rascunho, depois o agendamento

`create_post` pode agendar na hora se você passar `schedule_at`. Raramente deixo agentes fazerem isso em trabalho de cliente. O padrão mais seguro são duas chamadas:

1. `create_post` sem `schedule_at`, que salva um rascunho.
2. `schedule_post` com o ID do post e o horário, depois que uma pessoa ou uma regra liberou o post.

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

Há também um motivo de permissão. No Shager, agendar exige o escopo `publish` na chave de API, enquanto criar rascunhos exige só `write`. Uma pessoa concede `publish` explicitamente ao assumir o ambiente de teste de um agente, e pode criar chaves sem esse escopo. Essa divisão permite dar bastante liberdade a um agente que escreve rascunhos e manter a etapa final nas mãos de alguém. Os detalhes estão em [chaves de API, escopos e auditoria](/en/blog/api-keys-scopes-and-audit).

`schedule_post` também faz algo útil quando dá errado: se alguma conta fosse rejeitar o post, ou se a aprovação do cliente for exigida e estiver faltando, ele falha com um motivo claro, em vez de agendar uma execução que vai falhar pela metade.

## Quanto tempo leva, de fato, uma execução escalonada?

O Shager publica conta por conta, com uma pausa aleatória entre contas da mesma rede. O campo `stagger_seconds` define esse intervalo, com padrão `[30, 90]`. As redes rodam em paralelo, então a duração de uma execução é determinada pela rede com mais contas.

A conta é simples o bastante para o agente fazer antes de escolher um horário:

| Contas na maior rede | Escalonamento | Intervalo médio | Duração aproximada |
|---|---|---|---|
| 10 | [30, 90] | 60 s | cerca de 9 minutos |
| 40 | [30, 90] | 60 s | cerca de 39 minutos |
| 40 | [60, 180] | 120 s | cerca de 78 minutos |
| 120 | [30, 90] | 60 s | cerca de 2 horas |

A última linha é a que surpreende. Se o cliente diz "tudo precisa estar no ar até as 10h" e você tem 120 páginas no Facebook, agendar para as 9h não resolve. Ou você começa mais cedo, ou divide a execução.

Não responda a um prazo reduzindo o escalonamento para `[0, 5]`. A pausa existe para que uma execução em massa não pareça uma rajada vinda de uma única fonte. Nosso artigo sobre [como evitar bloqueios por spam ao publicar em escala](/en/blog/avoid-spam-blocks-when-posting-at-scale) explica por que o ritmo importa mais do que qualquer legenda isolada.

## Divida por grupo, não por hora

Para clientes grandes, o padrão mais sólido é um post por grupo de contas, cada um com seu horário. Uma rede de lojas com 90 páginas de filiais pode ser agrupada por região. O agente cria três posts, um por grupo regional, agendados em manhãs diferentes ou espalhados ao longo de um dia.

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

Os grupos são criados com `create_group`, que recebe um nome e uma lista de `channel_ids`. Todos os canais ativos de um grupo entram quando você mira o grupo.

## Limites das redes que o agente deve respeitar

As próprias redes limitam quanto uma conta pode publicar pelas suas APIs. A Meta documenta um limite por conta para posts do Instagram publicados via API numa janela móvel de 24 horas e oferece um [endpoint content_publishing_limit](https://developers.facebook.com/docs/instagram-platform/content-publishing) para consultar o uso atual. O YouTube distribui a cota de API por projeto, com um [padrão de 10.000 unidades por dia](https://developers.google.com/youtube/v3/getting-started), e os uploads estão entre as operações mais caras.

O Shager cuida do envio, mas o planejamento é responsabilidade do agente. Uma conta que recebe seis posts num dia é um problema de estratégia antes de ser um problema de API. Dou aos agentes uma regra simples da casa: no máximo um post no feed por conta por dia, a menos que uma pessoa diga o contrário.

## Calendários, feriados e dias parados

O calendário do Shager inclui os feriados de Israel, o que importa para clientes israelenses: um post agendado para a véspera de um feriado importante chega a um público que está offline. Para clientes de outros lugares, coloque nas instruções do agente o calendário de fechamentos e eventos do próprio cliente. Os modelos sabem mais ou menos quando caem os feriados nacionais; não sabem que o depósito deste cliente fecha para inventário na última sexta-feira do trimestre.

## Cancelar e remarcar

`cancel_post` tira do agendamento um post que ainda não começou a ser publicado. Ele não apaga o post: o post volta a ser um rascunho aprovado, e o agente pode chamar `schedule_post` de novo com outro horário. O cancelamento vale para posts que ainda estão esperando; depois que a publicação começou, `cancel_post` não se aplica mais.

Antes de remarcar qualquer coisa, o agente deve chamar `list_posts` com `status` igual a `SCHEDULED` para ver o que já está na fila daquele workspace. Duas execuções agendadas caindo nas mesmas contas na mesma hora é o erro autoinfligido mais comum que eu vejo.

## Perguntas frequentes

### Qual fuso horário o Shager usa se o agente enviar em UTC?

Um timestamp com `Z` não tem ambiguidade, então o Shager agenda exatamente naquele instante. O fuso do workspace importa para a forma como as pessoas veem a programação no calendário e para o raciocínio do próprio agente. Enviar o horário local com o offset correto mantém os logs do agente legíveis para quem vai conferi-los.

### O agente pode agendar contas diferentes em horários diferentes num mesmo post?

Um post tem um único `schedule_at`, e as contas saem em sequência escalonada a partir dele. Para horários realmente diferentes, crie posts separados, geralmente um por grupo. Isso também deixa os relatórios mais limpos, já que cada post pode ter o próprio `label`.

### Qual é um escalonamento padrão sensato?

O padrão `[30, 90]` é razoável para a maioria das execuções. Para vídeo e para execuções com mais de cerca de 50 contas numa mesma rede, eu aumento para algo como `[60, 150]` e começo mais cedo. O custo é tempo, não alcance.

## Próximos passos

Coloque essas regras nas instruções fixas do seu agente, em vez de repeti-las a cada tarefa. O artigo de [prompts para um agente de conteúdo](/en/blog/prompts-for-a-content-agent) tem um bloco de agendamento que você pode colar do jeito que está.

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