Polling-Agenten in KI-Assistenten: 11 Implementierungsmuster

Polling-Agenten gehören zu den wenig glamourösen Aspekten der Architektur von KI-Assistenten, sind jedoch gleichzeitig eine der nützlichsten Komponenten.

Ein herkömmlicher Chat-Assistent wartet darauf, dass der Benutzer eine Frage stellt. Ein Polling-Agent (Abfrage-Agent) beobachtet kontinuierlich. Er überprüft eine Datenquelle, erkennt Änderungen, entscheidet, ob diese relevant sind, und handelt dann entsprechend. Diese Handlung kann eine Benachrichtigung, eine Zusammenfassung, ein Entwurf, ein Tool-Aufruf oder ein vollständiger Workflow sein.

So entwickelt sich ein Assistent von der Funktion „Beantworte meine Frage“ hin zur Funktion „Behalte dies für mich im Auge“. Anstatt reaktiv zu sein, wird er zu einem Hintergrundprozess, der im Namen des Benutzers Dinge bemerkt und handelt, wenn bestimmte Bedingungen erfüllt sind.

Der wichtige Designgedanke ist einfach: Machen Sie das Sprachmodell nicht für Zeit, Zustand, Wiederholungsversuche oder Sperren verantwortlich. Verwenden Sie dafür normale Backend-Infrastruktur. Nutzen Sie das Modell dort, wo es wertvoll ist: bei der Interpretation unstrukturierten Kontexts, beim Treffen semantischer Urteile und bei der Erzeugung nützlicher Sprache.

Was ist ein Polling-Agent?

Ein Polling-Agent ist ein Hintergrundprozess, der wiederholt eine Quelle überprüft und eine Assistentenaktion auslöst, wenn eine Bedingung erfüllt ist. In der breiteren AI Systems-Architektur – wo der Assistent ein LLM (Large Language Model), Speicher, Tooling, Routing und Observability kombiniert – ist die Polling-Schicht das Element, das den Assistenten proaktiv statt rein reaktiv macht. Für das vollständige Fünf-Schichten-Modell siehe AI Assistant Architecture: LLM, Memory, Tools, Routing, Observability.

Beispiele:

• Prüfe jeden Morgen einen Posteingang und fasse wichtige Nachrichten zusammen.
• Beobachte eine Notion-Aufgabenliste und führe den nächsten Todo-Ausführungsschritt aus.
• Überwache ein GitHub-Issue, bis sich der Status ändert.
• Polling eines lang laufenden KI-Jobs, bis das Ergebnis bereit ist.
• Prüfe einen Buchungstermin, bis einer verfügbar wird.
• Beobachte ein Lieferantenportal, bis ein Dokument erscheint.
• Scanne einmal pro Woche neue Forschungsarbeiten und fasse relevante zusammen.

Ein praktischer Polling-Agent hat fünf Verantwortlichkeiten:

1. Zur richtigen Zeit aufwachen.
2. Aus der Quelle lesen.
3. Sich merken, was bereits gesehen wurde.
4. Entscheiden, ob der neue Zustand relevant ist.
5. Einmalig, sicher und ohne sich selbst zu wiederholen, handeln.

Ein typischer Produktionsablauf sieht wie folgt aus:

Scheduler
  -> Polling-Worker
  -> Quellsystem
  -> Zustandspeicher
  -> deterministische Filter
  -> optionale LLM-Auswertung
  -> Assistentenaktion

Diese Struktur ist auf die bestmögliche Weise langweilig. Langweilige Systeme sind um 2 Uhr morgens leichter zu debuggen.

Der Zustand, den jeder Polling-Agent benötigt

Polling-Agenten benötigen einen persistenten Zustand. Konversationsverlauf reicht nicht aus. Der Assistent kann sich die Konversation merken, aber das System benötigt eine zuverlässige operative Aufzeichnung.

Ein guter Polling-Zustandsdatensatz enthält normalerweise:

{
  "poll_id": "poll_123",
  "user_id": "user_456",
  "source_type": "notion",
  "source_ref": "database_tasks",
  "condition": "Nimm eine Aufgabe im Todo-Zustand und führe sie aus",
  "interval_seconds": 600,
  "last_run_at": "2026-06-19T01:00:00Z",
  "next_run_at": "2026-06-19T01:10:00Z",
  "last_seen_cursor": "cursor_or_timestamp",
  "last_result_hash": "b64e8a...",
  "failure_count": 0,
  "status": "active"
}

Das genaue Schema hängt von der Quelle ab, aber die meisten Systeme benötigen diese Konzepte.

Poll-Definition

Dies beschreibt, was der Agent beobachtet und warum.

poll_id
user_id
workspace_id
source_type
source_ref
condition_text
priority
status

Zum Beispiel:

source_type: notion
source_ref: Tasks database
condition_text: Finde eine Todo-Aufgabe, beanspruche sie, führe sie aus und markiere sie als Fertig.

Zeitplan

Dies beschreibt, wann der Agent laufen soll.

interval_seconds
cron_expression
timezone
last_run_at
next_run_at
jitter

Für einen Hermes-Agenten, der Notion alle 10 Minuten überprüft:

interval_seconds: 600
timezone: Australia/Melbourne

Cursor oder Snapshot

Dies hilft dem Agenten, das gleiche Datenmaterial nicht erneut zu verarbeiten.

Je nach Quelle kann dies sein:

last_seen_id
last_seen_timestamp
api_cursor
etag
version
content_hash

Für eine Notion-Aufgabenwarteschlange ist der Cursor möglicherweise weniger wichtig als der Aufgabenstatus und die Claim-Felder. Für Gmail, GitHub oder eine Sync-API ist der Cursor normalerweise kritisch.

Claim oder Lease (Miete)

Dies verhindert, dass zwei Worker dieselbe Aufgabe übernehmen.

claimed_by
claimed_at
claim_expires_at
run_id

Zum Beispiel kann eine Notion-Aufgabe geändert werden von:

Status: Todo

zu:

Status: InProgress
ClaimedBy: hermes
ClaimedAt: 2026-06-19T01:00:00Z
ClaimExpiresAt: 2026-06-19T01:30:00Z
RunId: run_789

Dies ist der Unterschied zwischen „Ich hoffe, nur ein Worker wählt sie“ und „das System hat ein Claim-Protokoll“.

Ausführungsprotokoll

Dies protokolliert, was während einer Ausführung geschehen ist.

run_id
poll_id
source_object_id
started_at
finished_at
status
items_checked
items_changed
decision_summary
error

Das Ausführungsprotokoll sollte im Assistenten-Backend leben, nicht nur in Notion oder einem anderen externen Tool. Notion ist gut für die Sichtbarkeit durch Menschen. Es ist nicht ideal als einziges Ausführungsprotokoll.

Dedupe-Protokoll (Entdopplung)

Dies verhindert doppelte Benachrichtigungen oder wiederholte Aktionen.

dedupe_key
poll_id
source_object_id
condition_version
action_type
delivered_at

Zum Beispiel:

user_456:poll_123:notion_page_999:execute:v1

Wenn dieselbe Aktion erneut versucht wird, kann das System sie unterdrücken.

Methode 1: Geplanter Polling-Worker

Dies ist das einfachste zuverlässige Muster.

Ein Scheduler wacht alle festen Intervalle auf und ruft einen Worker auf. Der Worker liest die Quelle, aktualisiert den Zustand und löst bei Bedarf eine Assistentenaktion aus.

Scheduler
  -> Worker
  -> Quell-API
  -> Datenbank
  -> Assistentenaktion

Wie es läuft

Der Scheduler ist für die Zeit verantwortlich. Es könnte Cron, ein Cloud-Scheduler, ein Kubernetes CronJob oder ein kleiner interner Scheduler sein.

In jedem Intervall startet er einen Worker-Lauf. Der Worker lädt seine Konfiguration, fragt die Zielquelle ab, vergleicht das Ergebnis mit dem gespeicherten Zustand und handelt bei Bedarf.

Für einen einfachen Assistenten reicht dies oft aus. Ein einzelner Scheduler und ein leichtgewichtiger Worker-Prozess können dutzende tägliche Prüfungen bewältigen, ohne Warteschlangen, Leases oder verteilte Koordination zu benötigen.

Zustandsmodell

Der Scheduler speichert sehr wenig. Normalerweise weiß er nur, wann er einen Job auslösen soll.

Die Anwendungsdatenbank speichert den wichtigen Zustand:

Poll-Definition
Zeitplan
Cursor oder Snapshot
Letzte Ausführungszeit
Fehleranzahl
Status

Der Worker sollte zustandslos sein. Er kann temporäre Daten während der Ausführung halten, aber die persistente Wahrheit gehört in die Datenbank.

Beispielablauf

Alle 10 Minuten:
  Hermes-Polling-Worker auslösen

Worker:
  aktive Poll-Konfiguration laden
  Quelle abfragen
  mit vorherigem Zustand vergleichen
  deterministische Checks ausführen
  LLM nur aufrufen, wenn nötig
  Zustand aktualisieren
  Assistenten-Ereignis emittieren

Beste Anwendung

Verwenden Sie geplante Polling-Worker für:

• Tägliche Zusammenfassungen.
• Stündliche Checks.
• Kleine interne Automatisierungen.
• Einfache „Behalte dies im Auge“-Aufgaben.
• Assistentenjobs mit niedriger bis mittlerer Volumenbelastung.

Schwächen

Geplantes Polling ist einfach zu verstehen, kann aber im großen Maßstab zerbrechlich werden. Wenn viele Polls gleichzeitig laufen, können Sie Ihre Worker überlasten oder die Rate-Limits der Anbieter erreichen. Wiederholungsversuche können auch unübersichtlich werden, wenn der Scheduler die Arbeit direkt startet.

Methode 2: Warteschlangenbasierte Polling-Worker

Warteschlangenbasiertes Polling ist in der Regel das beste Standardverfahren für Produktions-KI-Assistenten.

Der Scheduler führt den Poll nicht direkt aus. Er stellt einen Job in eine Warteschlange. Worker-Prozesse entnehmen Jobs aus der Warteschlange.

Scheduler
  -> Warteschlange
  -> Worker-Pool
  -> Quell-API
  -> Zustandspeicher
  -> Assistentenaktion

Wie es läuft

Ein Scanner sucht nach fälligen Polls und stellt Jobs in die Warteschlange. Worker ziehen Jobs ab, wenn sie Kapazität haben.

Dies gibt Ihnen Backpressure (Gegendruck). Wenn das System beschäftigt ist, warten Jobs in der Warteschlange, anstatt die Quell-API oder den LLM-Anbieter zu überfordern.

Zustandsmodell

Die Datenbank speichert den Poll-Zustand:

poll_id
user_id
source_ref
condition_text
next_run_at
cursor
status
failure_count

Die Warteschlangen-Nachricht sollte klein bleiben:

{
  "poll_id": "poll_123",
  "scheduled_for": "2026-06-19T01:10:00Z",
  "attempt": 1
}

Der Worker lädt den vollständigen Zustand aus der Datenbank, wenn er startet.

Beispielablauf

Alle Minute:
  Scheduler findet Polls, bei denen next_run_at <= jetzt ist
  Scheduler stellt Jobs in die Warteschlange

Worker:
  entnehmen Jobs aus der Warteschlange
  sperren oder mieten den Poll
  Quelle abfragen
  Zustand aktualisieren
  bei Bedarf Assistentenaktion emittieren
  next_run_at setzen

Beste Anwendung

Verwenden Sie warteschlangenbasiertes Polling für:

• KI-Assistenten mit mehreren Benutzern.
• Viele simultane Polls.
• Integrationen mit Rate-Limits.
• Wiederholbare Hintergrundarbeit.
• Jobs, die unterschiedlich lange dauern können.
• SaaS-Produkte, bei denen Zuverlässigkeit wichtig ist.

Schwächen

Warteschlangen fügen Infrastruktur hinzu. Sie benötigen Dead-Letter-Handling, Idempotenz, Sichtbarkeits-Timeouts und Wiederholungsrichtlinien. Das lohnt sich für Produktionssysteme, ist aber wahrscheinlich für einen kleinen Prototyp übertrieben.

Methode 3: Externes Tool als Aufgabenwarteschlange

Dies ist das Muster im Beispiel mit Notion plus Hermes.

Das externe Tool ist nicht nur eine Datenquelle. Es wird zur menschenfreundlichen Aufgabenwarteschlange. Der Agent prüft das Tool regelmäßig, beansprucht eine Aufgabe, führt sie aus und aktualisiert den Aufgabenstatus.

Scheduler
  -> Hermes-Worker
  -> Notion-Datenbank
  -> eine Aufgabe beanspruchen
  -> Aufgabe ausführen
  -> Notion-Status aktualisieren

Wie es läuft

Alle 10 Minuten fragt Hermes die Notion-Datenbank nach einer Aufgabe im Zustand Todo ab. Er wählt die nächste Aufgabe, normalerweise nach Priorität und Erstellungszeit. Dann beansprucht er die Aufgabe, indem er sie auf InProgress setzt.

Danach führt Hermes die Aufgabe aus. Wenn die Ausführung erfolgreich ist, markiert er die Aufgabe als Complete. Wenn die Ausführung fehlschlägt, markiert er die Aufgabe als Failed oder gibt sie mit einer Wiederholungsanzahl nach Todo zurück.

Zustandsmodell

Notion speichert den menschenfreundlichen Aufgabenzustand:

Titel
Beschreibung
Status: Todo | InProgress | Complete | Failed
Priorität
CreatedAt
ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId
RetryCount
LastError
CompletedAt

Das Hermes-Backend speichert den operativen Ausführungszustand:

run_id
notion_page_id
started_at
finished_at
execution_status
tool_calls
LLM trace
error details
idempotency_key

Diese Aufteilung ist wichtig. Notion ist hervorragend für Sichtbarkeit und manuelle Bearbeitung. Das Hermes-Backend ist besser für Protokolle, Wiederholungsversuche, Entdopplung und Audit-Historie.

Beispielablauf

Alle 10 Minuten:
  Hermes wacht auf

Hermes:
  Notion abfragen nach einer Aufgabe, wo Status = Todo
  sortieren nach Priorität, CreatedAt
  ausgewählte Aufgabe auf InProgress aktualisieren
  ClaimedBy, ClaimedAt, ClaimExpiresAt, RunId setzen
  die Aufgabe ausführen
  Ausführungsprotokoll schreiben
  Aufgabe auf Complete oder Failed setzen

Beste Anwendung

Verwenden Sie dieses Muster, wenn:

• Menschen die Arbeit bereits in Notion, Jira, Linear, Trello oder einem anderen Tool verwalten.
• Sie möchten, dass der Assistent sichtbare Aufgaben verarbeitet.
• Das Task-Board die Benutzeroberfläche ist.
• Sie ein einfaches Human-in-the-Loop-Automatisierungsmodell benötigen.

Schwächen

Externe Tools sind selten perfekte Warteschlangen. Atomare Claims können begrenzt sein. Die Abfragekonsistenz kann verzögert sein. Rate-Limits können gelten. Wenn der Agent in mehreren Instanzen laufen kann, benötigen Sie eine sorgfältige Claim- oder Lease-Strategie.

Die praktische Empfehlung ist, Notion als menschenfreundlichen Aufgabenposteingang zu verwenden, während alle Ausführungsprotokolle, Wiederholungsprotokolle, Traces und Idempotenzschlüssel in Hermes bleiben. Notion gibt Benutzern Sichtbarkeit; Hermes hält das System zuverlässig. Für die Dispatcher- und Konkurzenzmechanik, die sich hinter diesem Muster in Hermes befinden, siehe Kanban in Hermes Agent for Self Hosted LLM Workflows.

Methode 4: Lang laufender Worker-Loop

Ein lang laufender Loop ist die einfachste Implementierung.

while True:
    due_polls = db.find_due_polls()
    for poll in due_polls:
        run_poll(poll)
    sleep(30)

Dieses Muster kombiniert Planung und Ausführung in einem Dienst, was es zum einfachstmöglichen Ausgangspunkt für Hintergrund-Agent-Arbeit macht.

Wie es läuft

Der Worker-Prozess läuft kontinuierlich. Alle paar Sekunden oder Minuten prüft er die Datenbank auf fällige Polls und führt sie aus. Es ist einfach zu bauen, einfach zu verstehen und schnell zu iterieren während der Entwicklung.

Zustandsmodell

Die Datenbank speichert weiterhin persistenten Zustand:

Poll-Konfiguration
next_run_at
cursor
last result
failure count
status

Der Prozessspeicher sollte nur temporären Zustand enthalten:

current batch
short-lived cache
in-flight run

Speichern Sie wichtigen Fortschritt niemals nur im Speicher. Wenn der Prozess abstürzt, ist jeder Zustand, der nicht in den persistenten Speicher geschrieben wurde, verloren, und der nächste Lauf hat keine Möglichkeit zu wissen, wo die Dinge aufgehört haben.

Beste Anwendung

Verwenden Sie lang laufende Loops für:

• Prototypen.
• Lokale Entwicklung.
• Interne Tools.
• Single-Tenant-Systeme.
• Agents mit niedriger Volumenbelastung.

Schwächen

Dieses Muster wird riskant mit mehreren Replikaten. Ohne Leases können zwei Worker denselben Poll ausführen. Es fehlen auch die operativen Funktionen einer echten Warteschlange oder Workflow-Engine.

Ein lang laufender Loop ist als Ausgangspunkt nicht falsch, aber er ist kein verteilter Scheduler und sollte nicht als solcher behandelt werden. Sobald Sie mehrere Replikate oder stärkere Zuverlässigkeitsgarantien benötigen, müssen Sie zu einem der oben genannten strukturierten Muster wechseln.

Methode 5: Webhook-First mit Polling-Fallback

Wenn die Quelle Webhooks unterstützt, verwenden Sie diese. Polling sollte oft das Backup sein, nicht der primäre Mechanismus. Dieselbe Aufteilung erscheint im Agent-Protokoll-Design: A2A-Push-Benachrichtigungen wecken einen Client-Handler, der dann GetTask für den vollständigen Zustand abfragt, wie in A2A Streaming and Async Tasks for Long-Running Agent Workflows beschrieben.

externes System
  -> Webhook-Endpunkt
  -> Ereignisspeicher
  -> Assistentenaktion

Rekonziliations-Poll
  -> Quell-API
  -> Vergleich mit Ereignisspeicher
  -> Reparatur verpasster Ereignisse

Wie es läuft

Das externe System sendet Ereignisse an Ihren Webhook-Endpunkt, wenn sich etwas ändert. Ihr System speichert das Ereignis und verarbeitet es asynchron.

Ein langsamerer Rekonziliations-Poll läuft alle paar Stunden oder einmal pro Tag. Er prüft, ob Ereignisse verpasst wurden.

Zustandsmodell

Der Ereignisspeicher protokolliert eingehende Webhooks:

event_id
source_type
source_object_id
event_type
received_at
payload_hash
processed_at
signature_valid

Der Rekonziliations-Poll speichert:

last_reconciliation_at
last_seen_cursor
last_seen_version

Die Quellobjekt-Tabelle speichert den letzten bekannten Zustand:

external_id
current_status
external_updated_at
last_processed_event_id

Beste Anwendung

Verwenden Sie Webhook-First-Architektur für:

• GitHub-Ereignisse.
• Stripe-Ereignisse.
• Slack-Ereignisse.
• CRM-Updates.
• Bereitstellungsbenachrichtigungen.
• Ticketing-Systeme.

Schwächen

Webhooks erfordern einen öffentlichen Endpunkt, Signaturvalidierung, Replay-Schutz und Ereignis-Entdopplung. Einige Anbieter senden auch unvollständige Ereignisse, sodass Sie möglicherweise trotzdem das vollständige Objekt abrufen müssen.

Dennoch ist Polling alle Minute normalerweise verschwenderisch, wenn gute Webhooks existieren.

Methode 6: Provider-seitiges Hintergrund-Job-Polling

Manchmal ist das Abgefragte der KI-Job selbst.

Die Anwendung startet einen lang laufenden Provider-Job, speichert die Job-ID und prüft später, ob er abgeschlossen ist.

App
  -> KI-Hintergrundjob starten
  -> Provider-Job-ID speichern
  -> Status abfragen
  -> Ergebnis abrufen
  -> Benutzer benachrichtigen

Wie es läuft

Der Assistent startet einen Job mit dem Anbieter. Der Anbieter gibt eine ID zurück. Ihr Backend speichert diese ID und prüft ihren Status, bis der Job erfolgreich ist, fehlschlägt, abläuft oder ein Timeout erreicht.

Zustandsmodell

Ihr Backend speichert:

assistant_task_id
provider_job_id
user_id
status
created_at
last_checked_at
expires_at
result_ref

Der Anbieter speichert den temporären Job-Zustand und die Ausgabe.

Wenn die Ausgabe wichtig ist, kopieren Sie sie so bald wie möglich nach Abschluss des Jobs in Ihren eigenen persistenten Speicher. Provider-seitige Ergebnisspeicherung hat kurze Aufbewahrungszeitfenster und ist kein Ersatz für ein ordnungsgemäßes Archiv in Ihrem eigenen System.

Beste Anwendung

Verwenden Sie provider-seitiges Hintergrund-Job-Polling für:

• Lange KI-Forschungsaufgaben.
• Großes Dokumentenprocessing.
• Codebasis-Analyse.
• Berichterstellung.
• Datenextraktionsjobs.
• Aufgaben, die normale HTTP-Anfrage-Timeouts überschreiten.

Schwächen

Dieses Muster löst ein Problem: Warten auf einen langen Provider-Job. Es ersetzt nicht Ihre Workflow-Engine, Ihren Scheduler, Ihre Warteschlange oder Ihren Geschäftszustandspeicher.

Methode 7: Durable Workflow Engine (Persistente Workflow-Engine)

Eine persistente Workflow-Engine verwaltet lang laufende Ausführung, Timer, Wiederholungsversuche und Wiederherstellung. Temporal ist die häufigste Wahl für Go- und Python-basierte Assistenten-Backends; für einen vollständigen Implementierungsleitfaden siehe Implementing Workflow Applications with Temporal in Go.

Anstatt jedes Warten und jede Wiederholung manuell zu verdrahten, modellieren Sie den Prozess als Workflow.

Workflow-Engine
  -> Aktivität: Quelle überprüfen
  -> Timer: warten
  -> Aktivität: Ergebnis auswerten
  -> Aktivität: Benutzer benachrichtigen

Wie es läuft

Der Workflow startet einmal und steuert dann sein eigenes Warten. Er kann minuten-, tageweise oder wochenlang schlafen. Wenn der Worker-Prozess abstürzt, kann die Workflow-Engine vom aufgezeichneten Zustand aus wieder aufnehmen.

Zustandsmodell

Die Workflow-Engine speichert:

workflow_id
execution history
timer state
activity attempts
retry policy
current workflow state

Ihre Anwendungsdatenbank speichert:

user-facing poll definition
authorization references
business records
notification records

Die Workflow-Engine besitzt den Prozesszustand – Ausführungshistorie, Timer, Wiederholungsversuche und Aktivitätsversuche. Ihre Datenbank besitzt den Geschäftszustand – Benutzerkonfigurationen, Autorisierungsprotokolle, Benachrichtigungen und Audit-Logs. Das Trennen dieser beiden verhindert, dass jede Schicht zu einem verwirrten Hybrid aus beiden wird.

Beste Anwendung

Verwenden Sie persistente Workflows für:

• Mehrstufige Geschäftsprozesse.
• Lang laufende Automatisierungen.
• Human-Approval-Flows.
• Zuverlässige Wiederholungsversuche.
• Auditierbare Hintergrundarbeit.
• Prozesse, die nach einem Fehler wieder aufgenommen werden müssen.

Schwächen

Workflow-Engines fügen Konzepte und Infrastruktur hinzu. Sie sind hervorragend, wenn der Prozess wichtig ist, aber schwerfälling für einfache stündliche Checks.

Methode 8: Persistenter Agent-Runtime

Einige Agent-Frameworks können Agent-Zustand persistieren, Ausführung checkpointen und später wieder aufnehmen.

Dies ist nützlich, wenn der Agent selbst einen mehrstufigen Reasoning-Prozess hat.

Scheduler oder Workflow
  -> Agent-Runtime
  -> Checkpoint laden
  -> Tools aufrufen
  -> Checkpoint speichern
  -> später wieder aufnehmen

Wie es läuft

Ein externer Scheduler oder Workflow startet den Agenten. Die Agent-Runtime lädt den vorherigen Zustand, führt den nächsten Schritt aus, ruft bei Bedarf Tools auf und schreibt einen Checkpoint.

Die Agent-Runtime sollte nicht Ihr einziger Scheduler sein. Sie ist besser als die Reasoning-Schicht innerhalb einer größeren Backend-Architektur zu betrachten.

Zustandsmodell

Agent-Checkpoint-Speicher enthält:

current node
messages
tool outputs
intermediate reasoning state
pending action

Langzeitspeicher enthält:

stable user preferences
facts
project context
source references

Operativer Zustand gehört weiterhin woanders hin:

poll schedule
cursor
status
retry count
dedupe records

Eine nützliche Regel: Speicher ist kein Cursor, und ein Checkpoint ist keine Warteschlange. Agent-Speicher speichert, was das Modell weiß; operativer Zustand verfolgt, wo der Prozess ist und was es getan hat. Das Vermischen der beiden führt zu subtilen Bugs, die nur unter Konkurrenz oder nach einem Neustart auftreten. Der gesamte Designraum für Arbeitsspeicher, persistenten Zustand und Retrieval-Schichten wird in Memory Systems in AI Assistants behandelt.

Beste Anwendung

Verwenden Sie persistente Agent-Runtime für:

• Mehrstufige Forschung.
• Agenten, die pausieren und fortfahren.
• Human-in-the-Loop-Arbeit.
• Tool-lastige Reasoning-Aufgaben.
• Aufgaben, bei denen sich Kontext im Laufe der Zeit ansammelt.

Schwächen

Agent-Persistenz ist nicht dasselbe wie operative Zuverlässigkeit. Sie benötigen immer noch Planung, Sperren, Wiederholungsversuche, Rate-Limits und Audit-Logs.

Methode 9: Datenbank-Sync plus Änderungsauswertung

In diesem Muster wird Polling verwendet, um externe Daten in Ihre eigene Datenbank zu synchronisieren. Der Assistent reagiert dann auf lokale Datenbankänderungen, anstatt bei jedem Auswertungszyklus direkt externe APIs abzufragen.

Sync-Poller
  -> externe API
  -> lokale Datenbank
  -> Änderungsauswertung
  -> Assistentenaktion

Dies trennt die Datensynchronisierung von der Assistentenintelligenz. Der Sync-Worker ist dafür verantwortlich, lokale Datensätze aktuell zu halten; der Auswerter ist dafür verantwortlich, zu entscheiden, was mit Änderungen geschehen soll. Jede Schicht kann unabhängig getestet, überwacht und skaliert werden.

Wie es läuft

Der Sync-Worker holt regelmäßig externe Änderungen ab und schreibt normalisierte Datensätze in Ihre Datenbank. Ein zweiter Worker oder Änderungsstrom erkennt aktualisierte Zeilen und entscheidet, ob der Assistent handeln soll.

Zustandsmodell

Die Sync-Tabelle speichert:

external_id
source_type
raw_payload
normalized_fields
external_updated_at
synced_at
version
content_hash

Der Sync-Zustand speichert:

source_cursor
last_sync_at
rate_limit_status
failure_count

Die Assistenten-Auswertungstabelle speichert:

object_id
evaluation_status
last_evaluated_hash
decision
notification_id

Beste Anwendung

Verwenden Sie dieses Muster für:

• CRM-Sync.
• Ticketing-Systeme.
• Buchhaltungsunterlagen.
• Produktinventar.
• Compliance-Überprüfung.
• Suchindexierung.
• Interne Dashboards.

Schwächen

Das Synchronisieren von allem kann teuer und unnötig sein. Es kann auch Datenschutz- und Aufbewahrungspflichten schaffen. Verwenden Sie dieses Muster, wenn lokale Daten einen Wert jenseits einer einzelnen Assistentenaktion haben.

Methode 10: Adaptives Polling

Adaptives Polling ändert die Frequenz basierend auf Zustand, Dringlichkeit oder jüngster Aktivität.

aktives Objekt: alle 1 Minute pollen
wartendes Objekt: alle 1 Stunde pollen
veraltetes Objekt: einmal pro Tag pollen
abgeschlossenes Objekt: Polling stoppen

Wie es läuft

Nach jedem Lauf entscheidet der Worker, wann der nächste Lauf stattfinden soll.

Wenn sich das Objekt kürzlich geändert hat, pollen Sie früher. Wenn sich lange nichts geändert hat, verlangsamen Sie. Wenn die Aufgabe abgeschlossen ist, stoppen Sie.

Zustandsmodell

Der Poll-Zustand enthält:

current_interval
minimum_interval
maximum_interval
backoff_policy
last_activity_at
priority
stop_condition

Der Quell-Snapshot enthält:

status
updated_at
activity_level
expected_next_change

Beste Anwendung

Verwenden Sie adaptives Polling für:

• Bereitstellungsstatus.
• Sendungsverfolgung.
• Kalenderterminverfügbarkeit.
• Preisüberwachung.
• Build-Jobs.
• Lang laufende Provider-Aufgaben.
• Jede Quelle mit burstartigen Updates.

Schwächen

Adaptives Polling kann schwerer zu verstehen sein. Wenn eine Aufgabe zu einer strengen Zeit laufen muss, halten Sie es streng. Machen Sie Compliance-Jobs nicht clever.

Methode 11: Semantisches Polling mit einem LLM-Auswerter

Semantisches Polling wird verwendet, wenn die Bedingung ungenau ist.

Code kann antworten:

Ist Status gleich Fertig?
Ist Preis unter 100?
Gibt es eine neue Nachricht?

Ein LLM kann helfen zu antworten:

Klingt diese E-Mail dringend?
Ist dieser Kunde wahrscheinlich unzufrieden?
Ist diese Forschungsarbeit relevant?
Erfordert diese Änderung meine Aufmerksamkeit?

Wie es läuft

Der Worker wendet zuerst billige deterministische Filter an. Nur Kandidatenelemente gehen zum LLM.

neues Element?
entspricht Quellfiltern?
nicht bereits verarbeitet?
nicht offensichtlich irrelevant?

Dann wertet das LLM die kleinere Kandidatenmenge aus und gibt strukturierte Ausgabe zurück.

{
  "should_notify": true,
  "urgency": "high",
  "reason": "Der Kunde meldet einen Produktionsausfall."
}

Zustandsmodell

Die Poll-Definition speichert:

semantic_condition
examples
negative_examples
user_preference_summary
model_config

Das Auswertungsprotokoll speichert:

input_reference
model
prompt_version
structured_output
confidence
cost
latency

Der Poll-Zustand speichert:

last_seen_ids
last_evaluated_hashes
last_decision
last_decision_reason

Beste Anwendung

Verwenden Sie semantisches Polling für:

• Erkennung wichtiger E-Mails.
• Überwachung der Kundengefüge.
• Forschungsalarme.
• Erkennung von Verkaufschancen.
• Sicherheits-Triage.
• Executive-Briefings.

Schwächen

LLM-Aufrufe kosten Geld und fügen Latenz hinzu. Sie können auch inkonsistent sein, wenn Prompts und Schemata lose sind. Verwenden Sie zuerst deterministische Filter. Fragen Sie das Modell nur, wenn Urteil tatsächlich benötigt wird.

Entscheidungstabelle: Wahl einer Polling-Agent-Methode

Empfohlene Standardarchitektur

Für die meisten Produktions-KI-Assistenten beginnen Sie damit:

polls table
  -> Scheduler
  -> Warteschlange
  -> zustandslose Worker
  -> deterministische Filter
  -> optionaler LLM-Auswerter
  -> Benachrichtigung oder Assistentenaktion

Ein minimales Schema:

CREATE TABLE polls (
    id TEXT PRIMARY KEY,
    user_id TEXT NOT NULL,
    source_type TEXT NOT NULL,
    source_ref TEXT NOT NULL,
    condition_text TEXT NOT NULL,
    schedule_type TEXT NOT NULL,
    interval_seconds INTEGER,
    timezone TEXT,
    next_run_at TIMESTAMP NOT NULL,
    last_run_at TIMESTAMP,
    cursor_value TEXT,
    last_hash TEXT,
    status TEXT NOT NULL,
    failure_count INTEGER NOT NULL DEFAULT 0,
    last_error TEXT,
    created_at TIMESTAMP NOT NULL,
    updated_at TIMESTAMP NOT NULL
);

CREATE TABLE poll_runs (
    id TEXT PRIMARY KEY,
    poll_id TEXT NOT NULL,
    started_at TIMESTAMP NOT NULL,
    finished_at TIMESTAMP,
    status TEXT NOT NULL,
    items_checked INTEGER,
    items_matched INTEGER,
    decision_summary TEXT,
    error TEXT
);

CREATE TABLE notifications (
    id TEXT PRIMARY KEY,
    poll_id TEXT NOT NULL,
    user_id TEXT NOT NULL,
    dedupe_key TEXT NOT NULL,
    title TEXT NOT NULL,
    body TEXT NOT NULL,
    delivered_at TIMESTAMP,
    UNIQUE (dedupe_key)
);

Dies gibt Ihnen eine saubere Trennung:

Scheduler besitzt Zeit
Warteschlange besitzt Pufferung
Worker besitzt Ausführung
Datenbank besitzt Zustand
LLM besitzt semantisches Urteil
Assistent besitzt Benutzerinteraktion

Diese Trennung ist das Herz eines zuverlässigen Polling-Agenten.

Beispiel: Hermes-Agent verarbeitet Notion-Aufgaben

Wenden wir nun die Architektur auf einen konkreten Fall an.

Gehen Sie davon aus, dass eine Notion-Datenbank Aufgaben enthält. Hermes sollte alle 10 Minuten laufen, eine Aufgabe im Todo-Zustand nehmen, sie auf InProgress setzen, sie ausführen und dann als Complete markieren.

Dies ist am besten beschrieben als:

externes Tool als Aufgabenwarteschlange
+
geplanter Polling-Worker
+
claim- oder lease-basierte Ausführung

Für eine Produktionsversion wird es zu:

warteschlangenbasiertes Polling mit Notion als menschenfreundlichem Aufgabenposteingang

Notion-Aufgabendaten

Die Notion-Datenbank sollte Felder wie diese enthalten:

Name
Status: Todo | InProgress | Complete | Failed
Priorität
CreatedAt
ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId
RetryCount
LastError
CompletedAt

Die wichtigen Felder sind ClaimedAt, ClaimExpiresAt und RunId. Sie machen den Aufgaben-Claim sichtbar und wiederherstellbar.

Hermes-Ausführungszustand

Hermes sollte auch sein eigenes Ausführungsprotokoll führen:

run_id
notion_page_id
started_at
finished_at
status
input_snapshot
tool_calls
result_summary
error
idempotency_key

Dies schützt Sie, falls Notion manuell bearbeitet wird, ein API-Aufruf fehlschlägt oder Sie auditieren müssen, was Hermes tatsächlich getan hat.

Ausführungsablauf

Alle 10 Minuten:
  Hermes-Scheduler erstellt einen Lauf

Hermes-Worker:
  findet eine Notion-Aufgabe, wo Status = Todo
  sortiert nach Priorität und CreatedAt
  beansprucht die Aufgabe, indem er Status = InProgress setzt
  schreibt ClaimedBy, ClaimedAt, ClaimExpiresAt und RunId
  führt die Aufgabe aus
  schreibt Ausführungsprotokolle in das Hermes-Backend
  setzt Notion-Status auf Complete bei Erfolg
  setzt Notion-Status auf Failed bei Fehler

Wenn Hermes nach dem Beantragen einer Aufgabe abstürzt, kann der Lease ablaufen:

Status = InProgress
ClaimExpiresAt < jetzt

Ein zukünftiger Lauf kann dann die Aufgabe wiederherstellen oder als fehlgeschlagen markieren.

Fehlerbehandlung

Bei Erfolg:

Status = Complete
CompletedAt = jetzt
LastError = leer

Bei wiederholbarem Fehler:

Status = Todo
RetryCount = RetryCount + 1
LastError = kurze Fehlermeldung

Bei nicht wiederholbarem Fehler:

Status = Failed
LastError = klare Erklärung

Zur Sicherheit sollte Hermes auch einen Idempotenzschlüssel verwenden:

notion_page_id + task_version + action_type

Dies verhindert, dass dieselbe Aufgabe doppelt ausgeführt wird, wenn ein Wiederholungsversuch zum falschen Zeitpunkt erfolgt.

Warum dies nicht nur Polling ist

Der Polling-Teil ist nur der Aufwachmechanismus. Die echte Architektur ist Aufgaben-Claiming und zuverlässige Ausführung.

Eine naive Implementierung sagt:

Alle 10 Minuten, finde eine Todo-Aufgabe und mache sie.

Eine zuverlässige Implementierung sagt:

Alle 10 Minuten, beanspruche genau eine eligible Aufgabe, protokolliere den Lauf, führe idempotent aus und bewege die Aufgabe in einen terminalen Zustand.

Das ist der Unterschied zwischen einer Demo und einem Agenten, dem Sie vertrauen können.

Häufige Polling-Agent-Fehler

Fehler 1: Kein Claim-Protokoll

Wenn zwei Worker dieselbe Aufgabe sehen können, können sie beide sie ausführen.

Verwenden Sie:

ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId

Selbst wenn Sie aktuell nur einen Worker laufen lassen, designen Sie so, als ob ein zweiter Worker später erscheinen könnte.

Fehler 2: Kein Dedupe-Key

Jede externe Aktion sollte einen Dedupe-Key haben.

user_id + poll_id + source_object_id + action_type + condition_version

Dies verhindert wiederholte Benachrichtigungen, wiederholte E-Mails, wiederholte Aufgabenausführung und wiederholte Tool-Aufrufe. Die breiteren Prinzipien hinter dem Scoping, Speichern und Testen dieser Schlüssel gelten hier gleichermaßen – siehe Idempotency in Distributed Systems That Actually Works.

Fehler 3: Zu frühes Aufrufen des LLM

Fragen Sie das Modell nicht, Datenbankfilterung zu erledigen.

Schlecht:

Senden Sie alle Aufgaben an das LLM und fragen Sie, welche Todo ist.

Besser:

Verwenden Sie den Notion-API-Filter, um Todo-Aufgaben abzurufen.
Verwenden Sie dann das LLM nur, wenn Aufgabeninterpretation benötigt wird.

Fehler 4: Notion als einzigen Backend behandeln

Notion ist eine gute Benutzeroberfläche. Es ist kein vollständiger Ausführungsbackend.

Behalten Sie Ausführungsprotokolle, Wiederholungsversuche, Traces und Idempotenzprotokolle in Hermes.

Fehler 5: Unendliches Polling

Jeder Poll sollte eine Stop-Bedingung haben.

Beispiele:

stoppen nach Erfolg
stoppen nach Datum
stoppen nach maximalen Wiederholungsversuchen
stoppen, wenn Benutzer es deaktiviert
stoppen nach wiederholter Autorisierungsfehler

Ein Polling-Agent ohne Stop-Bedingung ist eine stille Kostenleakage.

Fehler 6: Keine Observability

Sie sollten in der Lage sein zu antworten:

Was hat der Agent ausgeführt?
Warum hat er ausgeführt?
Was hat er gelesen?
Was hat er geändert?
Warum ist er fehlgeschlagen?
Hat er den Benutzer benachrichtigt?
Hat er zweimal ausgeführt?

Wenn Sie diese Fragen nicht beantworten können, ist das System nicht bereit für wichtige Arbeit.

Observability-Checkliste

Verfolgen Sie Metriken wie:

polls_due
polls_started
polls_succeeded
polls_failed
tasks_claimed
tasks_completed
tasks_failed
claim_expired_count
duplicate_suppressed_count
llm_calls
llm_cost
rate_limit_count
average_run_duration

Protokollieren Sie Felder wie:

poll_id
run_id
source_type
source_object_id
claim_id
cursor_before
cursor_after
decision
dedupe_key
error

Erstellen Sie eine Admin-Ansicht für:

aktive Polls
stuck InProgress-Aufgaben
jüngste Fehler
Aufgaben mit hoher Wiederholungsrate
Dead-Letter-Jobs
teure LLM-Auswertungen
deaktivierte Integrationen

Polling-Agenten laufen im Hintergrund, wo Ausfälle leise sind und Probleme sich anhäufen können, bevor jemand es bemerkt. Hintergrundsysteme benötigen von Anfang an eingebauten Sichtbarkeit, nicht als nachträglichen Gedanken, wenn etwas schiefgeht. Für den vollständigen Observability-Stack für KI- und LLM-gestützte Systeme – Metriken, Traces, strukturierte Logs und SLOs – siehe Observability for LLM Systems: Metrics, Traces, Logs, and Testing in Production.

Finale Empfehlung

Polling-Muster handhaben die proaktive Planungsschicht unter einem Multi-Agent-System. Sobald Sie mehrere Agenten haben, die miteinander koordinieren müssen – nicht nur unabhängig pollen – ist die nächste Designentscheidung, wie sie koordinieren: Hub-and-Spoke, Pipeline, Fan-Out oder Swarm. Multi-Agent Orchestration Patterns behandelt diese Koordinations-Topologien mit Ausfallmodi und einem Entscheidungsframework.

Für einen ernsthaften KI-Assistenten beginnen Sie mit warteschlangenbasierten Polling-Workern und einem persistenten Zustandspeicher. Fügen Sie Webhooks hinzu, wo Anbieter sie unterstützen. Verwenden Sie adaptives Polling, wenn Rate-Limits wichtig sind. Verwenden Sie eine persistente Workflow-Engine, wenn der Prozess lang läuft und mehrere Schritte umfasst. Verwenden Sie persistente Agent-Runtime, wenn der Agent über die Zeit hinweg reasonen muss.

Für das Hermes- und Notion-Beispiel ist die richtige Architektur:

Notion als menschenfreundlicher Aufgabenposteingang
Hermes-Scheduler alle 10 Minuten
Hermes-Worker mit Claim- oder Lease-Logik
Hermes-Backend für Ausführungsprotokolle und Idempotenz
Notion-Statusupdates für Sichtbarkeit

Das Polling-Intervall ist nicht der harte Teil. Der harte Teil ist sicherzustellen, dass der Agent eine Aufgabe beansprucht, sie einmal ausführt, protokolliert, was passiert ist, und das System in einem Zustand zurücklässt, den Menschen verstehen können.

Das ist es, was ein Polling-Skript in einen zuverlässigen KI-Assistenten verwandelt – nicht das Intervall, nicht das Modell, sondern die Disziplin beim Claiming von Arbeit, beim Protokollieren und beim Zurücklassen des Systems in einem Zustand, den Menschen und zukünftige Läufe beide verstehen können.