Polling Agents in AI-assistenten: 11 implementatiepatronen

Pollende agents behoren tot de minst glamourrijze onderdelen van de architectuur van AI-assistents, maar ze zijn ook een van de meest nuttige.

Een normale chat-assistent wacht tot de gebruiker iets vraagt. Een pollende agent blijft toekijken. Hij controleert een bron, merkt veranderingen op, beslist of dit van belang is en treedt vervolgens op. Deze actie kan een melding, een samenvatting, een concept, een tool-oproep of een volledige workflow zijn.

Zo verandert een assistent van “beantwoord mijn vraag” naar “houd dit voor mij in de gaten”. In plaats van reactief te zijn, wordt het een achtergrondproces dat dingen namens de gebruiker opmerkt en optreedt wanneer aan bepaalde voorwaarden wordt voldaan.

Het belangrijke ontwerppunt is simpel: laat het taalmodel niet verantwoordelijk zijn voor tijd, status, opnieuw proberen of vergrendeling. Gebruik daar normale backend-infrastructuur voor. Gebruik het model waar het waardevol is: het interpreteren van rommelige context, het maken van semantische oordelen en het produceren van nuttige taal.

Wat is een pollende agent?

Een pollende agent is een achtergrondproces dat herhaaldelijk een bron controleert en een actie van de assistent activeert wanneer een voorwaarde wordt voldaan. In de bredere AI-systemen stack — waarbij de assistent een LLM, geheugen, gereedschap, routing en observabiliteit combineert — is de polling-laag wat de assistent proactief maakt in plaats van puur reactief. Zie voor het volledige vijf-laags overzicht AI-assistentarchitectuur: LLM, geheugen, tools, routing, observabiliteit.

Voorbeelden:

• Controleer elke ochtend een inbox en vat belangrijke berichten samen.
• Houd een Notion-taaklijst in de gaten en voer de volgende todo-item uit.
• Monitor een GitHub-issue totdat de status verandert.
• Poll een langlopende AI-job totdat het resultaat klaar is.
• Controleer een boekingslot totdat er een beschikbaar is.
• Houd een leveranciersportaal in de gaten totdat een document verschijnt.
• Scan wekelijks nieuwe onderzoeksartikelen en vat de relevante samen.

Een praktische pollende agent heeft vijf verantwoordelijkheden:

1. Op het juiste moment wakker worden.
2. Uit de bron lezen.
3. Onthouden wat er al is gezien.
4. Beslissen of de nieuwe status van belang is.
5. Eenmaal, veilig en zonder zichzelf te herhalen, handelen.

Een typische productiestroom ziet er als volgt uit:

planner
  -> pollende worker
  -> bronsysteem
  -> opslag voor status
  -> deterministische filters
  -> optionele LLM-evaluatie
  -> assistentactie

Deze structuur is op de beste mogelijke manier saai. Saai systemen zijn makkelijker te debuggen om 2 uur ’s nachts.

De status die elke pollende agent nodig heeft

Pollende agents hebben duurzame status nodig. Conversatiegeschiedenis is niet genoeg. De assistent kan het gesprek onthouden, maar het systeem heeft een betrouwbare operationele registratie nodig.

Een goede statusregistratie voor polling bevat meestal:

{
  "poll_id": "poll_123",
  "user_id": "user_456",
  "source_type": "notion",
  "source_ref": "database_tasks",
  "condition": "neem één taak in Todo-status en voer deze uit",
  "interval_seconds": 600,
  "last_run_at": "2026-06-19T01:00:00Z",
  "next_run_at": "2026-06-19T01:10:00Z",
  "last_seen_cursor": "cursor_of_tijdstip",
  "last_result_hash": "b64e8a...",
  "failure_count": 0,
  "status": "actief"
}

Het exacte schema hangt af van de bron, maar de meeste systemen hebben deze concepten nodig.

Poll-definitie

Dit beschrijft wat de agent bewaakt en waarom.

poll_id
user_id
workspace_id
source_type
source_ref
condition_text
priority
status

Bijvoorbeeld:

source_type: notion
source_ref: Taken-database
condition_text: Zoek een Todo-taak, claim deze, voer deze uit en markeer deze als Voltooid.

Planning

Dit beschrijft wanneer de agent moet draaien.

interval_seconds
cron_expression
timezone
last_run_at
next_run_at
jitter

Voor een Hermes-agent die elke 10 minuten Notion controleert:

interval_seconds: 600
timezone: Australia/Melbourne

Cursor of snapshot

Dit helpt de agent om te voorkomen dat dezelfde gegevens opnieuw worden verwerkt.

Afhankelijk van de bron kan dit zijn:

last_seen_id
last_seen_timestamp
api_cursor
etag
version
content_hash

Voor een Notion-taakwachtrij is de cursor minder belangrijk dan taakstatus en claimvelden. Voor Gmail, GitHub of een synchronisatie-API is de cursor meestal cruciaal.

Claim of lease

Dit voorkomt dat twee workers dezelfde job aanpakken.

claimed_by
claimed_at
claim_expires_at
run_id

Bijvoorbeeld, een Notion-taak kan worden gewijzigd van:

Status: Todo

naar:

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

Dit is het verschil tussen “Ik hoop dat slechts één worker het oppakt” en “het systeem heeft een claimprotocol”.

Uitvoeringsregistratie

Dit registreert wat er tijdens een run is gebeurd.

run_id
poll_id
source_object_id
started_at
finished_at
status
items_checked
items_changed
decision_summary
error

De uitvoeringsregistratie moet in de backend van de assistent leven, niet alleen in Notion of een ander extern hulpmiddel. Notion is goed voor menselijke zichtbaarheid. Het is niet ideaal als je enige uitvoeringslogboek.

Dedupe-registratie

Dit voorkomt dubbele meldingen of herhaalde acties.

dedupe_key
poll_id
source_object_id
condition_version
action_type
delivered_at

Bijvoorbeeld:

user_456:poll_123:notion_page_999:execute:v1

Als dezelfde actie opnieuw wordt geprobeerd, kan het systeem deze onderdrukken.

Methode 1: Gepoldeerde pollende worker

Dit is het eenvoudigste betrouwbare patroon.

Een planner wordt elke vaste interval wakker en roept een worker aan. De worker leest de bron, werkt de status bij en activeert een assistentactie indien nodig.

planner
  -> worker
  -> bron-API
  -> database
  -> assistentactie

Hoe het werkt

De planner is verantwoordelijk voor de tijd. Het kan cron zijn, een cloudplanner, een Kubernetes CronJob of een kleine interne planner.

Elke interval start hij een worker-run. De worker laadt zijn configuratie, queryt de doelbron, vergelijkt het resultaat met de opgeslagen status en treedt op indien nodig.

Voor een eenvoudige assistent is dit vaak voldoende. Een enkele planner en een lichtgewicht workerproces kunnen tientallen dagelijkse controles afhandelen zonder dat wachtrijen, leases of gedistribueerde coördinatie nodig zijn.

Statusmodel

De planner slaat weinig op. Meestal weet hij alleen wanneer hij een job moet triggeren.

De applicatiedatabase bewaart de belangrijke status:

poll-definitie
planning
cursor of snapshot
laatste run-tijd
aantal fouten
status

De worker moet stateless zijn. Hij kan tijdelijke gegevens bevatten tijdens het draaien, maar de duurzame waarheid hoort in de database.

Voorbeeldstroom

Elke 10 minuten:
  trigger Hermes pollende worker

Worker:
  laadt actieve poll-configuratie
  queryt bron
  vergelijkt met vorige status
  voert deterministische controles uit
  roept LLM alleen aan indien nodig
  werkt status bij
  zendt assistentgebeurtenis uit

Beste toepassing

Gebruik gepoldeerde pollende workers voor:

• Dagelijkse samenvattingen.
• Uurtelijke controles.
• Kleine interne automatiseringen.
• Eenvoudige “houd dit in de gaten”-taken.
• Assistentaakjes met laag tot medium volume.

Zwakke punten

Gepoldeerde polling is makkelijk te begrijpen, maar kan kwetsbaar worden bij schaal. Als veel polls tegelijk draaien, kun je je workers overbelasten of tegen rate limits van providers aanlopen. Opnieuw proberen kan ook rommelig worden als de planner het werk direct start.

Methode 2: Wachtrijgebaseerde pollende workers

Wachtrijgebaseerde polling is meestal de beste standaard voor productie-AI-assistents.

De planner voert de poll niet direct uit. Hij zet een job op een wachtrij. Workerprocessen consumeren jobs uit de wachtrij.

planner
  -> wachtrij
  -> worker-pool
  -> bron-API
  -> opslag voor status
  -> assistentactie

Hoe het werkt

Een planner scant op polls die aan de beurt zijn en voegt jobs toe aan de wachtrij. Workers halen jobs op wanneer ze capaciteit hebben.

Dit geeft je backpressure. Als het systeem druk is, wachten jobs in de wachtrij in plaats van de bron-API of de LLM-provider over te laden.

Statusmodel

De database bewaart de poll-status:

poll_id
user_id
source_ref
condition_text
next_run_at
cursor
status
failure_count

Het wachtrijbericht moet klein blijven:

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

De worker laadt de volledige status uit de database wanneer hij start.

Voorbeeldstroom

Elke minuut:
  planner vindt polls waarbij next_run_at <= nu
  planner voegt jobs toe aan wachtrij

Workers:
  halen jobs uit wachtrij
  vergrendelen of leasen van de poll
  queryt de bron
  werkt status bij
  zendt assistentactie uit indien nodig
  stelt next_run_at in

Beste toepassing

Gebruik wachtrijgebaseerde polling voor:

• AI-assistents met meerdere gebruikers.
• Veel gelijktijdige polls.
• Integraties met rate limits.
• Opnieuw te proberen achtergrondwerk.
• Jobs die verschillende hoeveelheden tijd kunnen kosten.
• SaaS-producten waarbij betrouwbaarheid belangrijk is.

Zwakke punten

Wachtrijen voegen infrastructuur toe. Je hebt Dead Letter-handling, idempotentie, zichtbaarheidstijdsduren en retry-beleid nodig. Dit is het waard voor productsystemen, maar waarschijnlijk overkill voor een klein prototype.

Methode 3: Extern hulpmiddel als taakwachtrij

Dit is het patroon in het Notion-plus-Hermes-voorbeeld.

Het externe hulpmiddel is niet alleen een databron. Het wordt de voor mensen zichtbare taakwachtrij. De agent controleert periodiek het hulpmiddel, claimt één taak, voert deze uit en werkt de taakstatus bij.

planner
  -> Hermes worker
  -> Notion-database
  -> claim één taak
  -> voer taak uit
  -> werk Notion-status bij

Hoe het werkt

Elke 10 minuten queryt Hermes de Notion-database voor één taak in Todo-status. Hij kiest de volgende taak, meestal op basis van prioriteit en creatietijd. Vervolgens claimt hij de taak door deze op InProgress te zetten.

Daarna voert Hermes de taak uit. Als de uitvoering slaagt, markeert hij de taak als Complete. Als de uitvoering faalt, markeert hij de taak als Failed of brengt hij deze terug naar Todo met een retry-teller.

Statusmodel

Notion bewaart de voor mensen zichtbare taakstatus:

Titel
Beschrijving
Status: Todo | InProgress | Complete | Failed
Prioriteit
CreatedAt
ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId
RetryCount
LastError
CompletedAt

Hermes-backend bewaart de operationele uitvoeringsstatus:

run_id
notion_page_id
started_at
finished_at
execution_status
tool_calls
LLM-trace
foutdetails
idempotency_key

Deze splitsing is belangrijk. Notion is uitstekend voor zichtbaarheid en handmatig bewerken. Hermes-backend is beter voor logs, opnieuw proberen, deduping en auditgeschiedenis.

Voorbeeldstroom

Elke 10 minuten:
  Hermes wordt wakker

Hermes:
  queryt Notion voor één taak waarbij Status = Todo
  sorteer op Prioriteit, CreatedAt
  werkt geselecteerde taak bij naar InProgress
  stelt ClaimedBy, ClaimedAt, ClaimExpiresAt, RunId in
  voert de taak uit
  schrijft uitvoeringslogboek
  stelt taak in op Complete of Failed

Beste toepassing

Gebruik dit patroon wanneer:

• Mensen al werk beheren in Notion, Jira, Linear, Trello of een ander hulpmiddel.
• Je wilt dat de assistent zichtbare taken verwerkt.
• Het taskboard de gebruikersinterface is.
• Je een eenvoudig human-in-the-loop-automatiseringsmodel nodig hebt.

Zwakke punten

Externe hulpmiddelen zijn zelden perfecte wachtrijen. Atomics claims kunnen beperkt zijn. Queryconsistentie kan achterlopen. Rate limits kunnen van toepassing zijn. Als de agent in meerdere instanties kan draaien, heb je een zorgvuldige claim- of lease-strategie nodig.

De praktische aanbeveling is om Notion te gebruiken als de voor mensen zichtbare taakinbox, terwijl alle uitvoeringslogs, retry-registraties, traces en idempotentie-sleutels in Hermes blijven. Notion geeft gebruikers zichtbaarheid; Hermes houdt het systeem betrouwbaar. Zie voor de dispatcher- en concurrentiemechanica die achter dit patroon in Hermes zitten Kanban in Hermes Agent voor zelfgehoste LLM-workflows.

Methode 4: Langlopende worker-loop

Een langlopende loop is de eenvoudigste implementatie.

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

Dit patroon combineert planning en uitvoering in één service, wat het het eenvoudigste mogelijke startpunt maakt voor achtergrondagentwerk.

Hoe het werkt

Het workerproces draait continu. Elke paar seconden of minuten controleert het de database op polls die aan de beurt zijn en voert deze uit. Het is makkelijk te bouwen, makkelijk te begrijpen en snel te itereren tijdens ontwikkeling.

Statusmodel

De database bewaart nog steeds duurzame status:

poll-configuratie
next_run_at
cursor
laatste resultaat
aantal fouten
status

Het procesgeheugen moet alleen tijdelijke status bevatten:

huidige batch
kortlevende cache
in-flight run

Bewaar belangrijke voortgang nooit alleen in het geheugen. Als het proces crasht, is elke status die niet naar duurzame opslag is geschreven weg, en heeft de volgende run geen manier om te weten waar het is blijven zitten.

Beste toepassing

Gebruik langlopende loops voor:

• Prototypes.
• Lokale ontwikkeling.
• Interne tools.
• Single-tenant-systemen.
• Agents met laag volume.

Zwakke punten

Dit patroon wordt riskant met meerdere replicaten. Zonder leases kunnen twee workers dezelfde poll uitvoeren. Het mist ook de operationele functies van een echte wachtrij of workflow-engine.

Een langlopende loop is niet verkeerd als startpunt, maar het is geen gedistribueerde planner en mag niet als zodanig worden behandeld. Zodra je meerdere replicaten of sterkere betrouwbaarheids garanties nodig hebt, zul je moeten overstappen naar een van de gestructureerdere patronen hierboven.

Methode 5: Webhook-first met polling als fallback

Als de bron webhooks ondersteunt, gebruik ze dan. Polling zou vaak de backup moeten zijn, niet het primaire mechanisme. Dezelfde splitsing verschijnt in agentprotocolontwerp: A2A-pushmeldingen wekken een client-handler wakker, die vervolgens GetTask polt voor volledige status, zoals beschreven in A2A-streaming en asynche taken voor langlopende agentworkflows.

extern systeem
  -> webhook-eindpunt
  -> gebeurtenisopslag
  -> assistentactie

herstelpoll
  -> bron-API
  -> vergelijk met gebeurtenisopslag
  -> repareer gemiste gebeurtenissen

Hoe het werkt

Het externe systeem stuurt gebeurtenissen naar je webhook-eindpunt als er iets verandert. Je systeem bewaart de gebeurtenis en verwerkt deze asynchroon.

Een langzamere herstelpoll draait elke paar uur of een keer per dag. Hij controleert of er gebeurtenissen zijn gemist.

Statusmodel

De gebeurtenisopslag registreert inkomende webhooks:

event_id
source_type
source_object_id
event_type
received_at
payload_hash
processed_at
signature_valid

De herstelpoll bewaart:

last_reconciliation_at
last_seen_cursor
last_seen_version

De bronobjecttabel bewaart de laatst bekende status:

external_id
current_status
external_updated_at
last_processed_event_id

Beste toepassing

Gebruik webhook-first-architectuur voor:

• GitHub-gebeurtenissen.
• Stripe-gebeurtenissen.
• Slack-gebeurtenissen.
• CRM-updates.
• Deployeringsmeldingen.
• Ticketingsystemen.

Zwakke punten

Webhooks vereisen een publiek eindpunt, signatuurvalidatie, replay-bescherming en gebeurtenisdeduping. Sommige providers sturen ook onvolledige gebeurtenissen, dus je moet mogelijk nog steeds het volledige object ophalen.

Toch is polling elke minuut meestal verspilling als goede webhooks bestaan.

Methode 6: Provider-gebaseerde achtergrondjobpolling

Soms is hetgeen dat wordt gepolld de AI-job zelf.

De applicatie start een langlopende providerjob, bewaart de job-ID en controleert later of deze is voltooid.

app
  -> start AI-achtergrondjob
  -> bewaar provider-job-ID
  -> poll status
  -> haal resultaat op
  -> meld gebruiker

Hoe het werkt

De assistent start een job bij de provider. De provider retourneert een ID. Je backend bewaart die ID en controleert de status totdat de job slaagt, faalt, verloopt of time-out geeft.

Statusmodel

Je backend bewaart:

assistant_task_id
provider_job_id
user_id
status
created_at
last_checked_at
expires_at
result_ref

De provider bewaart de tijdelijke jobstatus en -output.

Als de output belangrijk is, kopieer deze dan zo snel mogelijk naar je eigen duurzame opslag zodra de job is voltooid. Provider-gebaseerde resultaatopslag heeft korte retentievensters en is geen vervanging voor een juiste archief in je eigen systeem.

Beste toepassing

Gebruik provider-gebaseerde achtergrondjobpolling voor:

• Lange AI-onderzoekstaken.
• Grote documentverwerking.
• Codebase-analyse.
• Rapportgeneratie.
• Data-extractiejobs.
• Taken die normale HTTP-aanvraagtijdsduren overschrijden.

Zwakke punten

Dit patroon lost één probleem op: wachten op een lange providerjob. Het vervangt niet je workflow-engine, planner, wachtrij of business-statusopslag.

Methode 7: Duurzame workflow-engine

Een duurzame workflow-engine beheert langlopende uitvoering, timers, opnieuw proberen en herstel. Temporal is de meest voorkomende keuze voor Go- en Python-gebaseerde assistantbackends; zie voor een volledige implementatiegids Implementeren van workflow-applicaties met Temporal in Go.

In plaats van elke wachtpauze en retry handmatig te bedraden, modelleer je het proces als een workflow.

workflow-engine
  -> activiteit: controleer bron
  -> timer: wacht
  -> activiteit: evalueer resultaat
  -> activiteit: meld gebruiker

Hoe het werkt

De workflow start eenmaal en controleert vervolgens zijn eigen wachten. Hij kan minuten, dagen of weken slapen. Als het workerproces crasht, kan de workflow-engine hervatten vanuit de geregistreerde status.

Statusmodel

De workflow-engine bewaart:

workflow_id
executiegeschiedenis
timerstatus
activiteitspogingen
retry-beleid
huidige workflowstatus

Je applicatiedatabase bewaart:

voor mensen zichtbare poll-definitie
autorisatiereferenties
businessregistraties
meldingsregistraties

De workflow-engine bezit processtatus — uitvoeringsgeschiedenis, timers, opnieuw proberen en activiteitspogingen. Je database bezit businessstatus — gebruikersconfiguraties, autorisatieregistraties, meldingen en auditlogs. Het apart houden van deze lagen voorkomt dat elke laag een verwarde hybride van beide wordt.

Beste toepassing

Gebruik duurzame workflows voor:

• Multi-step businessprocessen.
• Langlopende automatiseringen.
• Menselijke goedkeuringsstromen.
• Betrouwbare retries.
• Auditabele achtergrondwerkzaamheden.
• Processen die na een storing moeten worden hervat.

Zwakke punten

Workflow-engines voegen concepten en infrastructuur toe. Ze zijn uitstekend wanneer het proces belangrijk is, maar zwaar voor eenvoudige uurtelijke controles.

Methode 8: Persistente agentruntime

Sommige agentframeworks kunnen agentstatus persistent maken, uitvoering checkpointen en later hervatten.

Dit is nuttig wanneer de agent zelf een multi-step redeneringsproces heeft.

planner of workflow
  -> agentruntime
  -> laad checkpoint
  -> roep tools aan
  -> sla checkpoint op
  -> hervat later

Hoe het werkt

Een externe planner of workflow start de agent. De agentruntime laadt vorige status, voert de volgende stap uit, roept tools aan indien nodig en schrijft een checkpoint.

De agentruntime mag niet je enige planner zijn. Hij is beter te behandelen als de redeneringslaag binnen een grotere backendarchitectuur.

Statusmodel

Agentcheckpointopslag bevat:

huidige node
berichten
tool-outputs
intermediare redeneringsstatus
pending actie

Langdurig geheugen bevat:

stabiele gebruikersvoorkeuren
feiten
projectcontext
bronreferenties

Operationele status hoort nog steeds elders:

poll-planning
cursor
status
retry-aantal
dedupe-registraties

Een nuttige regel: geheugen is geen cursor, en een checkpoint is geen wachtrij. Agentgeheugen bewaart wat het model weet; operationele status bijhoudt waar het proces is en wat het heeft gedaan. Het vermengen van de twee leidt tot subtiele bugs die pas bij concurrentie of na een restart verschijnen. De volledige ontwerpruimte voor werkgeheugen, duurzame status en ophaallagen is te vinden in Geheugensystemen in AI-assistents.

Beste toepassing

Gebruik persistente agentruntime voor:

• Multi-step onderzoek.
• Agents die pauzeren en hervatten.
• Human-in-the-loop-werk.
• Tool-zware redenering.
• Taken waarbij context door de tijd heen accumuleert.

Zwakke punten

Agentpersistentie is niet hetzelfde als operationele betrouwbaarheid. Je hebt nog steeds planning, vergrendeling, opnieuw proberen, rate limits en auditlogs nodig.

Methode 9: Databasesynchronisatie plus waningevaluatie

In dit patroon wordt polling gebruikt om externe data te synchroniseren met je eigen database. De assistent reageert vervolgens op lokale databaseveranderingen in plaats van externe API’s direct te queryen tijdens elke evaluatiecyclus.

sync-poller
  -> externe API
  -> lokale database
  -> waningevaluatie
  -> assistentactie

Dit scheidt datasynchronisatie van assistentintelligentie. De sync-worker is verantwoordelijk voor het actueel houden van lokale records; de evaluator is verantwoordelijk voor het beslissen wat er met veranderingen moet gebeuren. Elke laag kan onafhankelijk worden getest, gemonitord en geschaald.

Hoe het werkt

De sync-worker haalt periodiek externe veranderingen op en schrijft genormaliseerde records in je database. Een tweede worker of changestream detecteert bijgewerkte rijen en beslist of de assistent moet optreden.

Statusmodel

De synctabel bewaart:

external_id
source_type
raw_payload
normalized_fields
external_updated_at
synced_at
version
content_hash

De syncstatus bewaart:

source_cursor
last_sync_at
rate_limit_status
failure_count

De assistentevaluatietabel bewaart:

object_id
evaluation_status
last_evaluated_hash
decision
notification_id

Beste toepassing

Gebruik dit patroon voor:

• CRM-synchronisatie.
• Ticketingsystemen.
• Administratieve documenten.
• Productinventaris.
• Compliance-review.
• Zoekindexering.
• Interne dashboards.

Zwakke punten

Alles synchroniseren kan duur en onnodig zijn. Het kan ook privacy- en retentieverplichtingen creëren. Gebruik dit patroon wanneer lokale data waarde heeft buiten een enkele assistentactie.

Methode 10: Adaptieve polling

Adaptieve polling verandert frequentie op basis van status, urgentie of recente activiteit.

actief object: poll elke 1 minuut
wachtend object: poll elke 1 uur
verouderd object: poll een keer per dag
voltooid object: stop met pollen

Hoe het werkt

Na elke run beslist de worker wanneer de volgende run moet plaatsvinden.

Als het object onlangs is veranderd, poll dan sneller. Als er al lang niets is veranderd, vertraag dan. Als de taak is voltooid, stop dan.

Statusmodel

De pollstatus bevat:

current_interval
minimum_interval
maximum_interval
backoff_policy
last_activity_at
priority
stop_condition

De bronsnapshot bevat:

status
updated_at
activity_level
expected_next_change

Beste toepassing

Gebruik adaptieve polling voor:

• Deployeringsstatus.
• Bezorgingsvolging.
• Beschikbaarheid van kalenderSlots.
• Prijsmonitoring.
• Build-jobs.
• Langlopende providertaken.
• Elke bron met bursty updates.

Zwakke punten

Adaptieve polling kan moeilijker te begrijpen zijn. Als een taak op een strikt moment moet draaien, houd het dan strikt. Maak compliance-taken niet slim.

Methode 11: Semantische polling met een LLM-evaluator

Semantische polling wordt gebruikt wanneer de voorwaarde vaag is.

Code kan antwoorden:

Is status gelijk aan Voltooid?
Is prijs onder 100?
Is er een nieuw bericht?

Een LLM kan helpen antwoorden:

Klinkt dit e-mail urgent?
Is deze klant waarschijnlijk ontevreden?
Is dit onderzoeksartikel relevant?
Vereist deze verandering mijn aandacht?

Hoe het werkt

De worker past eerst goedkope deterministische filters toe. Alleen kandidaat-items gaan naar de LLM.

nieuw item?
voldoet aan bronfilters?
niet al verwerkt?
niet duidelijk irrelevant?

Vervolgens evalueert de LLM de kleinere kandidaatset en retourneert gestructureerde output.

{
  "should_notify": true,
  "urgency": "high",
  "reason": "De klant meldt een productie-uitval."
}

Statusmodel

De poll-definitie bewaart:

semantic_condition
examples
negative_examples
user_preference_summary
model_config

Het evaluatielogboek bewaart:

input_reference
model
prompt_version
structured_output
confidence
cost
latency

De pollstatus bewaart:

last_seen_ids
last_evaluated_hashes
last_decision
last_decision_reason

Beste toepassing

Gebruik semantische polling voor:

• Detectie van belangrijke e-mails.
• Klant sentiment monitoring.
• Onderzoeksalerts.
• Detectie van verkoopkansen.
• Security triage.
• Uitvoerende samenvattingen.

Zwakke punten

LLM-oproepen kosten geld en voegen latentie toe. Ze kunnen ook inconsistent zijn als prompts en schemas losjes zijn. Gebruik eerst deterministische filters. Vraag het model alleen wanneer oordeel echt nodig is.

Beslissingstabel: Een pollende agentmethode kiezen

Aanbevolen standaardarchitectuur

Voor de meeste productie-AI-assistents, begin met dit:

polls-tabel
  -> planner
  -> wachtrij
  -> stateless workers
  -> deterministische filters
  -> optionele LLM-evaluator
  -> melding of assistentactie

Een minimale 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)
);

Dit geeft je een schone scheiding:

planner bezit tijd
wachtrij bezit buffering
worker bezit uitvoering
database bezit status
LLM bezit semantisch oordeel
assistent bezit gebruikersinteractie

Die scheiding is het hart van een betrouwbare pollende agent.

Voorbeeld: Hermes-agent verwerkt Notion-taken

Laten we de architectuur nu toepassen op een concreet geval.

Stel dat een Notion-database taken bevat. Hermes moet elke 10 minuten draaien, één taak in Todo-status pakken, deze op InProgress zetten, uitvoeren en vervolgens als Complete markeren.

Dit is het beste te beschrijven als:

extern hulpmiddel als taakwachtrij
+
gepoldeerde pollende worker
+
claim- of leasegebaseerde uitvoering

Voor een productieve versie wordt het:

wachtrijgebaseerde polling met Notion als de voor mensen zichtbare taakinbox

Notion-taakeigenschappen

De Notion-database moet velden bevatten zoals:

Naam
Status: Todo | InProgress | Complete | Failed
Prioriteit
CreatedAt
ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId
RetryCount
LastError
CompletedAt

De belangrijke velden zijn ClaimedAt, ClaimExpiresAt en RunId. Ze maken de taakclaim zichtbaar en te herstellen.

Hermes-uitvoeringsstatus

Hermes moet ook zijn eigen uitvoeringsregistratie bijhouden:

run_id
notion_page_id
started_at
finished_at
status
input_snapshot
tool_calls
result_summary
error
idempotency_key

Dit beschermt je als Notion handmatig wordt bewerkt, als een API-aanroep faalt, of als je moet controleren wat Hermes daadwerkelijk heeft gedaan.

Uitvoeringsstroom

Elke 10 minuten:
  Hermes-planner maakt een run

Hermes-worker:
  vindt één Notion-taak waarbij Status = Todo
  sorteer op Prioriteit en CreatedAt
  claimt de taak door Status in te stellen op InProgress
  schrijft ClaimedBy, ClaimedAt, ClaimExpiresAt en RunId
  voert de taak uit
  schrijft uitvoeringslogs naar Hermes-backend
  stelt Notion-Status in op Complete bij succes
  stelt Notion-Status in op Failed bij falen

Als Hermes crasht nadat hij een taak heeft geclaimd, kan de lease verlopen:

Status = InProgress
ClaimExpiresAt < nu

Een toekomstige run kan de taak dan herstellen of als mislukt markeren.

Foutafhandeling

Bij succes:

Status = Complete
CompletedAt = nu
LastError = leeg

Bij herstelbaar falen:

Status = Todo
RetryCount = RetryCount + 1
LastError = korte foutmelding

Bij niet-herstelbaar falen:

Status = Failed
LastError = duidelijke uitleg

Voor veiligheid moet Hermes ook een idempotentie-sleutel gebruiken:

notion_page_id + task_version + action_type

Dit voorkomt dat dezelfde taak twee keer wordt uitgevoerd als een retry op het verkeerde moment plaatsvindt.

Waarom dit niet alleen polling is

Het polling-deel is alleen het wakermakend mechanisme. De echte architectuur is taakclaiming en betrouwbare uitvoering.

Een naïeve implementatie zegt:

Elke 10 minuten, vind een Todo-taak en doe het.

Een betrouwbare implementatie zegt:

Elke 10 minuten, claim precies één geschikte taak, registreer de run, voer idempotent uit en verplaats de taak naar een eindstatus.

Dat is het verschil tussen een demo en een agent die je kunt vertrouwen.

Veelgemaakte fouten bij pollende agents

Fout 1: Geen claimprotocol

Als twee workers dezelfde taak kunnen zien, kunnen ze deze beide uitvoeren.

Gebruik:

ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId

Zelfs als je momenteel één worker draait, ontwerp dan alsof er later een tweede worker kan verschijnen.

Fout 2: Geen dedupe-sleutel

Elke externe actie moet een dedupe-sleutel hebben.

user_id + poll_id + source_object_id + action_type + condition_version

Dit voorkomt herhaalde meldingen, herhaalde e-mails, herhaalde taakuitvoering en herhaalde tool-aanroepen. De bredere principes achter scoping, opslaan en testen van deze sleutels zijn hier eveneens van toepassing — zie Idempotentie in gedistribueerde systemen die daadwerkelijk werkt.

Fout 3: Te vroeg de LLM aanroepen

Vraag het model niet om databasefiltering te doen.

Slecht:

Stuur alle taken naar de LLM en vraag welke Todo is.

Beter:

Gebruik de Notion-API-filter om Todo-taken op te halen.
Gebruik de LLM alleen als taakinterpretatie nodig is.

Fout 4: Notion behandelen als de enige backend

Notion is een goede menselijke interface. Het is geen complete uitvoeringsbackend.

Bewaar uitvoeringslogs, retries, traces en idempotentieregistraties in Hermes.

Fout 5: Oneindige polling

Elke poll moet een stopconditie hebben.

Voorbeelden:

stop na succes
stop na datum
stop na max retries
stop wanneer gebruiker het uitschakelt
stop na herhaalde autorisatiefouten

Een pollende agent zonder stopconditie is een stille kostenlek.

Fout 6: Geen observabiliteit

Je moet in staat zijn om te beantwoorden:

Wat heeft de agent uitgevoerd?
Waarom heeft het uitgevoerd?
Wat heeft het gelezen?
Wat heeft het veranderd?
Waarom is het mislukt?
Heeft het de gebruiker gemeld?
Heeft het twee keer uitgevoerd?

Als je die vragen niet kunt beantwoorden, is het systeem niet klaar voor belangrijk werk.

Observabiliteitscontrolelijst

Houd metingen bij zoals:

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

Log velden zoals:

poll_id
run_id
source_type
source_object_id
claim_id
cursor_before
cursor_after
decision
dedupe_key
error

Bouw een admin-view voor:

actieve polls
vastgelopen InProgress-taken
recente fouten
taken met hoge retry
Dead Letter-jobs
duurzame LLM-evaluaties
uitgeschakelde integraties

Pollende agents draaien op de achtergrond, waar fouten stil zijn en problemen kunnen opstapelen voordat iemand het merkt. Achtergrondsysteem hebben zichtbaarheid nodig die vanaf het begin is ingebouwd, niet als een nagedachte toevoeging wanneer er iets misgaat. Zie voor de volledige observabiliteitsstack voor AI- en LLM-gesponsorde systemen — metingen, traces, gestructureerde logs en SLO’s — Observabiliteit voor LLM-systemen: metingen, traces, logs en testen in productie.

Eindaanbeveling

Pollingpatronen behandelen de proactieve planningslaag onder een multi-agentsysteem. Zodra je meerdere agents hebt die met elkaar moeten coördineren — niet alleen onafhankelijk pollen — is het volgende ontwerpbepalende besluit hoe ze coördineren: hub-and-spoke, pipeline, fan-out of zwerm. Multi-Agent Orkestratiepatronen behandelt die coördinatielogeometrieën met faalmodi en een beslissingsframework.

Voor een serieuze AI-assistent, begin met wachtrijgebaseerde pollende workers en een duurzame statusopslag. Voeg webhooks toe waar providers ze ondersteunen. Gebruik adaptieve polling wanneer rate limits belangrijk zijn. Gebruik een duurzame workflow-engine wanneer het proces langlopend en multi-step is. Gebruik persistente agentruntime wanneer de agent door de tijd heen moet redeneren.

Voor het Hermes- en Notion-voorbeeld is de juiste architectuur:

Notion als de voor mensen zichtbare taakinbox
Hermes-planner elke 10 minuten
Hermes-worker met claim- of lease-logica
Hermes-backend voor uitvoeringslogs en idempotentie
Notion-statusupdates voor zichtbaarheid

Het polling-interval is niet het moeilijke deel. Het moeilijke deel is ervoor zorgen dat de agent één taak claimt, deze één keer uitvoert, registreert wat er is gebeurd en het systeem in een staat laat die mensen kunnen begrijpen.

Dat is wat een polling-script omzet in een betrouwbare AI-assistent — niet het interval, niet het model, maar de discipline rondom het claimen van werk, het registreren ervan en het achterlaten van het systeem in een staat die zowel mensen als toekomstige runs kunnen begrijpen.