Polling Agents in KI-Assistenten: 11 Implementierungsmuster

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

Ein herkömmlicher Chat-Assistent wartet darauf, dass der Nutzer eine Frage stellt. Ein Polling-Agent (Abfrage-Agent) beobachtet fortlaufend. Er prüft eine Quelle, erkennt Änderungen, entscheidet, ob diese relevant sind, und trifft daraufhin eine Maßnahme. Diese Maßnahme kann eine Benachrichtigung, eine Zusammenfassung, ein Entwurf, ein Tool-Aufruf oder ein vollständiger Workflow sein.

So wandelt sich ein Assistent von „beantworte meine Frage“ zu „halte für mich die Augen offen“. Statt reaktiv zu sein, wird er zu einem Hintergrundprozess, der im Namen des Nutzers Dinge bemerkt und handelt, wenn bestimmte Bedingungen erfüllt sind.

Der wichtige Designpunkt ist einfach: Machen Sie das Sprachmodell nicht für Zeit, Zustand, Wiederholungsversuche oder Sperren verantwortlich. Nutzen Sie dafür herkömmliche Backend-Infrastruktur. Setzen Sie das Modell dort ein, wo es wertvoll ist: bei der Interpretation unstrukturierter Kontexte, semantischer Bewertungen und 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. Im breiteren KI-Systeme-Stack – wo der Assistent ein LLM (Large Language Model), Speicher, Tools, Routing und Observabilität kombiniert – ist die Polling-Schicht das, was den Assistenten proaktiv statt rein reaktiv macht. Für das vollständige Bild der fünf Schichten sehen Sie KI-Assistenten-Architektur: LLM, Speicher, Tools, Routing, Observabilität.

Beispiele:

• Prüfe jeden Morgen den Posteingang und fasse wichtige Nachrichten zusammen.
• Beobachte eine Notion-Aufgabenliste und führe den nächsten Todo-Punkt 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 Lieferantensportal, 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 Wiederholung handeln.

Ein typischer Produktionsablauf sieht wie folgt aus:

Scheduler
  -> Polling-Worker
  -> Quellensystem
  -> 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. Der Gesprächsverlauf reicht nicht aus. Der Assistent mag sich das Gespräch 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": "eine Aufgabe im Todo-Status aufnehmen und ausführen",
  "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, übernehme sie, führe sie aus und markiere sie als Completed.

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 alle 10 Minuten Notion prüft:

interval_seconds: 600
timezone: Australia/Melbourne

Cursor oder Snapshot

Dies hilft dem Agenten, dieselben Daten 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 Aufgabestatus und Claim-Felder. Für Gmail, GitHub oder eine Synchronisierungs-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

Das ist der Unterschied zwischen „Ich hoffe, nur ein Worker nimmt es“ und „das System hat ein Claim-Protokoll“.

Ausführungsprotokoll

Dies zeichnet auf, was während eines Laufs passierte.

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 menschliche Sichtbarkeit. Es ist nicht ideal als einziges Ausführungsprotokoll.

Deduplizierungsprotokoll

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 eine Assistentenaktion aus, falls erforderlich.

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 ist dies oft ausreichend. Ein einzelner Scheduler und ein leichtgewichtiges Worker-Prozess können dutzende tägliche Prüfungen handhaben, 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 Laufzeit
Fehlerzähler
Status

Der Worker sollte zustandslos sein. Er kann temporäre Daten halten, während er läuft, 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 Prüfungen durchführen
  LLM nur bei Bedarf aufrufen
  Zustand aktualisieren
  Assistentenereignis emittieren

Best Fit

Verwenden Sie geplante Polling-Worker für:

• Tägliche Zusammenfassungen.
• Stündliche Prüfungen.
• Kleine interne Automatisierungen.
• Einfache „beobachte dies“-Aufgaben.
• Assistentenjobs mit niedrigem bis mittlerem Volumen.

Schwächen

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

Methode 2: Warteschlangenbasierte Polling-Worker

Warteschlangenbasiertes Polling ist normalerweise der beste Standard für Produktions-KI-Assistenten.

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

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

Wie es läuft

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

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

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, wo next_run_at <= jetzt
  Scheduler legt Jobs in die Warteschlange

Worker:
  zieht Jobs aus der Warteschlange
  sperrt oder mietet den Poll
  fragt die Quelle ab
  aktualisiert den Zustand
  emittiert Assistentenaktion bei Bedarf
  setzt next_run_at

Best Fit

Verwenden Sie warteschlangenbasiertes Polling für:

• KI-Assistenten mit mehreren Benutzern.
• Viele gleichzeitige Polls.
• Integrationen mit Ratenlimits.
• 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 übertrieben für einen kleinen Prototyp.

Methode 3: Externes Tool als Aufgabenwarteschlange

Dies ist das Muster im Notion-plus-Hermes-Beispiel.

Das externe Tool ist nicht nur eine Datenquelle. Es wird zur menschenfreundlichen Aufgabenwarteschlange. Der Agent prüft periodisch das Tool, übernimmt eine Aufgabe, führt sie aus und aktualisiert den Aufgabestatus.

Scheduler
  -> Hermes-Worker
  -> Notion-Datenbank
  -> eine Aufgabe übernehmen
  -> 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 übernimmt 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 zu Todo mit einem Wiederholungszähler 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 Trennung ist wichtig. Notion ist hervorragend für Sichtbarkeit und manuelle Bearbeitung. Das Hermes-Backend ist besser für Logs, Wiederholungen, Deduplizierung und Audit-Historie.

Beispielablauf

Alle 10 Minuten:
  Hermes wacht auf

Hermes:
  fragt Notion nach einer Aufgabe ab, wo Status = Todo
  sortiert nach Priorität, CreatedAt
  aktualisiert ausgewählte Aufgabe zu InProgress
  setzt ClaimedBy, ClaimedAt, ClaimExpiresAt, RunId
  führt die Aufgabe aus
  schreibt Ausführungslog
  setzt Aufgabe auf Complete oder Failed

Best Fit

Verwenden Sie dieses Muster, wenn:

• Menschen bereits Arbeit 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. Abfragekonsistenz kann verzögert sein. Ratenlimits 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ührungslogs, Wiederholungsprotokolle, Traces und Idempotenz-Schlüssel in Hermes bleiben. Notion gibt Benutzern Sichtbarkeit; Hermes hält das System zuverlässig. Für die Dispatcher- und Konkurzenzmechaniken, die sich hinter diesem Muster in Hermes befinden, sehen Sie Kanban im Hermes-Agent für selbst gehostete LLM-Workflows.

Methode 4: Lang laufende Worker-Schleife

Eine lang laufende Schleife 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 einfachsten möglichen Ausgangspunkt für Hintergrundagentenarbeit 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 immer noch persistenten Zustand:

Poll-Konfiguration
next_run_at
cursor
last result
failure count
status

Der Prozessspeicher sollte nur temporären Zustand enthalten:

aktueller Batch
kurzlebiger Cache
in-flight run

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

Best Fit

Verwenden Sie lang laufende Schleifen für:

• Prototypen.
• Lokale Entwicklung.
• Interne Tools.
• Single-Tenant-Systeme.
• Agenten mit niedrigem Volumen.

Schwächen

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

Eine lang laufende Schleife ist nicht falsch als Ausgangspunkt, aber sie 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 strukturierten Muster oben wechseln.

Methode 5: Webhook-First mit Polling-Fallback

Wenn die Quelle Webhooks unterstützt, verwenden Sie sie. Polling sollte oft die Backup-Lösung sein, nicht der primäre Mechanismus.

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

Rekonkiliations-Poll
  -> Quell-API
  -> vergleichen mit Ereignisspeicher
  -> verpasste Ereignisse reparieren

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 Rekonkiliations-Poll läuft alle paar Stunden oder einmal täglich. Er prüft, ob Ereignisse verpasst wurden.

Zustandsmodell

Der Ereignisspeicher zeichnet eingehende Webhooks auf:

event_id
source_type
source_object_id
event_type
received_at
payload_hash
processed_at
signature_valid

Der Rekonkiliations-Poll speichert:

last_reconciliation_at
last_seen_cursor
last_seen_version

Die Quell-Objekt-Tabelle speichert den neuesten bekannten Zustand:

external_id
current_status
external_updated_at
last_processed_event_id

Best Fit

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 Ereignisdeduplizierung. Einige Anbieter senden auch unvollständige Ereignisse, sodass Sie möglicherweise trotzdem das vollständige Objekt abrufen müssen.

Trotzdem: Wenn gute Webhooks existieren, ist Polling jede Minute normalerweise verschwenderisch.

Methode 6: Anbieterseitiges Hintergrundjob-Polling

Manchmal ist das, was gepollt wird, der KI-Job selbst.

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

App
  -> KI-Hintergrundjob starten
  -> Anbieter-Job-ID speichern
  -> Status pollen
  -> 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 zeitüberschreitet.

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 Jobzustand 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. Anbieterseitige Ergebnisspeicherung hat kurze Aufbewahrungszeiten und ist kein Ersatz für ein ordnungsgemäßes Archiv in Ihrem eigenen System.

Best Fit

Verwenden Sie anbieterseitiges Hintergrundjob-Polling für:

• Lange KI-Forschungsaufgaben.
• Verarbeitung großer Dokumente.
• Codebasis-Analyse.
• Berichterstellung.
• Datenextraktionsjobs.
• Aufgaben, die normale HTTP-Anforderungs-Timeouts überschreiten.

Schwächen

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

Methode 7: Dauerhafte Workflow-Engine

Eine dauerhafte Workflow-Engine verwaltet lang laufende Ausführung, Timer, Wiederholungen und Wiederherstellung. Temporal ist die häufigste Wahl für Go- und Python-basierte Assistenten-Backends; für eine vollständige Implementierungsanleitung sehen Sie Implementierung von Workflow-Anwendungen mit Temporal in Go.

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

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

Wie es läuft

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

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 Prozesszustand – Ausführungshistorie, Timer, Wiederholungen und Aktivitätsversuche. Ihre Datenbank besitzt Geschäftszustand – Benutzerkonfigurationen, Autorisierungsprotokolle, Benachrichtigungen und Audit-Logs. Das Trennen dieser Schichten verhindert, dass jede Schicht zu einem verwirrten Hybrid aus beidem wird.

Best Fit

Verwenden Sie dauerhafte Workflows für:

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

Schwächen

Workflow-Engines fügen Konzepte und Infrastruktur hinzu. Sie sind hervorragend, wenn der Prozess wichtig ist, aber schwer für einfache stündliche Prüfungen.

Methode 8: Persistenter Agenten-Runtime

Einige Agenten-Frameworks können Agentenzustand persistieren, Ausführung checkpointen und später fortsetzen.

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

Scheduler oder Workflow
  -> Agenten-Runtime
  -> Checkpoint laden
  -> Tools aufrufen
  -> Checkpoint speichern
  -> später fortsetzen

Wie es läuft

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

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

Zustandsmodell

Agenten-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 immer noch woanders hin:

poll schedule
cursor
status
retry count
dedupe records

Eine nützliche Regel: Speicher ist kein Cursor, und ein Checkpoint ist keine Warteschlange. Agentenspeicher speichert, was das Modell weiß; operativer Zustand verfolgt, wo der Prozess ist und was er 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 Arbeitspeicher, persistenten Zustand und Retrieval-Schichten wird in Speichersysteme in KI-Assistenten abgedeckt.

Best Fit

Verwenden Sie persistente Agenten-Runtime für:

• Mehrstufige Forschung.
• Agenten, die pausieren und fortsetzen.
• Human-in-the-Loop-Arbeit.
• Tool-lastiges Reasoning.
• Aufgaben, bei denen Kontext im Laufe der Zeit anwächst.

Schwächen

Agenten-Persistenz ist nicht dasselbe wie operative Zuverlässigkeit. Sie benötigen immer noch Planung, Sperren, Wiederholungen, Ratenlimits und Audit-Logs.

Methode 9: Datenbanksynchronisation plus Änderungsbewertung

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 Bewertungszyklus externe APIs direkt abzufragen.

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

Dies trennt Datensynchronisation von Assistentenintelligenz. Der Sync-Worker ist dafür verantwortlich, lokale Datensätze aktuell zu halten; der Bewerter 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 ruft periodisch externe Änderungen ab und schreibt normalisierte Datensätze in Ihre Datenbank. Ein zweiter Worker oder Change Stream 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 Assistentenbewertungstabelle speichert:

object_id
evaluation_status
last_evaluated_hash
decision
notification_id

Best Fit

Verwenden Sie dieses Muster für:

• CRM-Synchronisation.
• Ticketing-Systeme.
• Buchhaltungsunterlagen.
• Produktinventar.
• Compliance-Prü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 über eine einzelne Assistentenaktion hinaus haben.

Methode 10: Adaptives Polling

Adaptives Polling ändert die Frequenz basierend auf Zustand, Dringlichkeit oder letzter Aktivität.

aktives Objekt: pollen alle 1 Minute
wartendes Objekt: pollen alle 1 Stunde
veraltetes Objekt: pollen einmal pro Tag
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

Best Fit

Verwenden Sie adaptives Polling für:

• Bereitstellungsstatus.
• Sendungsverfolgung.
• Kalenderplatzverfügbarkeit.
• Preisüberwachung.
• Build-Jobs.
• Lang laufende Anbieteraufgaben.
• Jede Quelle mit burstigen Updates.

Schwächen

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

Methode 11: Semantisches Polling mit einem LLM-Bewerter

Semantisches Polling wird verwendet, wenn die Bedingung ungenau ist.

Code kann beantworten:

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

Ein LLM kann helfen zu beantworten:

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 günstige deterministische Filter an. Nur Kandidatenelemente gehen zum LLM.

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

Dann bewertet der LLM die kleinere Kandidatensammlung 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 Bewertungsprotokoll 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

Best Fit

Verwenden Sie semantisches Polling für:

• Erkennung wichtiger E-Mails.
• Überwachung der Kundenstimmung.
• Forschungsalarme.
• Erkennung von Verkaufschancen.
• Sicherheitstriage.
• Executive-Briefings.

Schwächen

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

Entscheidungstabelle: Wahl einer Polling-Agenten-Methode

Empfohlene Standardarchitektur

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

polls table
  -> scheduler
  -> queue
  -> stateless workers
  -> deterministic filters
  -> optional LLM evaluator
  -> notification or assistant action

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 owns time
queue owns buffering
worker owns execution
database owns state
LLM owns semantic judgment
assistant owns user interaction

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.

Angenommen, eine Notion-Datenbank enthält Aufgaben. Hermes sollte alle 10 Minuten laufen, eine Aufgabe im Zustand Todo aufnehmen, 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-Aufgabeneigenschaften

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 Aufgabenclass sichtbar und wiederherstellbar.

Hermes-Ausführungszustand

Hermes sollte auch sein eigenes Ausführungsprotokoll behalten:

run_id
notion_page_id
started_at
finished_at
status
input_snapshot
tool_calls
result_summary
error
idempotency_key

Dies schützt Sie, wenn Notion manuell bearbeitet wird, wenn ein API-Aufruf fehlschlägt oder wenn Sie prüfen 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
  übernimmt die Aufgabe, indem er Status = InProgress setzt
  schreibt ClaimedBy, ClaimedAt, ClaimExpiresAt und RunId
  führt die Aufgabe aus
  schreibt Ausführungslogs zum Hermes-Backend
  setzt Notion-Status auf Complete bei Erfolg
  setzt Notion-Status auf Failed bei Fehler

Wenn Hermes nach dem Übernehmen einer Aufgabe abstürzt, kann die Miete ablaufen:

Status = InProgress
ClaimExpiresAt < jetzt

Ein zukünftiger Lauf kann dann die Aufgabe wiederherstellen oder sie 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 Idempotenz-Schlüssel verwenden:

notion_page_id + task_version + action_type

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

Warum dies nicht nur Polling ist

Der Polling-Teil ist nur der Aufweckmechanismus. Die echte Architektur ist Aufgabenübernahme 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, übernimm genau eine geeignete Aufgabe, protokolliere den Lauf, führe idempotent aus und bewege die Aufgabe in einen Endzustand.

Das ist der Unterschied zwischen einer Demo und einem Agenten, dem man vertrauen kann.

Häufige Polling-Agenten-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 ausführen, entwerfen Sie so, als ob ein zweiter Worker später erscheinen könnte.

Fehler 2: Kein Deduplizierungsschlüssel

Jede externe Aktion sollte einen Deduplizierungsschlüssel 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 – sehen Sie Idempotenz in verteilten Systemen, die tatsächlich funktioniert.

Fehler 3: LLM zu früh aufrufen

Fragen Sie das Modell nicht, Datenbankfilterung zu machen.

Schlecht:

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

Besser:

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

Fehler 4: Notion als einzigen Backend behandeln

Notion ist eine gute menschliche Schnittstelle. Es ist kein vollständiger Ausführungsbackend.

Behalten Sie Ausführungslogs, Wiederholungen, Traces und Idempotenz-Protokolle in Hermes.

Fehler 5: Unendliches Polling

Jeder Poll sollte eine Stop-Bedingung haben.

Beispiele:

stop after success
stop after date
stop after max retries
stop when user disables it
stop after repeated authorization failure

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

Fehler 6: Keine Observabilität

Sie sollten in der Lage sein zu beantworten:

What did the agent run?
Why did it run?
What did it read?
What did it change?
Why did it fail?
Did it notify the user?
Did it run twice?

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

Observabilitäts-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

Loggen 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:

active polls
stuck InProgress tasks
recent failures
high retry tasks
dead letter jobs
expensive LLM evaluations
disabled integrations

Polling-Agenten laufen im Hintergrund, wo Fehler leise sind und Probleme sich anhäufen können, bevor jemand es bemerkt. Hintergrundsysteme benötigen von Anfang an eingebaute Sichtbarkeit, nicht als nachträglichen Gedanken, wenn etwas schiefgeht. Für den vollständigen Observabilitäts-Stack für KI- und LLM-gestützte Systeme – Metriken, Traces, strukturierte Logs und SLOs – sehen Sie Observabilität für LLM-Systeme: Metriken, Traces, Logs und Testing in Production.

Finale Empfehlung

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 Ratenlimits wichtig sind. Verwenden Sie eine dauerhafte Workflow-Engine, wenn der Prozess lang läuft und mehrstufig ist. Verwenden Sie persistente Agenten-Runtime, wenn der Agent im Laufe der Zeit reasonieren 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ührungslogs 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 übernimmt, sie einmal ausführt, aufzeichnet, was passierte, und das System in einem Zustand lä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 Übernehmen von Arbeit, beim Aufzeichnen und beim Verlassen des Systems in einem Zustand, den Menschen und zukünftige Läufe beide verstehen können.