Agenti di polling negli assistenti AI: 11 pattern di implementazione

Gli agenti di polling sono una delle parti meno glamour dell’architettura degli assistenti AI, ma sono anche tra le più utili.

Un assistente chat normale aspetta che l’utente ponga una domanda. Un agente di polling continua a vigilare. Controlla una fonte, nota i cambiamenti, decide se qualcosa è rilevante e poi agisce. Tale azione può essere una notifica, un riassunto, una bozza, una chiamata a uno strumento o un flusso di lavoro completo.

Questo è il modo in cui un assistente passa da “rispondi alla mia domanda” a “tieni d’occhio questo per me”. Invece di essere reattivo, diventa un processo in background che nota le cose per conto dell’utente e agisce quando sono soddisfatte le condizioni.

Il punto di progettazione importante è semplice: non rendere il modello linguistico responsabile del tempo, dello stato, dei tentativi ripetuti o del blocco. Usa l’infrastruttura backend normale per questo. Usa il modello dove è prezioso: interpretare un contesto disordinato, prendere giudizi semantici e produrre linguaggio utile.

Cos’è un Agente di Polling?

Un agente di polling è un processo in background che controlla ripetutamente una fonte e innesca un’azione dell’assistente quando è soddisfatta una condizione. Nella più ampia stack di Sistemi AI — dove l’assistente combina un LLM, memoria, strumenti, routing e osservabilità — lo strato di polling è ciò che rende l’assistente proattivo piuttosto che puramente reattivo. Per l’immagine completa a cinque strati, vedi Architettura dell’Assistente AI: LLM, Memoria, Strumenti, Routing, Osservabilità.

Esempi:

• Controllare una casella di posta ogni mattina e riassumere i messaggi importanti.
• Monitorare un elenco di compiti su Notion ed eseguire la prossima attività.
• Monitorare un issue su GitHub finché non cambia stato.
• Pollare un lavoro AI di lunga durata finché il risultato non è pronto.
• Controllare uno slot di prenotazione finché uno diventa disponibile.
• Monitorare un portale del fornitore finché non appare un documento.
• Scansionare nuovi paper di ricerca una volta alla settimana e riassumere quelli rilevanti.

Un agente di polling pratico ha cinque responsabilità:

1. Svegliarsi al momento giusto.
2. Leggere dalla fonte.
3. Ricordare cosa ha già visto.
4. Decidere se il nuovo stato è rilevante.
5. Agire una volta, in sicurezza, senza ripetere se stesso.

Un flusso di produzione tipico assomiglia a questo:

scheduler
  -> polling worker
  -> source system
  -> state store
  -> deterministic filters
  -> optional LLM evaluation
  -> assistant action

Questa struttura è noiosa nel miglior modo possibile. I sistemi noiosi sono più facili da debuggare alle 2 del mattino.

Lo Stato di cui Ogni Agente di Polling Ha Bisogno

Gli agenti di polling hanno bisogno di uno stato durevole. La cronologia della conversazione non è sufficiente. L’assistente può ricordare la conversazione, ma il sistema ha bisogno di un record operativo affidabile.

Un buon record di stato di polling di solito contiene:

{
  "poll_id": "poll_123",
  "user_id": "user_456",
  "source_type": "notion",
  "source_ref": "database_tasks",
  "condition": "prendi un compito in stato Todo ed eseguirlo",
  "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"
}

Lo schema esatto dipende dalla fonte, ma la maggior parte dei sistemi ha bisogno di questi concetti.

Definizione del Poll

Questo descrive cosa l’agente sta monitorando e perché.

poll_id
user_id
workspace_id
source_type
source_ref
condition_text
priority
status

Ad esempio:

source_type: notion
source_ref: Database Compiti
condition_text: Trova un compito Todo, assegnalo, eseguirlo, marcarlo Completato.

Pianificazione

Questo descrive quando l’agente dovrebbe eseguire.

interval_seconds
cron_expression
timezone
last_run_at
next_run_at
jitter

Per un agente Hermes che controlla Notion ogni 10 minuti:

interval_seconds: 600
timezone: Australia/Melbourne

Cursore o Snapshot

Questo aiuta l’agente a evitare di rielaborare gli stessi dati.

A seconda della fonte, questo può essere:

last_seen_id
last_seen_timestamp
api_cursor
etag
version
content_hash

Per una coda di compiti di Notion, il cursore può essere meno importante dello stato del compito e dei campi di assegnazione. Per Gmail, GitHub o un’API di sincronizzazione, il cursore è di solito critico.

Assegnazione o Lease

Questo impedisce a due worker di prendere lo stesso lavoro.

claimed_by
claimed_at
claim_expires_at
run_id

Ad esempio, un compito di Notion può essere cambiato da:

Status: Todo

a:

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

Questa è la differenza tra “spero che solo un worker lo prenda” e “il sistema ha un protocollo di assegnazione”.

Record di Esecuzione

Questo registra cosa è successo durante un’esecuzione.

run_id
poll_id
source_object_id
started_at
finished_at
status
items_checked
items_changed
decision_summary
error

Il record di esecuzione dovrebbe vivere nel backend dell’assistente, non solo in Notion o in un altro strumento esterno. Notion è buono per la visibilità umana. Non è ideale come unico registro di esecuzione.

Record di Deduplicazione

Questo impedisce notifiche duplicate o azioni ripetute.

dedupe_key
poll_id
source_object_id
condition_version
action_type
delivered_at

Ad esempio:

user_456:poll_123:notion_page_999:execute:v1

Se la stessa azione viene tentata di nuovo, il sistema può sopprimerla.

Metodo 1: Worker di Polling Programmato

Questo è il pattern più semplice e affidabile.

Un programmatore si sveglia ogni intervallo fisso e chiama un worker. Il worker legge la fonte, aggiorna lo stato e innesca un’azione dell’assistente se richiesto.

scheduler
  -> worker
  -> source API
  -> database
  -> assistant action

Come Funziona

Il programmatore è responsabile del tempo. Potrebbe essere cron, un programmatore cloud, un CronJob Kubernetes o un piccolo programmatore interno.

Ad ogni intervallo, avvia un’esecuzione del worker. Il worker carica la sua configurazione, interroga la fonte target, confronta il risultato con lo stato memorizzato e agisce se necessario.

Per un assistente semplice, questo è spesso sufficiente. Un singolo programmatore e un processo worker leggero possono gestire decine di controlli giornalieri senza richiedere code, lease o coordinamento distribuito.

Modello di Stato

Il programmatore memorizza molto poco. Di solito sa solo quando innescare un lavoro.

Il database dell’applicazione memorizza lo stato importante:

definizione del poll
pianificazione
cursore o snapshot
ultima ora di esecuzione
conteggio errori
status

Il worker dovrebbe essere stateless. Può contenere dati temporanei mentre è in esecuzione, ma la verità durevole appartiene al database.

Flusso di Esempio

Ogni 10 minuti:
  innesca il worker di polling Hermes

Worker:
  carica la configurazione del poll attivo
  interroga la fonte
  confronta con lo stato precedente
  esegue controlli deterministici
  chiama LLM solo se necessario
  aggiorna lo stato
  emette evento dell'assistente

Migliore Adattamento

Usa i worker di polling programmati per:

• Riepiloghi giornalieri.
• Controlli orari.
• Piccole automazioni interne.
• Compiti semplici di “tieni d’occhio questo”.
• Lavori assistenti a volume basso o medio.

Debolezze

Il polling programmato è facile da capire, ma può diventare fragile su larga scala. Se molti poll vengono eseguiti allo stesso tempo, puoi sovraccaricare i tuoi worker o raggiungere i limiti di frequenza del provider. Anche i tentativi ripetuti possono diventare caotici se il programmatore avvia direttamente il lavoro.

Metodo 2: Worker di Polling Basati su Code

Il polling basato su code è di solito il default migliore per gli assistenti AI di produzione.

Il programmatore non esegue il poll direttamente. Mette un lavoro in una coda. I processi worker consumano i lavori dalla coda.

scheduler
  -> queue
  -> worker pool
  -> source API
  -> state store
  -> assistant action

Come Funziona

Un programmatore cerca i poll scaduti e accoda i lavori. I worker prelevano i lavori quando hanno capacità.

Questo ti dà la contro-pressione. Se il sistema è occupato, i lavori aspettano nella coda invece di sopraffare l’API della fonte o il provider LLM.

Modello di Stato

Il database memorizza lo stato del poll:

poll_id
user_id
source_ref
condition_text
next_run_at
cursor
status
failure_count

Il messaggio della coda dovrebbe rimanere piccolo:

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

Il worker carica lo stato completo dal database quando si avvia.

Flusso di Esempio

Ogni minuto:
  il programmatore trova i poll dove next_run_at <= ora
  il programmatore accoda i lavori

Worker:
  preleva i lavori dalla coda
  blocca o affitta il poll
  interroga la fonte
  aggiorna lo stato
  emette azione dell'assistente se necessario
  imposta next_run_at

Migliore Adattamento

Usa il polling basato su code per:

• Assistenti AI multi-utente.
• Molti poll simultanei.
• Integrazioni con limiti di frequenza.
• Lavoro in background ripetibile.
• Lavori che possono richiedere quantità di tempo diverse.
• Prodotti SaaS dove l’affidabilità è importante.

Debolezze

Le code aggiungono infrastruttura. Hai bisogno di gestione delle lettere morte, idempotenza, timeout di visibilità e politiche di retry. Vale la pena per i sistemi di produzione, ma probabilmente eccessivo per un piccolo prototipo.

Metodo 3: Strumento Esterno come Coda di Compiti

Questo è il pattern nell’esempio Notion più Hermes.

Lo strumento esterno non è solo una fonte di dati. Diventa la coda di compiti visibile all’utente. L’agente controlla periodicamente lo strumento, assegna un compito, lo esegue e aggiorna lo stato del compito.

scheduler
  -> Hermes worker
  -> Notion database
  -> claim one task
  -> execute task
  -> update Notion status

Come Funziona

Ogni 10 minuti, Hermes interroga il database di Notion per un compito in stato Todo. Sceglie il prossimo compito, di solito per priorità e tempo di creazione. Poi assegna il compito impostandolo su InProgress.

Dopo di che, Hermes esegue il compito. Se l’esecuzione ha successo, marca il compito come Complete. Se l’esecuzione fallisce, marca il compito come Failed o lo restituisce a Todo con un conteggio di retry.

Modello di Stato

Notion memorizza lo stato del compito visibile all’utente:

Titolo
Descrizione
Status: Todo | InProgress | Complete | Failed
Priority
CreatedAt
ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId
RetryCount
LastError
CompletedAt

Il backend Hermes memorizza lo stato di esecuzione operativo:

run_id
notion_page_id
started_at
finished_at
execution_status
tool_calls
LLM trace
error details
idempotency_key

Questa separazione è importante. Notion è eccellente per la visibilità e la modifica manuale. Il backend Hermes è migliore per log, retry, deduplicazione e storia dell’audit.

Flusso di Esempio

Ogni 10 minuti:
  Hermes si sveglia

Hermes:
  interroga Notion per un compito dove Status = Todo
  ordina per Priority, CreatedAt
  aggiorna il compito selezionato a InProgress
  imposta ClaimedBy, ClaimedAt, ClaimExpiresAt, RunId
  esegue il compito
  scrive il log di esecuzione
  imposta il compito su Complete o Failed

Migliore Adattamento

Usa questo pattern quando:

• Gli umani gestiscono già il lavoro in Notion, Jira, Linear, Trello o un altro strumento.
• Vuoi che l’assistente elabori compiti visibili.
• La bacheca dei compiti è l’interfaccia utente.
• Hai bisogno di un modello di automazione semplice con intervento umano.

Debolezze

Gli strumenti esterni raramente sono code perfette. Le assegnazioni atomiche possono essere limitate. La coerenza delle query può ritardare. Possono applicarsi limiti di frequenza. Se l’agente può eseguire in più istanze, hai bisogno di una strategia di assegnazione o lease attenta.

La raccomandazione pratica è usare Notion come casella di posta dei compiti visibile all’utente mantenendo tutti i log di esecuzione, i record di retry, le tracce e le chiavi di idempotenza in Hermes. Notion dà agli utenti visibilità; Hermes mantiene il sistema affidabile. Per il dispatcher e la meccanica di concorrenza che stanno dietro a questo pattern in Hermes, vedi Kanban in Hermes Agent per Workflow LLM Self-Hosted.

Metodo 4: Loop di Worker a Lunga Durata

Un loop a lunga durata è l’implementazione più semplice.

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

Questo pattern combina pianificazione ed esecuzione in un unico servizio, il che lo rende il punto di partenza più semplice possibile per il lavoro dell’agente in background.

Come Funziona

Il processo worker viene eseguito continuamente. Ogni pochi secondi o minuti, controlla il database per i poll scaduti e li esegue. È facile da costruire, facile da ragionare su e veloce da iterare durante lo sviluppo.

Modello di Stato

Il database memorizza ancora lo stato durevole:

configurazione del poll
next_run_at
cursor
ultimo risultato
conteggio errori
status

La memoria del processo dovrebbe contenere solo stato temporaneo:

batch corrente
cache a breve termine
esecuzione in corso

Non memorizzare mai progressi importanti solo nella memoria. Se il processo crasha, qualsiasi stato che non è stato scritto nello storage durevole è perso, e la prossima esecuzione non avrà modo di sapere dove si era interrotto.

Migliore Adattamento

Usa i loop a lunga durata per:

• Prototipi.
• Sviluppo locale.
• Strumenti interni.
• Sistemi single-tenant.
• Agenti a basso volume.

Debolezze

Questo pattern diventa rischioso con più repliche. Senza lease, due worker possono eseguire lo stesso poll. Manca anche delle funzionalità operative di una vera coda o motore di workflow.

Un loop a lunga durata non è sbagliato come punto di partenza, ma non è un programmatore distribuito e non dovrebbe essere trattato come tale. Non appena hai bisogno di più repliche o garanzie di affidabilità più forti, dovrai passare a uno dei pattern più strutturati sopra.

Metodo 5: Webhook-First con Fallback di Polling

Se la fonte supporta webhook, usali. Il polling dovrebbe spesso essere il backup, non il meccanismo principale. La stessa divisione appare nella progettazione del protocollo dell’agente: le notifiche push A2A svegliano un handler client, che poi polla GetTask per lo stato completo, come descritto in Streaming A2A e Task Asincroni per Workflow Agent a Lunga Durata.

external system
  -> webhook endpoint
  -> event store
  -> assistant action

reconciliation poll
  -> source API
  -> compare with event store
  -> repair missed events

Come Funziona

Il sistema esterno invia eventi al tuo endpoint webhook quando qualcosa cambia. Il tuo sistema memorizza l’evento e lo elabora asincronamente.

Un poll di riconciliazione più lento viene eseguito ogni poche ore o una volta al giorno. Controlla se sono stati persi degli eventi.

Modello di Stato

Lo store degli eventi registra i webhook in arrivo:

event_id
source_type
source_object_id
event_type
received_at
payload_hash
processed_at
signature_valid

Il poll di riconciliazione memorizza:

last_reconciliation_at
last_seen_cursor
last_seen_version

La tabella degli oggetti della fonte memorizza lo stato più recente noto:

external_id
current_status
external_updated_at
last_processed_event_id

Migliore Adattamento

Usa l’architettura webhook-first per:

• Eventi GitHub.
• Eventi Stripe.
• Eventi Slack.
• Aggiornamenti CRM.
• Notifiche di distribuzione.
• Sistemi di ticketing.

Debolezze

I webhook richiedono un endpoint pubblico, convalida delle firme, protezione dal replay e deduplicazione degli eventi. Alcuni provider inviano anche eventi incompleti, quindi potresti ancora bisogno di recuperare l’oggetto completo.

Tuttavia, se esistono buoni webhook, il polling ogni minuto è di solito uno spreco.

Metodo 6: Polling di Job in Background lato Provider

A volte la cosa che viene pollata è il lavoro AI stesso.

L’applicazione avvia un lavoro provider a lunga durata, memorizza l’ID del lavoro e controlla più tardi se è stato completato.

app
  -> start AI background job
  -> store provider job id
  -> poll status
  -> fetch result
  -> notify user

Come Funziona

L’assistente avvia un lavoro con il provider. Il provider restituisce un ID. Il tuo backend memorizza quell’ID e ne controlla lo stato finché il lavoro non ha successo, fallisce, scade o va in timeout.

Modello di Stato

Il tuo backend memorizza:

assistant_task_id
provider_job_id
user_id
status
created_at
last_checked_at
expires_at
result_ref

Il provider memorizza lo stato temporaneo del lavoro e l’output.

Se l’output è importante, copialo nel tuo storage durevole non appena il lavoro si completa. Lo storage dei risultati lato provider ha finestre di ritenzione brevi e non è un sostituto per un archivio appropriato nel tuo sistema.

Migliore Adattamento

Usa il polling di job in background lato provider per:

• Task di ricerca AI a lunga durata.
• Elaborazione di documenti di grandi dimensioni.
• Analisi del codice.
• Generazione di report.
• Lavori di estrazione dati.
• Compiti che superano i timeout normali delle richieste HTTP.

Debolezze

Questo pattern risolve un problema: aspettare un lavoro provider lungo. Non sostituisce il tuo motore di workflow, programmatore, coda o store di stato aziendale.

Metodo 7: Motore di Workflow Durevole

Un motore di workflow durevole gestisce l’esecuzione a lunga durata, timer, retry e recupero. Temporal è la scelta più comune per i backend assistenti basati su Go e Python; per una guida completa all’implementazione vedi Implementazione di Applicazioni Workflow con Temporal in Go.

Invece di collegare manualmente ogni attesa e retry, modelli il processo come un workflow.

workflow engine
  -> activity: check source
  -> timer: wait
  -> activity: evaluate result
  -> activity: notify user

Come Funziona

Il workflow si avvia una volta e poi controlla la propria attesa. Può dormire per minuti, giorni o settimane. Se il processo worker crasha, il motore di workflow può riprendere dallo stato registrato.

Modello di Stato

Il motore di workflow memorizza:

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

Il database della tua applicazione memorizza:

definizione del poll visibile all'utente
riferimenti di autorizzazione
record aziendali
record di notifica

Il motore di workflow possiede lo stato del processo — storia di esecuzione, timer, retry e tentativi di attività. Il tuo database possiede lo stato aziendale — configurazioni utente, record di autorizzazione, notifiche e log di audit. Mantenere questi separati impedisce a ciascuno strato di diventare un ibrido confuso di entrambi.

Migliore Adattamento

Usa i workflow durevoli per:

• Processi aziendali multi-step.
• Automazioni a lunga durata.
• Flussi di approvazione umana.
• Retry affidabili.
• Lavoro in background auditabile.
• Processi che devono riprendere dopo un fallimento.

Debolezze

I motori di workflow aggiungono concetti e infrastruttura. Sono eccellenti quando il processo è importante, ma pesanti per controlli orari semplici.

Metodo 8: Runtime Agente Persistente

Alcuni framework agent possono persistere lo stato dell’agente, fare checkpoint dell’esecuzione e riprendere più tardi.

Questo è utile quando l’agente stesso ha un processo di ragionamento multi-step.

scheduler or workflow
  -> agent runtime
  -> load checkpoint
  -> call tools
  -> save checkpoint
  -> resume later

Come Funziona

Un programmatore esterno o workflow avvia l’agente. Il runtime dell’agente carica lo stato precedente, esegue il prossimo step, chiama strumenti se necessario e scrive un checkpoint.

Il runtime dell’agente non dovrebbe essere il tuo unico programmatore. È meglio trattato come lo strato di ragionamento all’interno di un’architettura backend più ampia.

Modello di Stato

Lo storage dei checkpoint dell’agente contiene:

current node
messages
tool outputs
intermediate reasoning state
pending action

La memoria a lungo termine contiene:

stable user preferences
facts
project context
source references

Lo stato operativo appartiene ancora altrove:

poll schedule
cursor
status
retry count
dedupe records

Una regola utile: la memoria non è un cursore, e un checkpoint non è una coda. La memoria dell’agente memorizza ciò che il modello sa; lo stato operativo traccia dove si trova il processo e cosa ha fatto. Confluenza dei due porta a bug sottili che appaiono solo sotto concorrenza o dopo un riavvio. Lo spazio di progettazione completo per la memoria di lavoro, lo stato durevole e gli strati di recupero è coperto in Sistemi di Memoria negli Assistenti AI.

Migliore Adattamento

Usa il runtime agente persistente per:

• Ricerca multi-step.
• Agenti che pausano e riprendono.
• Lavoro con intervento umano.
• Ragionamento pesante sugli strumenti.
• Compiti dove il contesto si accumula nel tempo.

Debolezze

La persistenza dell’agente non è la stessa cosa dell’affidabilità operativa. Hai ancora bisogno di pianificazione, bloccaggio, retry, limiti di frequenza e log di audit.

Metodo 9: Sincronizzazione Database Più Valutazione dei Cambiamenti

In questo pattern, il polling è usato per sincronizzare dati esterni nel tuo database. L’assistente poi reagisce ai cambiamenti del database locale invece di interrogare le API esterne direttamente su ogni ciclo di valutazione.

sync poller
  -> external API
  -> local database
  -> change evaluator
  -> assistant action

Questo separa la sincronizzazione dei dati dall’intelligenza dell’assistente. Il worker di sincronizzazione è responsabile di mantenere i record locali aggiornati; il valutatore è responsabile di decidere cosa fare riguardo ai cambiamenti. Ciascuno strato può essere testato, monitorato e scalato indipendentemente.

Come Funziona

Il worker di sincronizzazione recupera periodicamente i cambiamenti esterni e scrive record normalizzati nel tuo database. Un secondo worker o flusso di cambiamenti rileva le righe aggiornate e decide se l’assistente dovrebbe agire.

Modello di Stato

La tabella di sincronizzazione memorizza:

external_id
source_type
raw_payload
normalized_fields
external_updated_at
synced_at
version
content_hash

Lo stato di sincronizzazione memorizza:

source_cursor
last_sync_at
rate_limit_status
failure_count

La tabella di valutazione dell’assistente memorizza:

object_id
evaluation_status
last_evaluated_hash
decision
notification_id

Migliore Adattamento

Usa questo pattern per:

• Sincronizzazione CRM.
• Sistemi di ticketing.
• Documenti contabili.
• Inventario prodotti.
• Revisione conformità.
• Indicizzazione della ricerca.
• Dashboard interne.

Debolezze

Sincronizzare tutto può essere costoso e inutile. Può anche creare obblighi di privacy e ritenzione. Usa questo pattern quando i dati locali hanno valore oltre a un’unica azione dell’assistente.

Metodo 10: Polling Adattivo

Il polling adattivo cambia la frequenza in base allo stato, urgenza o attività recente.

active object: poll every 1 minute
waiting object: poll every 1 hour
stale object: poll once per day
completed object: stop polling

Come Funziona

Dopo ogni esecuzione, il worker decide quando dovrebbe accadere la prossima esecuzione.

Se l’oggetto è cambiato recentemente, polla prima. Se nulla è cambiato per un lungo tempo, rallenta. Se il compito è completo, fermati.

Modello di Stato

Lo stato del poll include:

current_interval
minimum_interval
maximum_interval
backoff_policy
last_activity_at
priority
stop_condition

Lo snapshot della fonte include:

status
updated_at
activity_level
expected_next_change

Migliore Adattamento

Usa il polling adattivo per:

• Stato di distribuzione.
• Tracciamento delle spedizioni.
• Disponibilità slot calendario.
• Monitoraggio dei prezzi.
• Job di build.
• Task provider a lunga durata.
• Qualsiasi fonte con aggiornamenti a raffiche.

Debolezze

Il polling adattivo può essere più difficile da ragionare su. Se un compito deve eseguire a un tempo stretto, mantienilo stretto. Non rendere i lavori di conformità intelligenti.

Metodo 11: Polling Semantico con un Valutatore LLM

Il polling semantico è usato quando la condizione è fuzzy.

Il codice può rispondere:

Lo status è uguale a Complete?
Il prezzo è sotto 100?
C'è un nuovo messaggio?

Un LLM può aiutare a rispondere:

Questo email sembra urgente?
Questo cliente è probabilmente infelice?
Questo paper di ricerca è rilevante?
Questo cambiamento richiede la mia attenzione?

Come Funziona

Il worker applica prima filtri deterministici economici. Solo gli elementi candidati vanno al LLM.

new item?
matches source filters?
not already processed?
not obviously irrelevant?

Poi il LLM valuta l’insieme candidato più piccolo e restituisce output strutturato.

{
  "should_notify": true,
  "urgency": "high",
  "reason": "Il cliente riporta un'interruzione di produzione."
}

Modello di Stato

La definizione del poll memorizza:

semantic_condition
examples
negative_examples
user_preference_summary
model_config

Il log di valutazione memorizza:

input_reference
model
prompt_version
structured_output
confidence
cost
latency

Lo stato del poll memorizza:

last_seen_ids
last_evaluated_hashes
last_decision
last_decision_reason

Migliore Adattamento

Usa il polling semantico per:

• Rilevamento email importanti.
• Monitoraggio del sentiment dei clienti.
• Allarmi di ricerca.
• Rilevamento opportunità di vendita.
• Triage di sicurezza.
• Riepiloghi esecutivi.

Debolezze

Le chiamate LLM costano denaro e aggiungono latenza. Possono anche essere incoerenti se prompt e schemi sono sciolti. Usa filtri deterministici prima. Chiedi al modello solo quando è davvero necessario il giudizio.

Tabella Decisionale: Scegliere un Metodo di Agente di Polling

Architettura Default Raccomandata

Per la maggior parte degli assistenti AI di produzione, inizia con questo:

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

Uno schema minimale:

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

Questo ti dà una separazione pulita:

scheduler owns time
queue owns buffering
worker owns execution
database owns state
LLM owns semantic judgment
assistant owns user interaction

Questa separazione è il cuore di un agente di polling affidabile.

Esempio: Agente Hermes che Processa Compiti Notion

Ora applichiamo l’architettura a un caso concreto.

Assumiamo che un database Notion contenga compiti. Hermes dovrebbe eseguire ogni 10 minuti, prendere un compito in stato Todo, impostarlo su InProgress, eseguirlo e poi marcarlo Complete.

Questo è meglio descritto come:

external tool as task queue
+
scheduled polling worker
+
claim or lease based execution

Per una versione di produzione, diventa:

queue-based polling with Notion as the human-facing task inbox

Proprietà dei Compiti Notion

Il database Notion dovrebbe contenere campi come:

Nome
Status: Todo | InProgress | Complete | Failed
Priority
CreatedAt
ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId
RetryCount
LastError
CompletedAt

I campi importanti sono ClaimedAt, ClaimExpiresAt e RunId. Rendono l’assegnazione del compito visibile e recuperabile.

Stato di Esecuzione Hermes

Hermes dovrebbe anche mantenere il proprio record di esecuzione:

run_id
notion_page_id
started_at
finished_at
status
input_snapshot
tool_calls
result_summary
error
idempotency_key

Questo ti protegge se Notion viene modificato manualmente, se una chiamata API fallisce o se hai bisogno di auditare cosa Hermes ha effettivamente fatto.

Flusso di Esecuzione

Every 10 minutes:
  Hermes scheduler creates a run

Hermes worker:
  finds one Notion task where Status = Todo
  sorts by Priority and CreatedAt
  claims the task by setting Status = InProgress
  writes ClaimedBy, ClaimedAt, ClaimExpiresAt, and RunId
  executes the task
  writes execution logs to Hermes backend
  sets Notion Status = Complete on success
  sets Notion Status = Failed on failure

Se Hermes crasha dopo aver assegnato un compito, il lease può scadere:

Status = InProgress
ClaimExpiresAt < now

Una futura esecuzione può poi recuperare il compito o marcarlo come fallito.

Gestione degli Errori

Su successo:

Status = Complete
CompletedAt = now
LastError = empty

Su errore recuperabile:

Status = Todo
RetryCount = RetryCount + 1
LastError = short error message

Su errore non recuperabile:

Status = Failed
LastError = clear explanation

Per sicurezza, Hermes dovrebbe anche usare una chiave di idempotenza:

notion_page_id + task_version + action_type

Questo impedisce che lo stesso compito venga eseguito due volte se un retry avviene al momento sbagliato.

Perché Questo Non è Solo Polling

La parte di polling è solo il meccanismo di sveglia. La vera architettura è l’assegnazione dei compiti e l’esecuzione affidabile.

Un’implementazione ingenua dice:

Every 10 minutes, find a Todo task and do it.

Un’implementazione affidabile dice:

Every 10 minutes, claim exactly one eligible task, record the run, execute idempotently, and move the task to a terminal state.

Questa è la differenza tra una demo e un agente di cui puoi fidarti.

Errori Comuni degli Agenti di Polling

Errore 1: Nessun Protocollo di Assegnazione

Se due worker possono vedere lo stesso compito, possono entrambi eseguirlo.

Usa:

ClaimedBy
ClaimedAt
ClaimExpiresAt
RunId

Anche se attualmente esegui un worker, progetta come se un secondo worker potesse apparire più tardi.

Errore 2: Nessuna Chiave di Deduplicazione

Ogni azione esterna dovrebbe avere una chiave di deduplicazione.

user_id + poll_id + source_object_id + action_type + condition_version

Questo impedisce notifiche ripetute, email ripetute, esecuzione compiti ripetuta e chiamate strumenti ripetute. I principi più ampi dietro lo scoping, lo storage e il test di queste chiavi si applicano ugualmente qui — vedi Idempotenza nei Sistemi Distribuiti che Funziona Davvero.

Errore 3: Chiamare il LLM Tropo Presto

Non chiedere al modello di fare il filtraggio del database.

Male:

Send all tasks to the LLM and ask which one is Todo.

Meglio:

Use the Notion API filter to fetch Todo tasks.
Then use the LLM only if task interpretation is needed.

Errore 4: Trattare Notion come l’Unico Backend

Notion è un’interfaccia utente buona. Non è un backend di esecuzione completo.

Mantieni i log di esecuzione, i retry, le tracce e i record di idempotenza in Hermes.

Errore 5: Polling Infinito

Ogni poll dovrebbe avere una condizione di stop.

Esempi:

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

Un agente di polling senza una condizione di stop è una perdita di costi silenziosa.

Errore 6: Nessuna Osservabilità

Dovresti essere in grado di rispondere:

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?

Se non puoi rispondere a quelle domande, il sistema non è pronto per lavoro importante.

Checklist di Osservabilità

Traccia metriche come:

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 di campi come:

poll_id
run_id
source_type
source_object_id
claim_id
cursor_before
cursor_after
decision
dedupe_key
error

Costruisci una vista admin per:

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

Gli agenti di polling corrono in background, dove i fallimenti sono silenziosi e i problemi possono accumularsi prima che qualcuno se ne accorga. I sistemi in background hanno bisogno di visibilità costruita fin dall’inizio, non aggiunta come un pensiero successivo quando qualcosa va storto. Per lo stack di osservabilità completo per sistemi AI e LLM — metriche, tracce, log strutturati e SLO — vedi Osservabilità per Sistemi LLM: Metriche, Tracce, Log e Testing in Produzione.

Raccomandazione Finale

I pattern di polling gestiscono lo strato di pianificazione proattiva sotto un sistema multi-agente. Una volta che hai più agenti che hanno bisogno di coordinarsi tra loro — non solo pollare indipendentemente — la prossima decisione di progettazione è come si coordinano: hub-and-spoke, pipeline, fan-out o swarm. Pattern di Orchestrazione Multi-Agente copre quelle topologie di coordinamento con modalità di fallimento e un framework decisionale.

Per un assistente AI serio, inizia con worker di polling basati su code e uno store di stato durevole. Aggiungi webhook dove i provider li supportano. Usa il polling adattivo quando i limiti di frequenza sono importanti. Usa un motore di workflow durevole quando il processo è a lunga durata e multi-step. Usa il runtime agente persistente quando l’agente ha bisogno di ragionare nel tempo.

Per l’esempio Hermes e Notion, l’architettura giusta è:

Notion as the human-facing task inbox
Hermes scheduler every 10 minutes
Hermes worker with claim or lease logic
Hermes backend for execution logs and idempotency
Notion status updates for visibility

L’intervallo di polling non è la parte difficile. La parte difficile è assicurarsi che l’agente assegni un compito, lo esegua una volta, registri cosa è successo e lasci il sistema in uno stato che gli umani possono capire.

Questo è ciò che trasforma uno script di polling in un assistente AI affidabile — non l’intervallo, non il modello, ma la disciplina intorno all’assegnazione del lavoro, alla registrazione e al lasciare il sistema in uno stato che sia gli umani che le esecuzioni future possono capire.