Agenti per Eventi vs Agenti Pianificati: Quale Pattern per Quale Lavoro

Indice

Aggiornato maggio 2026.

TL;DR: Usa agenti per eventi quando un’azione dell’utente richiede risposta immediata — qualsiasi ritardo oltre pochi secondi rompe l’esperienza. Usa agenti pianificati per lavori batch o periodici dove il timing è prevedibile. Il vincolo: gli agenti per eventi devono essere stateless e veloci; quelli pianificati possono essere stateful e più lenti.

[Prospettiva dell’operatore] Gestisco oltre 30 agenti in produzione per il mio brand di consulenza e Pickleland, un impianto di pickleball a Pflugerville, TX. Ognuno di essi rientra in uno dei due pattern: si attiva su un evento, o si attiva su un orologio. Sbagliare qui spreca denaro e consegna esperienze rotte.

I due pattern in parole semplici

Un agente per eventi si sveglia perché qualcosa è successo. È arrivata una prenotazione. È stato pubblicato un commento. È stato inviato un modulo. Il trigger è esterno e imprevedibile nel tempo. Il lavoro: rispondere velocemente.

Un agente pianificato si sveglia perché l’orologio lo dice. Ogni mattina alle 7. Ogni domenica alle 18. Ogni ora in punto. Il trigger è interno e completamente prevedibile. Il lavoro: fare un lavoro accurato.

È tutto. Non complicare. L’architettura deriva dalla risposta a una domanda: l’utente o il sistema ha bisogno di una risposta adesso, o può aspettare fino a un momento specifico?

Per eventi: l’agente di risposta social

Il mio agente di risposta social si attiva quando arriva un nuovo commento su un post Facebook monitorato. L’agente legge il commento, classifica l’intento (domanda, reclamo, complimento, spam), abbozza una risposta e la pubblica — oppure la segnala per revisione umana se la confidenza è bassa.

L’intero ciclo deve completarsi in meno di 30 secondi, altrimenti la risposta sembra obsoleta. Questo è un problema di attivazione per eventi.

Ecco un Cloudflare Worker semplificato che gestisce il webhook di un servizio di monitoraggio social:

// workers/social-reply.ts
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    if (request.method !== "POST") {
      return new Response("Method not allowed", { status: 405 });
    }

    // Verificare la firma del webhook
    const sig = request.headers.get("x-webhook-signature") ?? "";
    const body = await request.text();
    const valid = await verifySignature(body, sig, env.WEBHOOK_SECRET);
    if (!valid) return new Response("Unauthorized", { status: 401 });

    const event = JSON.parse(body) as SocialCommentEvent;

    // Classificare e rispondere — mantenere async per restituire 200 velocemente
    env.REPLY_QUEUE.send(event);

    return new Response("OK", { status: 200 });
  },
};

// Consumer della coda — fa il lavoro IA reale
export const queue: ExportedHandlerQueueHandler<Env, SocialCommentEvent> =
  async (batch, env) => {
    for (const msg of batch.messages) {
      const comment = msg.body;

      const classification = await classifyComment(comment.text, env);
      if (classification.intent === "spam") {
        msg.ack();
        continue;
      }

      const reply = await draftReply(comment, classification, env);

      if (classification.confidence > 0.85) {
        await postReply(comment.postId, comment.id, reply, env);
      } else {
        await flagForReview(comment, reply, env);
      }

      msg.ack();
    }
  };

Due cose da notare. Primo, il fetch handler restituisce 200 immediatamente e delega il lavoro reale a una coda. Questo mantiene la risposta del webhook veloce e impedisce al servizio di monitoraggio di riprovare. Secondo, il consumer della coda esegue la vera chiamata IA — classificazione e bozza — senza pressione temporale da una connessione HTTP aperta.

Pianificato: il promotore di eventi Pickleland

Pickleland gestisce campi ed eventi. Ogni settimana, qualcuno deve pubblicare i prossimi eventi nei gruppi Facebook giusti per riempire i posti. Questo è puro lavoro batch periodico — nessuna azione dell’utente lo scatena, e non deve avvenire in tempo reale.

Il promotore di eventi Pickleland gira su un cron, controlla il sistema di prenotazione per eventi nei prossimi 4 giorni, abbozza post specifici per ciascun gruppo Facebook corrispondente, e li presenta per la mia revisione prima che qualcosa vada live.

// workers/event-promoter.ts
export default {
  async scheduled(
    event: ScheduledEvent,
    env: Env,
    ctx: ExecutionContext
  ): Promise<void> {
    ctx.waitUntil(runPromoter(env));
  },
};

async function runPromoter(env: Env): Promise<void> {
  // Recuperare eventi dal sistema di prenotazione
  const upcomingEvents = await fetchUpcomingEvents(env, { daysAhead: 4 });

  if (upcomingEvents.length === 0) return;

  const drafts: PromoDraft[] = [];

  for (const event of upcomingEvents) {
    // Abbinare ogni evento ai gruppi FB giusti
    const groups = await matchFacebookGroups(event, env);

    for (const group of groups) {
      const post = await draftPromoPost(event, group, env);
      drafts.push({ event, group, post });
    }
  }

  // Salvare le bozze in Airtable per revisione — nulla viene pubblicato automaticamente
  await saveDraftsForReview(drafts, env);

  // Notificarmi via Slack
  await notifyOperator(
    `${drafts.length} bozze promo pronte per revisione`,
    env
  );
}

La config wrangler che collega tutto:

# wrangler.toml
[[triggers]]
crons = ["0 18 * * 0"]  # Ogni domenica alle 18 UTC

Nota cosa può fare l’agente pianificato che quello per eventi non può: itera su più eventi, scrive su un database e invia una notifica riepilogativa. Sta facendo lavoro batch. L’agente per eventi deve restare leggero e rispondere veloce.

Pianificato: il briefing quotidiano

Ogni mattina alle 7, il mio agente di briefing quotidiano gira. Recupera le email notturne, il mio calendario, le attività prioritarie e qualsiasi notizia che ho contrassegnato come rilevante. Formatta tutto in un unico documento e lo deposita nella cartella AI Workspace.

Questo è puramente pianificato. Non c’è nessun evento che lo scatenerebbe — voglio semplicemente che giri ogni mattina prima di iniziare a lavorare.

// workers/daily-brief.ts
export default {
  async scheduled(
    event: ScheduledEvent,
    env: Env,
    ctx: ExecutionContext
  ): Promise<void> {
    ctx.waitUntil(buildDailyBrief(env));
  },
};

async function buildDailyBrief(env: Env): Promise<void> {
  const [emails, calendar, tasks] = await Promise.all([
    fetchOvernightEmails(env),
    fetchTodayCalendar(env),
    fetchTopTasks(env),
  ]);

  const brief = await synthesizeBrief({ emails, calendar, tasks }, env);

  await writeToWorkspace(brief, env);
}

[[triggers]]
crons = ["0 7 * * *"]  # Ogni giorno alle 7 UTC

Il Promise.all parallelo è deliberato. Gli agenti pianificati non hanno un umano in attesa — ma non dovrebbero comunque essere più lenti del necessario. Recuperare tutte le fonti dati in parallelo, poi fare la sintesi IA una volta sola.

Quando gli agenti per eventi falliscono

Il modo di fallire più comune: qualcuno costruisce un agente per eventi che fa troppo lavoro nell’handler.

Arriva una prenotazione. L’agente recupera il profilo cliente, lo arricchisce da tre API esterne, esegue un modello di personalizzazione, scrive nel CRM, invia l’email di conferma e aggiorna una dashboard. Il tutto richiede 45 secondi. La piattaforma di prenotazione riprova perché non ha ricevuto un 200 abbastanza velocemente. Ora l’agente gira due volte.

Correzione: stesso approccio dell’agente di risposta social — restituire 200 immediatamente, inviare l’evento a una coda, lasciare che il consumer della coda faccia il lavoro pesante in modo asincrono.

L’altro fallimento: usare per eventi per lavoro che è in realtà periodico. “Inviare un riepilogo settimanale” non è un evento. Non collegarlo a un webhook cron sintetico — usare un trigger pianificato appropriato.

Quando gli agenti pianificati falliscono

Gli agenti pianificati falliscono quando il lavoro è in realtà sensibile alla latenza. Se un utente invia un modulo e l’agente che lo processa gira su un cron di 5 minuti, l’utente fissa uno spinner per fino a 5 minuti. Non è un job pianificato — è un job per eventi lento che finge di essere pianificato.

L’altro fallimento: agenti pianificati che si espandono a lavoro illimitato. Se il cron gira ogni minuto e ogni invocazione può elaborare centinaia di record, si raggiungeranno i limiti CPU di Cloudflare rapidamente. Aumentare l’intervallo del cron, aggiungere una coda per limitare il lavoro per invocazione, o passare ai Durable Objects per coordinazione a lungo termine.

Mescolare i pattern: la pipeline di prenotazioni

Alcuni flussi di lavoro hanno genuinamente bisogno di entrambi. La pipeline di prenotazioni Pickleland funziona così:

1. Per eventi: webhook nuova prenotazione → confermare la prenotazione, inviare la ricevuta al cliente, aggiornare la disponibilità. Deve completarsi in meno di 10 secondi.
2. Pianificato: ogni domenica → esaminare tutte le prenotazioni della settimana scorsa, generare un report riepilogativo, segnalare anomalie (prenotazioni duplicate, tassi di cancellazione insoliti).

Stesso dominio, due pattern, due agenti. Quello per eventi possiede l’esperienza utente in tempo reale. Quello pianificato possiede la revisione operativa settimanale. Condividono un database ma nient’altro.

Non provare a combinarli in un singolo agente che “fa tutto.” Il risultato sarebbe qualcosa di troppo lento per gli eventi e troppo accoppiato al flusso in tempo reale per il lavoro batch.

Cloudflare Workers: perché è l’infrastruttura giusta per entrambi

Cloudflare Workers gestisce entrambi i pattern nativamente:

• Handler fetch → per eventi (webhook, chiamate API)
• Handler scheduled → basato su cron (via [[triggers]] in wrangler.toml)
• Consumer queue → elaborazione asincrona disaccoppiata dallo strato HTTP

Il deployment sull’edge significa che gli agenti per eventi rispondono velocemente globalmente. Il livello gratuito è abbastanza generoso per prototipare entrambi i pattern senza spendere nulla. E la configurazione unificata wrangler.toml significa che non si gestiscono due setup infrastrutturali separati per due pattern.

L’unica cosa che Workers non risolve bene: agenti che devono girare per più di pochi minuti. Per quelli, usare i Durable Objects o delegare a un backend di maggiore durata.

La conclusione dell’operatore

Scegliere il proprio pattern prima di scrivere una singola riga di codice agente. Per eventi per tutto ciò su cui un umano sta aspettando; pianificato per tutto ciò che gira su un orologio. Tenere gli handler per eventi leggeri — rispondere veloce, accodare il lavoro. Tenere gli agenti pianificati paralleli — non serializzare ciò che si può parallelizzare. L’architettura è semplice. Violarla è la fonte della complessità.