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

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, 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, que vem embutida em toda linguagem popular, e calcular o offset para a data específica.

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, nem todos estão no mesmo fuso, e o workspace é o único lugar que registra em qual fuso cada cliente vive.

Role para o lado para ver o diagrama inteiro

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.

{
  "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.

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

{
  "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.

Role para o lado para ver o diagrama inteiro

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 para consultar o uso atual. O YouTube distribui a cota de API por projeto, com um padrão de 10.000 unidades por dia, 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 tem um bloco de agendamento que você pode colar do jeito que está.