OpenAI: Geplante Agent-Automatisierungen sind keine Cronjobs
Geplante Agent-Aufgaben starten zwar zur gewuenschten Zeit, doch entscheidend ist, was passiert, wenn die Session belegt ist, eine Freigabe fehlt oder ein Tool-Aufruf fehlschlaegt. Diese Lieferungsluecke macht den Unterschied zu klassischen Cronjobs aus.
Eine geplante Agentenaufgabe klingt einfach: eine Zeit wählen, eine Anweisung speichern und erwarten, dass die Arbeit erledigt wird. Doch sobald ein Agent nach einem Zeitplan handeln kann, ist die entscheidende Frage nicht mehr nur, wann er startet. Entscheidend ist, was passiert, wenn die Sitzung beschäftigt ist, eine Freigabe erforderlich ist, ein Toolaufruf fehlschlägt oder der Auftrag zwar zugestellt wird, die Arbeit aber nie zu einem brauchbaren Ergebnis führt.
OpenAIs neue Scheduled Automations für die Agents API macht genau diesen Unterschied sichtbar. Eine Automation speichert einen Zeitplan und sendet eine Aufgabe an eine Agentensitzung. Jeder Versuch erzeugt einen Invocation-Eintrag. Das ist nicht derselbe Vertrag wie ein traditioneller Cron-Prozess, der auf einem Host einen Befehl startet und dessen Supervisor den Exit-Status meldet. Die offizielle Dokumentation besagt, dass die Zustellung warten kann, während die Zielsitzung beschäftigt ist, dass ein geplanter Lauf keine aktive Runde unterbricht und dass die Anwendung weiterhin die erforderlichen Aktionen behandeln muss.
Genau darin liegt die Geschichte, die Aufmerksamkeit verdient. Agentenplattformen fügen Zeitplanung hinzu, doch ein Zeitplan ist nur ein Glied in einer längeren Kette: Auslöser, Zustellung, Sitzung, Tools, Freigabe, Seiteneffekt und Verifikation. Wenn ein System „Invocation in Warteschlange“ als „Aufgabe abgeschlossen“ behandelt, kann es Erfolg melden, obwohl keine nützliche Arbeit stattgefunden hat.
Das Feature erlaubt Entwicklern, eine einmalige oder wiederkehrende Automation für eine Agentensitzung zu speichern. Ein einmaliger Lauf verwendet einen zukünftigen Unix-Zeitstempel. Ein wiederkehrender Lauf verwendet einen Cron-Ausdruck mit fünf Feldern sowie eine Zeitzone. Die Automation kann eine neue Sitzung starten oder eine bestehende fortsetzen. Eine Anwendung kann zudem ein Automations-Tool aktivieren, damit ein Agent in seiner aktuellen Sitzung Automationen erstellen, auflisten, aktualisieren, pausieren, fortsetzen oder löschen kann.
Wenn ein Lauf fällig ist, erzeugt die Agents API eine Invocation, beschrieben als Eintrag über den Versuch, eine Aufgabe an die Zielsitzung zu senden. Die Invocation enthält Felder wie Status, Sitzungs-ID, Quelltyp und geplante Zeit. Zu Testzwecken kann eine manuelle Invocation ausgelöst werden, und ihr Verlauf kann getrennt von geplanten Läufen eingesehen werden.
Das sind nützliche Bausteine. Sie ermöglichen es einer Anwendung, Zeitabläufe und Planungszustand an die API zu delegieren, anstatt jeden Timer selbst zu verwalten. Doch die Formulierung in der Dokumentation ist wichtig: Der Dienst plant Aufgaben und stellt sie an eine Sitzung zu. Er verspricht nicht, dass jede geplante Aufgabe erfolgreich abgeschlossen wird, dass jede angeforderte Tool-Aktion freigegeben wird oder dass ein nachgelagertes System das Ergebnis akzeptiert hat.
Ein herkömmlicher Cron-Eintrag wird oft als direkter Befehlsstart behandelt: zu einer Zeit, starte einen Prozess. Selbst dort erfordert zuverlässiger Betrieb mehr als Cron. Der Prozess kann abstürzen, der Host kann ausgefallen sein, und ein zweiter Lauf kann sich mit dem ersten überschneiden. Doch die Ausführungsgrenze ist vergleichsweise klar: Ein Prozess wurde gestartet, und sein Exit-Status kann erfasst werden.
Eine Agentenautomation hat eine andere Grenze. Der Zeitplan bewirkt, dass eine Invocation an eine Sitzung zugestellt wird. Die Sitzung muss dann verfügbar werden, Anweisungen interpretieren, entscheiden, ob Tools genutzt werden, gegebenenfalls eine Freigabe anfordern und mit externen Systemen interagieren. Die offizielle Dokumentation weist ausdrücklich darauf hin, dass die Zustellung wartet, wenn eine Sitzung arbeitet, bis diese verfügbar wird. Der geplante Lauf unterbricht die aktive Runde nicht und liefert weder ein fehlendes Tool-Ergebnis noch eine Freigabe. Die Anwendung muss diese Anforderungen behandeln.
Das bedeutet, dass mehrere Zustände, die nach Erfolg klingen, nur Zwischenzustände sind:
Die praktische Lehre ist nicht, dass das Feature unzuverlässig ist. Es lautet, dass die Planungseinheit der API eine Aufgabenzustellung an einen Agenten ist, kein Geschäftsergebnis. Anwendungen müssen ihre eigene Abschlussbedingung definieren.
Nehmen wir an, ein Agent prüft stündlich eine Warteschlange und aktualisiert ein Ticket, wenn er ein eindeutiges Duplikat findet. Ist dieselbe Sitzung beim Auslösen des nächsten Zeitplans noch mit dem vorherigen Lauf beschäftigt, wartet die neue Zustellung. Das kann für eine Konversation korrekt sein, die Kontext bewahren muss. Es kann falsch sein für unabhängige periodische Prüfungen, bei denen jeder Lauf mit einem sauberen Zustand beginnen sollte.
Die Dokumentation lässt den Entwickler wählen, ob jeder Lauf eine neue Sitzung startet oder eine bestehende Konversation fortsetzt. Diese Wahl betrifft mehr als das Gedächtnis. Eine fortgesetzte Sitzung kann früheren Zustand und Kontext weitertragen, aber sie kann auch veraltete Annahmen ansammeln oder die Diagnose erschweren. Eine frische Sitzung begrenzt die konversationelle Übernahme, erfordert jedoch, dass Aufgabendaten und Anwendungszustand alles liefern, was der Lauf benötigt.
Keine der beiden Optionen ist automatisch besser. Ein Berichtsgenerator, der einmal täglich läuft, kann von einer neuen Sitzung und einem begrenzten Schnappschuss der Tagesdaten profitieren. Ein mehrstufiger Recherche-Workflow benötigt möglicherweise eine fortgesetzte Sitzung, weil spätere Arbeiten von früheren Ergebnissen abhängen. In beiden Fällen sollte die Anwendung die maßgebliche Eingabe für jeden Lauf identifizieren, statt sich ausschließlich auf das konversationelle Gedächtnis eines Agenten als einziges Protokoll zu verlassen.
Wenn ein geplanter Agent ein anderes System beeinflusst, sollte der Workflow als Zustandsmaschine modelliert werden. Beispielsweise könnte eine Aufgabe die Zustände scheduled, invocation_created, delivered, awaiting_approval, action_submitted, verified oder failed durchlaufen. Die genauen Bezeichnungen obliegen der Anwendung. Wichtig ist, diese Zustände nicht in einen einzigen Booleschen Wert namens success zusammenzufallen.
Der Invocation-Verlauf der Agents API kann helfen zu beantworten, ob eine Zustellung versucht wurde und welche Sitzung sie empfangen hat. Die Anwendung sollte die Geschäftslauf-ID, die beabsichtigte Operation, den Zeitplan-Termin und die betroffene externe Ressource protokollieren. Wenn der Agent einen Seiteneffekt auslöst, sollte dieser Effekt durch Rücklesen des Zielsystems verifiziert werden. Die Meldung eines Modells, etwas sei „aktualisiert“, ist keine Quittung der Datenbank oder des Issue-Trackers.
Daraus ergibt sich auch eine nützliche Designregel: Aktionen nach Möglichkeit idempotent gestalten. Wenn eine geplante Aufgabe wiederholt, fortgesetzt, manuell ausgelöst oder mit Verzögerung zugestellt wird, darf dieselbe logische Aufgabe keine doppelten Rechnungen erzeugen, wiederholte Benachrichtigungen senden oder mehrere identische Tickets öffnen. Eine stabile Operationsschlüssel in der Aktionsebene einbinden und das Ziel doppelte Operationen ablehnen lassen. Das Modell kann mitentscheiden, welche Aktion angefordert werden soll; deterministischer Anwendungscode sollte durchsetzen, ob diese Aktion bereits ausgeführt wurde.
Geplante Arbeit kann ein falsches Gefühl von Autonomie erzeugen. Eine Aufgabe mag um 2 Uhr nachts fällig sein, doch eine bestimmte Operation kann weiterhin eine menschliche Entscheidung erfordern. Die Dokumentation besagt, dass ein Zeitplan keine fehlende Freigabe ersetzt. Das ist eine wichtige Grenze, kein nebensächliches Implementierungsdetail.
Vor der Planung eines Agenten sollten seine möglichen Aktionen klassifiziert werden:
Die erste Kategorie kann oft unbeaufsichtigt laufen, wenn die Zugriffe richtig beschränkt sind. Die zweite sollte über eine klare Prüfspur und einen Rückgängig-Weg verfügen. Die dritte sollte in der Regel einen expliziten Autorisierungsmechanismus erfordern, der vom Urteil des Modells getrennt ist. Eine Benachrichtigung, dass der Agent eine Freigabe wünscht, ist selbst kein Freigabe-Workflow. Die Anwendung muss speichern, wer was wann und gegen welche Version der vorgeschlagenen Aktion genehmigt hat.
Die API liefert Invocation-Einträge und erlaubt Entwicklern, Status und Sitzungs-ID einzusehen. Das ist ein Ausgangspunkt für den Betrieb, kein vollständiger Überwachungsplan. Für jeden geplanten Job sollte ein Team die folgenden Fragen beantworten können:
Eine zufällige Verzögerung für wiederkehrende Läufe ist ein weiteres Detail, das in die Erwartungen einbezogen werden sollte. Die Dokumentation besagt, dass der Dienst eine kleine zufällige Verzögerung zur Lastverteilung einfügt und dass eine Aufgabe länger warten kann, wenn ihre Zielsitzung beschäftigt ist. Ein Cron-Ausdruck sollte daher als Zeitplan für den Beginn einer Arbeit gelesen werden, nicht als Zusage, dass eine Aktion zur exakten Sekunde erfolgt. Hat ein Geschäftsprozess eine harte Frist, sind Fristenüberwachung und Eskalation außerhalb des Agenten-Prompts zu implementieren.
Dieselbe Logik gilt für Pause, Fortsetzen und Löschen. Das Pausieren oder Löschen einer Automation stoppt keine Arbeit, die bereits von einer Sitzung angenommen wurde, und eine bereits laufende Zustellung kann ihre Sitzung dennoch erreichen. Ein Betreiber, der eine aktive Aktion stoppen muss, muss den separaten Abbruchpfad verstehen. „Zeitplan pausiert“ und „Arbeit gestoppt“ sind keine austauschbaren Betriebszustände.
Scheduled Automations kann eine gute Wahl sein, wenn eine Anwendung bereits die Agents API nutzt und wiederkehrende oder einmalige Agentenarbeiten in verwaltete Sitzungen zustellen möchte. Es bietet einen gemeinsamen Ort, um einen Zeitplan zu definieren, Invocations zu prüfen und einen Agenten Zeitpläne verwalten zu lassen, sofern dieses Tool aktiviert ist.
Es ist kein Direct Replacement für jedes Job-System. Ist eine Aufgabe deterministisch und benötigt kein reasoning, kann ein normaler Scheduler mit einem Programm einfacher sein. Muss ein Workflow strenge Service-Level-Ziele erfüllen, dauerhafte Wiederholungen sicherstellen oder Transaktionen über Dienste hinweg koordinieren, benötigen diese Anforderungen weiterhin explizite Infrastruktur. Die Fähigkeit eines Agenten, eine Anweisung zu interpretieren, beseitigt nicht die Notwendigkeit von Queue-Semantik, Deduplizierung, Timeouts, Zugriffskontrollen und Ergebnisverifikation.
Das beste mentale Modell ist ein Scheduler, der an ein asynchrones System zur Auslieferung von Agent-Sitzungen gekoppelt ist. Betrachte den Zeitplan als Ausloeser, den Aufruf als Beleg fuer einen Versuch und den verifizierten externen Zustand als Beleg fuer den Abschluss. Diese Unterscheidung haelt die Funktion nuetzlich, ohne ihr Garantien zuzuschreiben, die die API nicht erhebt.
Die Funktion ist ein bedeutsamer Schritt hin zu Agenten, die arbeiten koennen, ohne dass eine Person jeden Prompt senden muss. Ein gespeicherter Zeitplan ist jedoch kein autonomer Arbeiter, und eine ausgelieferte Anweisung ist keine abgeschlossene Aufgabe. Die Designfrage fuer Entwickler lautet, wo die Grenze zwischen dem flexiblen reasoning des Agenten und den deterministischen Garantien der Anwendung verlaufen soll.
Ich schreibe ueber Entwicklerwerkzeuge, KI-Systeme und Backend-Engineering. Abonniere fuer weitere praktische Analysen davon, wie sich diese Systeme im Produktivbetrieb verhalten.
Hast du schon einmal einen Agenten auf einen Zeitplan gesetzt? Was verwendest du als Nachweis, dass die Aufgabe tatsaechlich abgeschlossen wurde?
Speichere die Checkliste, bevor du einen geplanten Agenten fuer echte Nebenwirkungen verantwortlich machst.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
A scheduled agent task sounds simple: pick a time, save an instruction, and expect the work to happen. But the moment an agent can act on a schedule, the important question is no longer just when it starts. It is what happens if the session is busy, an approval is needed, a tool call fails, or the invocation is delivered but the work never reaches a useful result.
OpenAI's new Scheduled Automations for the Agents API makes that distinction visible. An automation stores a schedule and sends a task to an agent session. Each attempt creates an invocation record. That is not the same contract as a traditional cron process that starts a command on a host and lets the command's supervisor report its exit status. The official documentation says delivery can wait while the target session is busy, a scheduled run does not interrupt an active turn, and the application still has to handle required actions.
That is the story worth paying attention to. Agent platforms are adding scheduling, but a schedule is only one link in a longer chain: trigger, delivery, session, tools, approval, side effect, and verification. If your system treats “invocation queued” as “task completed,” it can report success while useful work has not happened.
The feature lets developers save a one-time or recurring automation for an agent session. A one-time run uses a future Unix timestamp. A recurring run uses a five-field cron expression and a time zone. The automation can start a new session or continue an existing one. An application can also enable an automations tool so an agent can create, list, update, pause, resume, or delete automations in its current session.
When a run is due, the Agents API creates an invocation, described as a record of an attempt to send a task to the target session. The invocation has fields such as status, session ID, source type, and scheduled time. A manual invocation can be triggered for testing, and its history can be inspected separately from scheduled runs.
Those are useful building blocks. They let an application delegate timing and scheduling state to the API rather than maintain every timer itself. But the language in the documentation matters: the service schedules and delivers work to a session. It does not promise that every scheduled task will finish successfully, that every requested tool action will be approved, or that a downstream system has accepted the result.
A conventional cron entry is often treated as a direct command launch: at a time, start a process. Even there, reliable operations require more than cron. The process can crash, the host can be down, and a second run can overlap the first. But the execution boundary is comparatively clear: a process began, and its exit status can be collected.
An agent automation has a different boundary. The schedule causes an invocation to be delivered to a session. The session then needs to become available, interpret instructions, decide whether to use tools, possibly request approval, and interact with external systems. The official docs explicitly note that if a session is working, delivery waits for it to become available. The scheduled run does not interrupt the active turn or provide a missing tool result or approval. The application must handle those requirements.
That means several states that sound like success are only intermediate states:
The practical lesson is not that the feature is unreliable. It is that the API's unit of scheduling is a task delivery to an agent, not a business outcome. Applications need to define their own completion condition.
Suppose an agent reviews a queue every hour and updates a ticket when it finds a clear duplicate. If the same session is still handling the previous run when the next schedule fires, the new delivery waits. That may be correct for a conversation that must preserve context. It may be wrong for independent periodic checks where each run should start with a clean state.
The docs let the developer choose whether each run starts a new session or continues an existing conversation. That choice affects more than memory. A continuing session can carry prior state and context forward, but it can also accumulate stale assumptions or make diagnosis harder. A fresh session limits conversational carry-over, but it requires the task payload and application state to provide everything the run needs.
Neither option is automatically best. A report generator that runs once per day may benefit from a new session and a bounded snapshot of the day's data. A multi-step research workflow may need a continuing session because later work depends on earlier findings. In both cases, the application should identify the authoritative input for each run rather than relying on an agent's conversational memory as the only record.
When a scheduled agent affects another system, model the workflow as a state machine. For example, a task could move through scheduled, invocation_created, delivered, awaiting_approval, action_submitted, verified, or failed. The exact names are up to the application. The important part is not collapsing those states into a single boolean called success.
The Agents API invocation history can help answer whether delivery was attempted and which session received it. The application should record the business task ID, intended operation, schedule occurrence, and the external resource affected. When the agent submits a side effect, verify that effect by reading the target system back. A model's message saying “updated” is not a receipt from the database or issue tracker.
This also suggests a useful design rule: make actions idempotent where possible. If a scheduled task is retried, resumed, manually invoked, or delivered after a delay, the same logical task should not create duplicate invoices, send repeated notifications, or open multiple identical tickets. Include a stable operation key in the action layer and let the destination reject duplicate operations. The model can help decide what action to request; deterministic application code should enforce whether that action has already been applied.
Scheduled work can create a false sense of autonomy. A task may be due at 2 a.m., but a particular operation may still need a human decision. The documentation says a schedule does not supply a missing approval. That is an important boundary, not a minor implementation detail.
Before scheduling an agent, classify its possible actions:
The first category can often run unattended if access is properly scoped. The second should have a clear audit trail and undo path. The third should usually require an explicit authorization mechanism that is separate from the model's own judgment. A notification saying that the agent wants approval is not itself an approval workflow. The application needs to store who approved what, when, and against which version of the proposed action.
The API gives invocation records and allows developers to inspect status and session ID. That is a starting point for operations, not a complete monitoring plan. For each scheduled job, a team should be able to answer:
A randomized delay for recurring runs is another detail worth including in expectations. The docs say the service adds a small randomized delay to spread load, and a task can wait longer if its target session is busy. Therefore, a cron expression should be read as a schedule for initiating work, not as a promise that an action will happen at the exact second. If a business process has a hard deadline, implement deadline monitoring and escalation outside the agent prompt.
The same logic applies to pause, resume, and delete. Pausing or deleting an automation does not stop work already accepted by a session, and a delivery already in progress may still reach its session. An operator who needs to stop an active action must understand the separate cancellation path. “Schedule paused” and “work stopped” are not interchangeable operational states.
Scheduled Automations can be a good fit when an application already uses the Agents API and wants recurring or one-time agent work delivered into managed sessions. It offers a shared place to define a schedule, inspect invocations, and let an agent manage schedules when that tool is enabled.
It is not a drop-in replacement for every job system. If a task is deterministic and does not need reasoning, a normal scheduler and program may be simpler. If a workflow must meet a strict service-level objective, preserve durable retries, or coordinate transactions across services, those requirements still need explicit infrastructure. An agent's ability to interpret an instruction does not remove the need for queue semantics, deduplication, timeouts, access controls, and outcome verification.
The best mental model is a scheduler attached to an asynchronous agent-session delivery system. Treat the schedule as the trigger, the invocation as evidence of an attempt, and the verified external state as evidence of completion. The distinction keeps the feature useful without attributing guarantees the API does not claim.
The feature is a meaningful step toward agents that can work without a person sending every prompt. But a saved schedule is not an autonomous worker, and a delivered instruction is not a completed task. The design question for developers is where to place the boundary between the agent's flexible reasoning and the application's deterministic guarantees.
I write about developer tools, AI systems, and backend engineering. Subscribe for more practical breakdowns of how these systems behave in production.
Have you put an agent on a schedule yet? What do you use as proof that the task actually finished?
Save the checklist before making a scheduled agent responsible for a real side effect.