# Planungsstrategie für Agenten: Zeitzonen, Staffelung und nicht 40 Seiten um 9:00 fluten

_2026-09-18 · Wie ein KI-Agent Beiträge auf vielen Konten plant: ISO-8601-Offsets, Zeitzonen und Sommerzeit, Staffelung, Gruppen auf Tage verteilen, sicher stornieren._

Eine gute Planungsstrategie für einen Agenten läuft auf drei Regeln hinaus: Zeiten immer als ISO 8601 mit ausdrücklichem Offset senden, berechnet aus der Zeitzone des Kunden. Die Plattform den Versand pro Konto staffeln lassen, statt alles auf einmal abzufeuern. Und große Kontolisten auf mehrere Beiträge und Zeitpunkte aufteilen, statt einen einzigen Riesendurchlauf zu starten. Erst entwerfen, dann in einem eigenen Schritt planen – und dafür sorgen, dass Stornieren nichts kostet.

Alles Weitere macht diese Regeln konkret, mit genau den Feldern, die Shager erwartet.

## Warum liegen Agenten bei der Zeit daneben?

Sprachmodelle können schlecht mit Uhren umgehen. Sie wissen nicht, wie spät es ist, wenn man es ihnen nicht sagt, sie schreiben fröhlich `2026-11-02T09:00:00` ohne Offset, und sie rechnen Zeitzonen im Kopf um. Jede dieser Gewohnheiten kann dazu führen, dass Beiträge um 7:00 statt um 9:00 rausgehen.

Eine dieser Türen schließt Shager, indem es keine Mehrdeutigkeit akzeptiert: `schedule_at` muss ISO 8601 mit Offset sein, zum Beispiel `2026-10-20T09:00:00+03:00`. Ein Zeitstempel ohne `Z` oder Offset fällt bei der Validierung durch. Dieses Format ist das in [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339) definierte Profil, und es lohnt sich, es dem Agenten in seinen Anweisungen ausdrücklich beim Namen zu nennen.

Die andere Tür ist der Offset selbst. `+03:00` stimmt für Israel im Oktober und ist im Dezember falsch. Offsets ändern sich mit der Sommerzeit, und die Umstellungstermine unterscheiden sich zwischen Israel, der EU und den USA. Der Agent sollte nie einen Offset fest eintragen. Er sollte den Zonennamen des Kunden über die [IANA-Zeitzonendatenbank](https://www.iana.org/time-zones) auflösen, die jede gängige Programmiersprache mitbringt, und den Offset für das konkrete Datum berechnen.

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

Jeder Shager-Workspace hat außerdem eine `timezone`, einen IANA-Zonennamen, der beim Anlegen des Workspace festgelegt wird (Standard ist `Asia/Jerusalem`). Lass den Agenten ihn auslesen und verwenden. Wenn du [einen Agenten für viele Kunden](/en/blog/one-agent-many-clients) einsetzt, sitzen nicht alle Kunden in derselben Zone – und der Workspace ist der eine Ort, an dem festgehalten ist, in welcher Zone jeder Kunde lebt.

## Erst entwerfen, dann planen

`create_post` kann sofort planen, wenn du `schedule_at` mitgibst. Bei Kundenarbeit lasse ich Agenten das selten tun. Sicherer ist ein Muster mit zwei Aufrufen:

1. `create_post` ohne `schedule_at` – das speichert einen Entwurf.
2. `schedule_post` mit Beitrags-ID und Zeitpunkt, sobald ein Mensch oder eine Regel ihn freigegeben hat.

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

Es gibt auch einen Grund bei den Berechtigungen. In Shager braucht das Planen den Scope `publish` am API-Schlüssel, das Entwerfen nur `write`. `publish` vergibt ein Mensch ausdrücklich, wenn er die Sandbox eines Agenten übernimmt, und er kann auch Schlüssel ohne dieses Recht erstellen. Durch diese Trennung kannst du einem Entwurfs-Agenten viel Freiheit lassen und den letzten Schritt trotzdem bei einem Menschen halten. Die Details stehen in [API-Schlüssel, Scopes und Audit](/en/blog/api-keys-scopes-and-audit).

`schedule_post` verhält sich auch bei Fehlern sinnvoll: Würde ein Konto den Beitrag ablehnen oder fehlt eine erforderliche Kundenfreigabe, schlägt der Aufruf mit einer klaren Begründung fehl, statt einen Durchlauf zu planen, der dann zur Hälfte scheitert.

## Wie lange dauert ein gestaffelter Durchlauf wirklich?

Shager veröffentlicht Konto für Konto, mit einer zufälligen Pause zwischen Konten desselben Netzwerks. Das Feld `stagger_seconds` legt diese Spanne fest, Standard ist `[30, 90]`. Die Netzwerke laufen parallel, die Dauer eines Durchlaufs bestimmt also das Netzwerk mit den meisten Konten.

Die Rechnung ist so einfach, dass der Agent sie anstellen kann, bevor er einen Zeitpunkt wählt:

| Konten im größten Netzwerk | Staffelung | Durchschnittlicher Abstand | Ungefähre Dauer |
|---|---|---|---|
| 10 | [30, 90] | 60 s | etwa 9 Minuten |
| 40 | [30, 90] | 60 s | etwa 39 Minuten |
| 40 | [60, 180] | 120 s | etwa 78 Minuten |
| 120 | [30, 90] | 60 s | etwa 2 Stunden |

Die letzte Zeile überrascht viele. Sagt ein Kunde „bis 10:00 muss alles online sein“ und du hast 120 Facebook-Seiten, reicht ein Start um 9:00 nicht. Entweder du fängst früher an, oder du teilst den Durchlauf auf.

Reagiere auf eine Deadline nicht, indem du die Staffelung auf `[0, 5]` zusammenstauchst. Die Pause gibt es, damit ein Massendurchlauf nicht wie ein Schwall aus einer einzigen Quelle aussieht. Unser Artikel [Spam-Sperren beim Posten in großem Maßstab vermeiden](/en/blog/avoid-spam-blocks-when-posting-at-scale) erklärt, warum das Tempo wichtiger ist als jeder einzelne Text.

## Nach Gruppen aufteilen, nicht nach Stunden

Bei großen Kunden ist ein anderes Muster stärker: ein Beitrag pro Kontogruppe, jeder mit eigenem Zeitpunkt. Eine Handelskette mit 90 Filialseiten ließe sich etwa nach Regionen gruppieren. Der Agent legt drei Beiträge an, einen pro Regionsgruppe, geplant an verschiedenen Vormittagen oder über einen Tag verteilt.

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

Gruppen entstehen mit `create_group`, das einen Namen und eine Liste von `channel_ids` erwartet. Zielst du auf eine Gruppe, wird jeder aktive Kanal darin hinzugefügt.

## Netzwerk-Limits, die der Agent respektieren sollte

Die Netzwerke selbst begrenzen, wie viel ein Konto über ihre APIs veröffentlichen kann. Meta dokumentiert ein Limit pro Konto für per API veröffentlichte Instagram-Beiträge innerhalb eines gleitenden 24-Stunden-Fensters und bietet einen [content_publishing_limit-Endpunkt](https://developers.facebook.com/docs/instagram-platform/content-publishing), um die aktuelle Nutzung abzufragen. YouTube teilt API-Kontingent pro Projekt zu, [standardmäßig 10.000 Einheiten pro Tag](https://developers.google.com/youtube/v3/getting-started), und Uploads gehören zu den teuersten Operationen.

Den Versand übernimmt Shager, die Planung ist Sache des Agenten. Ein Konto, das sechs Beiträge an einem Tag bekommt, hat ein Strategieproblem, lange bevor es ein API-Problem hat. Ich gebe Agenten eine einfache Hausregel: höchstens ein Feed-Beitrag pro Konto und Tag, außer ein Mensch sagt etwas anderes.

## Kalender, Feiertage und ruhige Tage

Shagers Kalender enthält die israelischen Feiertage. Das ist für israelische Kunden wichtig: Ein Beitrag, der für den Vorabend eines großen Feiertags geplant ist, trifft auf ein Publikum, das offline ist. Für Kunden anderswo gibst du dem Agenten in seinen Anweisungen den eigenen Kalender des Kunden mit Schließtagen und Terminen mit. Modelle wissen ungefähr, wann gesetzliche Feiertage liegen – etwa der Tag der Deutschen Einheit. Sie wissen aber nicht, dass das Lager dieses Kunden am letzten Freitag im Quartal wegen Inventur geschlossen ist.

## Stornieren und verschieben

`cancel_post` nimmt einen Beitrag, dessen Veröffentlichung noch nicht begonnen hat, aus der Planung. Gelöscht wird er dabei nicht: Er wird wieder zu einem freigegebenen Entwurf, und der Agent kann erneut `schedule_post` mit einem neuen Zeitpunkt aufrufen. Stornieren ist für Beiträge gedacht, die noch warten; hat die Veröffentlichung begonnen, greift `cancel_post` nicht mehr.

Bevor der Agent etwas verschiebt, sollte er `list_posts` mit `status` auf `SCHEDULED` aufrufen, um zu sehen, was für diesen Workspace bereits in der Warteschlange steht. Zwei geplante Durchläufe, die in derselben Stunde auf denselben Konten landen – das ist der häufigste hausgemachte Fehler, den ich sehe.

## FAQ

### Welche Zeitzone nutzt Shager, wenn der Agent UTC sendet?

Ein Zeitstempel mit `Z` ist eindeutig, Shager plant ihn also für genau diesen Zeitpunkt. Die Zeitzone des Workspace bestimmt, wie Menschen die Planung im Kalender sehen, und hilft dem Agenten bei seinen eigenen Überlegungen. Wer Ortszeit mit dem korrekten Offset sendet, hält die Logs des Agenten für die Menschen lesbar, die sie prüfen.

### Kann der Agent in einem Beitrag verschiedene Konten zu verschiedenen Zeiten planen?

Ein Beitrag hat genau ein `schedule_at`, danach gehen die Konten in der gestaffelten Reihenfolge raus. Für wirklich unterschiedliche Zeiten legst du getrennte Beiträge an, meist einen pro Gruppe. Das macht auch die Auswertung übersichtlicher, denn jeder Beitrag kann sein eigenes `label` tragen.

### Was ist eine sinnvolle Standard-Staffelung?

Der Standard `[30, 90]` passt für die meisten Durchläufe. Bei Videos und bei Durchläufen mit mehr als etwa 50 Konten in einem Netzwerk erweitere ich ihn auf etwas wie `[60, 150]` und fange früher an. Das kostet Zeit, keine Reichweite.

## Wie es weitergeht

Schreib diese Regeln in die festen Anweisungen deines Agenten, statt sie in jeder Aufgabe zu wiederholen. Der Artikel mit den [Prompts für einen Content-Agenten](/en/blog/prompts-for-a-content-agent) enthält einen Planungsblock, den du unverändert einfügen kannst.

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