Claude Managed Agents starten auf AWS jetzt nach Zeitplan
Scheduled Deployments verbinden POSIX-Cron, IANA-Zeitzonen und neue Agentensitzungen – ohne selbst betriebenen Scheduler.
Anthropic hat Scheduled Deployments für Claude Managed Agents auf Claude Platform on AWS verfügbar gemacht. Damit beginnt eine Agentenaufgabe zu einem festgelegten Termin automatisch: Der Zeitplan löst eine neue Sitzung aus, Claude arbeitet mit der hinterlegten Konfiguration und das System protokolliert das Ergebnis. Ein eigener Scheduler, der außerhalb der Plattform regelmäßig API-Aufrufe absetzt, ist dafür nicht mehr erforderlich.
Die Funktion gehört zur öffentlichen Beta von Claude Managed Agents. Anthropic kündigte Scheduled Deployments am 9. Juni 2026 an. Neu ist nicht nur ein weiterer Zeitgeber, sondern die direkte Verbindung zwischen Kalenderlogik und einer verwalteten Agentenumgebung mit zustandsbehafteten Sitzungen, Sandbox und Werkzeugausführung.
Ein Cron-Termin erzeugt eine vollständige Agentensitzung
Ein Scheduled Deployment besteht aus der vorhandenen Agentenkonfiguration und einem Zeitplan. Der Rhythmus wird als POSIX-Cron-Ausdruck angegeben; die gewünschte Zeitzone kommt als IANA-Bezeichner hinzu. Dadurch lässt sich beispielsweise „jeden Werktag am Morgen in Europa/Berlin“ präziser abbilden als mit einer bloßen UTC-Uhrzeit. Die Dokumentation zu Scheduled Deployments nennt eine Minute als kleinste unterstützte Zeiteinheit.
Beim Erreichen eines Termins setzt die Plattform nicht einfach eine alte Unterhaltung fort. Sie startet für diesen Ausführungsversuch eine neue Sitzung des Managed Agent. Das ist für wiederkehrende Aufgaben entscheidend: Jede Ausführung erhält einen klaren Anfang und lässt sich unabhängig von vorherigen Läufen zuordnen. Dauerhafter Kontext kann bei Bedarf über einen Memory Store bereitgestellt werden, ohne die einzelnen Sitzungen miteinander zu vermischen.
Tatsächliche Startzeiten dürfen laut Dokumentation einen begrenzten Jitter aufweisen. Scheduled Deployments eignen sich daher für regelmäßige Hintergrundaufgaben, aber nicht als sekundengenauer Taktgeber für zeitkritische Transaktionen. Wer einen Bericht um 07:00 Uhr benötigt, sollte den Zeitplan mit genügend Vorlauf vor der eigentlichen Übergabe setzen.
Aus dem Termin wird ein auswertbarer Ausführungsdatensatz
Jeder geplante Start erzeugt einen Datensatz für den Ausführungsversuch. Bei Erfolg enthält er die zugehörige Sitzungs-ID; bei einem Fehlschlag wird ein typisierter Fehler festgehalten. Damit besitzt jede geplante Aktivität einen maschinenlesbaren Ausgangspunkt für Statusanzeigen, Benachrichtigungen oder eine erneute Bearbeitung.
Die Sitzungs-ID ist dabei mehr als eine technische Quittung. Sie verbindet den Termin mit dem konkreten Agentenlauf, sodass sich dessen Verlauf getrennt untersuchen lässt. Der typisierte Fehler erlaubt es einer angebundenen Anwendung, verschiedene Fehlerklassen unterschiedlich zu behandeln, statt lediglich nach einem fehlenden Textresultat zu suchen.
Webhooks bieten sich als Ergänzung an: Der Zeitplan startet die Arbeit, während ein Webhook das nachgelagerte System über ein Ereignis informiert. So muss eine Anwendung nicht permanent nach abgeschlossenen Sitzungen fragen. Die Plattformdokumentation führt Scheduled Deployments und Webhooks gemeinsam unter den auf AWS verfügbaren Fähigkeiten auf.
Tägliche Zusammenfassungen ohne externen Scheduler
Ein konkretes Einsatzmuster ist eine tägliche Zusammenfassung. Der Zeitplan startet morgens eine neue Sitzung. Der Agent ruft über seine freigegebenen Werkzeuge die benötigten Informationen ab, verdichtet sie nach den hinterlegten Anweisungen und übergibt das Resultat an das angebundene Zielsystem. Zugangsdaten für externe Dienste können in einem Credential Vault liegen, statt im Prompt oder im Scheduler hinterlegt zu werden.
Gegenüber einem einfachen Cronjob liegt der Unterschied in der ausgeführten Einheit. Ein klassischer Scheduler startet gewöhnlich ein Skript oder sendet einen einzelnen Request. Scheduled Deployments starten dagegen einen Managed Agent, der innerhalb seiner Sitzung mehrere Werkzeugaufrufe ausführen, Zwischenergebnisse verarbeiten und die Aufgabe anhand des gefundenen Materials fortsetzen kann.
Anthropic nennt neben täglichen Zusammenfassungen auch nächtliche Datenabgleiche und wöchentliche Compliance-Prüfungen als typische Anwendungen. Für einen Datenabgleich kann der Agent beispielsweise zwei freigegebene Quellen aufrufen, Abweichungen zusammenstellen und nur bei relevanten Differenzen ein nachgelagertes Ereignis auslösen. Bei einer wiederkehrenden Prüfung kann er definierte Nachweise einsammeln und das Ergebnis jeder Ausführung über die Sitzungs-ID nachvollziehbar halten.
Memory Stores trennen Langzeitwissen von einzelnen Läufen
Weil jeder Termin eine neue Sitzung erzeugt, braucht längerfristiger Kontext einen eigenen Speicherort. Claude Managed Agents stellt dafür Memory Stores bereit. Ein geplanter Agent kann dadurch frühere Erkenntnisse oder einen fortgeschriebenen Arbeitsstand heranziehen, ohne eine alte Sitzung dauerhaft offenhalten zu müssen.
Diese Trennung ist besonders nützlich bei periodischen Beobachtungen. Eine tägliche Zusammenfassung kann im Memory Store festhalten, welche Themen am Vortag bereits behandelt wurden. Der nächste Lauf beginnt technisch neu, erhält aber den relevanten Verlauf als gezielten Kontext. Bei Datenabgleichen kann der Speicher den letzten bekannten Zustand enthalten, sodass der Agent Veränderungen statt vollständiger Bestände hervorhebt.
Credential Vaults erfüllen eine andere Aufgabe: Sie speichern Umgebungsvariablen und Geheimnisse für die Ausführung. Memory Stores liefern Kontext, Vaults liefern geschützte Zugangswerte. Zusammen mit dem Zeitplan entstehen damit drei getrennte Verantwortungsbereiche, die sich unabhängig verwalten lassen: Wann der Agent startet, welche Informationen er behalten darf und auf welche Systeme er zugreifen kann.
Der AWS-Zugang unterscheidet sich von der direkten Claude API
Claude Platform on AWS verwendet zwar die Claude-API-Endpunkte, der Zugang besitzt aber eine andere Basis-URL sowie AWS-Authentifizierung. Zusätzlich muss jeder Aufruf einen Workspace-Header enthalten. Bestehender Code für den direkten API-Zugang benötigt deshalb eine angepasste Verbindungs- und Authentifizierungsschicht; allein ein Austausch des API-Schlüssels genügt nicht.
Für AWS-Umgebungen liegt der Vorteil in der administrativen Anbindung. Laut AWS-Produktseite lassen sich AWS-Zugangsdaten, IAM-Richtlinien, CloudTrail und die vorhandene AWS-Abrechnung verwenden. Organisationen können den Zugriff damit über ihre AWS-Strukturen steuern und Aktivitäten in CloudTrail erfassen.
Claude Platform on AWS ist dennoch nicht Claude auf Amazon Bedrock. Der Dienst wird von Anthropic betrieben und verarbeitet Kundendaten außerhalb der AWS-Sicherheitsgrenze. Diese Abgrenzung ist für Architektur- und Datenhaltungsentscheidungen zentral: AWS stellt Zugang, Richtlinien und Abrechnung bereit, während die eigentliche Claude-Plattform bei Anthropic verbleibt.
AWS gibt an, dass die Preise den Preisen des direkten Zugriffs über die Claude API entsprechen. Für Scheduled Deployments nennt das bereitgestellte Material keinen separaten Aufpreis. Die tatsächliche Nutzung hängt davon ab, wie häufig ein Agent startet, welches Modell er verwendet und wie umfangreich seine Sitzungen und Werkzeugaufrufe ausfallen.
Sechs Stunden markieren die Grenze autonomer Sitzungen
Auf Claude Platform on AWS müssen autonome Sitzungen spätestens nach sechs Stunden durch ein neues Benutzerereignis reauthentifiziert werden. Ein Scheduled Deployment kann deshalb keine unbegrenzt laufende autonome Sitzung eröffnen. Für wiederkehrende Arbeit ist das meist passend: Jeder Termin startet ohnehin eine neue, abgegrenzte Ausführung.
Lange Aufgaben sollten so zugeschnitten sein, dass sie innerhalb dieses Fensters abgeschlossen werden oder einen definierten Übergabepunkt erreichen. Ein täglicher Bericht oder ein nächtlicher Abgleich ist dafür ein naheliegendes Profil. Ein Agent, der ohne neues Benutzerereignis über viele Stunden oder Tage ununterbrochen handeln soll, passt dagegen nicht zu dieser Sitzungsregel.
Der Zeitplan selbst darf häufiger laufen: Die kleinste Einheit beträgt eine Minute. Häufige Starts erzeugen jedoch jeweils neue Sitzungen und damit eigene Ausführungsversuche. Bei Aufgaben, die länger als ihr Intervall dauern können, muss die angebundene Logik parallele Läufe bewusst berücksichtigen, damit dieselben Daten nicht gleichzeitig mehrfach bearbeitet werden.
Beta-Zugang und organisatorische Obergrenze
Claude Managed Agents befindet sich in der Beta. API-Aufrufe benötigen den Beta-Header managed-agents-2026-04-01. Die Übersicht zu Claude Managed Agents nennt außerdem zwei derzeit nicht unterstützte Eigenschaften: Zero Data Retention und eine Abdeckung durch ein HIPAA Business Associate Agreement.
Pro Organisation werden höchstens 1.000 geplante Bereitstellungen unterstützt. Das ist ein Organisationslimit, nicht die Zahl der Termine in einem einzelnen Cron-Ausdruck. Für viele wiederkehrende Aufgaben ist es daher sinnvoll, Zeitpläne nach Zweck und Agentenkonfiguration zu bündeln, anstatt für jede kleine Variation ein eigenes Deployment anzulegen.
Die Kombination aus Beta-Header, möglichem Start-Jitter und typisierten Fehlern zeigt das passende Betriebsmodell: Scheduled Deployments übernehmen die wiederkehrende Auslösung und liefern einen dokumentierten Status zurück. Anwendungen können diesen Status auswerten und bei Fehlschlägen gezielt reagieren. Zeitkritische Garantien oder regulatorische Anforderungen, die Zero Data Retention beziehungsweise eine HIPAA-BAA-Abdeckung voraussetzen, werden von diesem Angebot derzeit nicht erfüllt.
Wo Scheduled Deployments den größten Unterschied machen
Der neue Baustein passt zu Aufgaben, die regelmäßig beginnen, innerhalb einer überschaubaren Sitzung mehrere Werkzeuge verwenden und ein klar abgrenzbares Resultat erzeugen. Tägliche Briefings, periodische Datenabgleiche und dokumentierte Prüfungen erfüllen dieses Muster. Cron-Ausdruck und Zeitzone bestimmen den Start, Vaults liefern benötigte Geheimnisse, Memory Stores stellen ausgewählten Langzeitkontext bereit und Webhooks können das Ergebnis an weitere Systeme melden.
Weniger passend sind sekundengenaue Ereignisverarbeitung und dauerhaft laufende Agenten. Dafür sprechen sowohl der begrenzte Jitter als auch die Reauthentifizierung nach spätestens sechs Stunden. Scheduled Deployments sind somit kein Ersatz für jede Form von Orchestrierung. Sie schließen vielmehr die konkrete Lücke zwischen einem wiederkehrenden Termin und einer vollständig verwalteten Claude-Agentensitzung auf AWS.