Ereignisgesteuerte vs. Geplante Agenten: Welches Muster Wofür

Inhaltsverzeichnis

Aktualisiert Mai 2026.

TL;DR: Nutze ereignisgesteuerte Agenten, wenn eine Benutzeraktion sofortige Reaktion verlangt – jede Verzögerung über wenige Sekunden bricht die Erfahrung. Nutze geplante Agenten für periodische oder Batch-Arbeit mit vorhersehbarem Timing. Die Einschränkung: Ereignisgesteuerte Agenten müssen zustandslos und schnell sein; geplante dürfen zustandsbehaftet und langsamer sein.

[Operator-Perspektive] Ich betreibe über 30 Produktionsagenten für meine Beratungsmarke und Pickleland, eine Pickleball-Anlage in Pflugerville, TX. Jeder einzelne fällt in eines von zwei Mustern: ausgelöst durch ein Ereignis, oder ausgelöst durch eine Uhr. Wer das verwechselt, verschwendet Geld und liefert kaputte Erlebnisse.

Die zwei Muster in einfachen Worten

Ein ereignisgesteuerter Agent wacht auf, weil etwas passiert ist. Eine Buchung kam rein. Ein Kommentar wurde gepostet. Ein Formular wurde abgeschickt. Der Auslöser ist extern und zeitlich unvorhersehbar. Die Aufgabe: schnell reagieren.

Ein geplanter Agent wacht auf, weil die Uhr es sagt. Jeden Morgen um 7 Uhr. Jeden Sonntag um 18 Uhr. Jede Stunde zur vollen Stunde. Der Auslöser ist intern und vollständig vorhersehbar. Die Aufgabe: gründliche Arbeit leisten.

Das ist alles. Nicht verkomplizieren. Die Architektur ergibt sich aus der Antwort auf eine Frage: Brauchen Benutzer oder System jetzt sofort eine Reaktion, oder kann das bis zu einem bestimmten Zeitpunkt warten?

Ereignisgesteuert: der Social-Reply-Agent

Mein Social-Reply-Agent löst aus, wenn ein neuer Kommentar auf einem überwachten Facebook-Post erscheint. Der Agent liest den Kommentar, klassifiziert die Absicht (Frage, Beschwerde, Lob, Spam), entwirft eine Antwort und veröffentlicht sie – oder markiert sie zur menschlichen Überprüfung, wenn die Konfidenz zu niedrig ist.

Der gesamte Durchlauf muss in unter 30 Sekunden abgeschlossen sein, sonst wirkt die Antwort abgestanden. Das ist ein ereignisgesteuertes Problem.

Hier ein vereinfachter Cloudflare Worker, der den Webhook eines Social-Monitoring-Diensts verarbeitet:

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

    // Webhook-Signatur prüfen
    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;

    // Klassifizieren und antworten — async halten, um schnell 200 zurückzugeben
    env.REPLY_QUEUE.send(event);

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

// Queue-Consumer — macht die eigentliche KI-Arbeit
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();
    }
  };

Zwei Dinge sind zu beachten. Erstens gibt der Fetch-Handler sofort 200 zurück und lagert die eigentliche Arbeit in eine Queue aus. Das hält die Webhook-Antwort schnell und verhindert, dass der Monitoring-Dienst wiederholt. Zweitens führt der Queue-Consumer den eigentlichen KI-Aufruf durch – Klassifizierung und Entwurf – ohne Zeitdruck durch eine offene HTTP-Verbindung.

Geplant: der Pickleland-Veranstaltungspromoter

Pickleland verwaltet Courts und Veranstaltungen. Jede Woche muss jemand bevorstehende Events in die richtigen Facebook-Gruppen posten, um Plätze zu füllen. Das ist reine periodische Batch-Arbeit – kein Benutzer-Event löst sie aus, und sie muss nicht in Echtzeit geschehen.

Der Pickleland-Veranstaltungspromoter läuft per Cron, prüft das Buchungssystem auf Events in den nächsten 4 Tagen, entwirft standortspezifische Posts für jede passende Facebook-Gruppe und legt sie zur Überprüfung vor, bevor irgendetwas live geht.

// 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> {
  // Events aus dem Buchungssystem abrufen
  const upcomingEvents = await fetchUpcomingEvents(env, { daysAhead: 4 });

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

  const drafts: PromoDraft[] = [];

  for (const event of upcomingEvents) {
    // Jedes Event den richtigen FB-Gruppen zuordnen
    const groups = await matchFacebookGroups(event, env);

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

  // Entwürfe in Airtable zur Überprüfung speichern — nichts wird automatisch gepostet
  await saveDraftsForReview(drafts, env);

  // Mich per Slack benachrichtigen
  await notifyOperator(
    `${drafts.length} Promo-Entwürfe zur Überprüfung bereit`,
    env
  );
}

Die Wrangler-Konfiguration:

# wrangler.toml
[[triggers]]
crons = ["0 18 * * 0"]  # Jeden Sonntag um 18 Uhr UTC

Beachte, was der geplante Agent kann, was der ereignisgesteuerte nicht kann: Er iteriert über mehrere Events, schreibt in eine Datenbank und sendet eine Zusammenfassungsbenachrichtigung. Er erledigt Batch-Arbeit. Der ereignisgesteuerte Agent muss schlank bleiben und schnell antworten.

Geplant: das tägliche Briefing

Jeden Morgen um 7 Uhr läuft mein Daily-Brief-Agent. Er holt nächtliche E-Mails, meinen Kalender, Top-Aufgaben und alle Nachrichten, die ich als relevant markiert habe. Er formatiert alles in ein einzelnes Dokument und legt es in meinen AI-Workspace-Ordner.

Dieser ist reines Scheduling. Es gibt kein Ereignis, das ihn auslösen würde – ich möchte ihn einfach jeden Morgen, bevor ich anfange zu arbeiten.

// 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 * * *"]  # Jeden Tag um 7 Uhr UTC

Das parallele Promise.all ist bewusst gewählt. Geplante Agenten haben keinen wartenden Menschen – sollten aber trotzdem nicht langsamer sein als nötig. Alle Datenquellen parallel abrufen, dann einmalig die KI-Synthese durchführen.

Wann ereignisgesteuerte Agenten scheitern

Das häufigste Fehlermuster: jemand baut einen ereignisgesteuerten Agenten, der zu viel im Handler macht.

Eine Buchung kommt rein. Der Agent holt das Kundenprofil, reichert es von drei externen APIs an, führt ein Personalisierungsmodell aus, schreibt ins CRM, sendet die Bestätigungs-E-Mail und aktualisiert ein Dashboard. Das Ganze dauert 45 Sekunden. Die Buchungsplattform versucht es erneut, weil sie nicht schnell genug ein 200 erhielt. Jetzt läuft der Agent zweimal.

Die Lösung ist dieselbe wie beim Social-Reply-Agenten: sofort 200 zurückgeben, das Event in eine Queue schieben, den Queue-Consumer die schwere Arbeit asynchron erledigen lassen.

Das andere Fehlermuster: ereignisgesteuert für Arbeit nutzen, die eigentlich periodisch ist. “Wöchentliche Zusammenfassung senden” ist kein Ereignis. Das nicht an einen synthetischen Cron-Webhook koppeln – einen richtigen geplanten Trigger verwenden.

Wann geplante Agenten scheitern

Geplante Agenten scheitern, wenn die Arbeit eigentlich latenzempfindlich ist. Wenn ein Benutzer ein Formular abschickt und der verarbeitende Agent auf einem 5-Minuten-Cron läuft, starrt der Benutzer bis zu 5 Minuten auf einen Spinner. Das ist kein geplanter Job – das ist ein langsamer ereignisgesteuerter Job, der vorgibt, geplant zu sein.

Der andere Fehler: geplante Agenten, die sich zu unbegrenzter Arbeit ausdehnen. Wenn der Cron jede Minute läuft und jede Ausführung Hunderte von Datensätzen verarbeiten kann, sind Cloudflares CPU-Limits schnell erreicht. Entweder das Cron-Intervall verlängern, eine Queue hinzufügen, um die Arbeit pro Ausführung zu begrenzen, oder auf Durable Objects für lang laufende Koordination wechseln.

Muster mischen: die Buchungs-Pipeline

Manche Workflows brauchen wirklich beide Muster. Die Pickleland-Buchungs-Pipeline funktioniert so:

1. Ereignisgesteuert: Neue-Buchung-Webhook → Buchung bestätigen, Quittung an Kunden senden, Verfügbarkeit aktualisieren. Muss in unter 10 Sekunden abgeschlossen sein.
2. Geplant: Jeden Sonntag → alle Buchungen der vergangenen Woche prüfen, Zusammenfassungsbericht erstellen, Anomalien markieren (doppelte Buchungen, ungewöhnliche Stornierungsraten).

Gleiche Domäne, zwei Muster, zwei Agenten. Der ereignisgesteuerte besitzt die Echtzeit-Benutzererfahrung. Der geplante besitzt die wöchentliche Betriebsüberprüfung. Sie teilen eine Datenbank, aber nichts anderes.

Nicht versuchen, sie in einen einzigen Agenten zu kombinieren, der “alles macht.” Das Ergebnis wäre etwas, das für Events zu langsam und für Batch-Arbeit zu sehr an den Echtzeit-Flow gekoppelt ist.

Cloudflare Workers: warum es die richtige Infrastruktur für beide ist

Cloudflare Workers handhabt beide Muster nativ:

• fetch-Handler → ereignisgesteuert (Webhooks, API-Aufrufe)
• scheduled-Handler → cron-basiert (über [[triggers]] in wrangler.toml)
• queue-Consumer → asynchrone Verarbeitung, entkoppelt von der HTTP-Schicht

Das Edge-Deployment bedeutet, dass ereignisgesteuerte Agenten global schnell antworten. Der kostenlose Tier ist großzügig genug, um beide Muster ohne Kosten zu prototypen. Und die einheitliche wrangler.toml-Konfiguration bedeutet, dass man keine zwei separaten Infrastruktur-Setups für zwei Muster verwaltet.

Das Einzige, was Workers nicht gut löst: Agenten, die länger als ein paar Minuten laufen müssen. Dafür Durable Objects nutzen oder an ein länger laufendes Backend auslagern.

Das Fazit des Operators

Das Muster festlegen, bevor eine einzige Zeile Agenten-Code geschrieben wird. Ereignisgesteuert für alles, worauf ein Mensch wartet; geplant für alles, was nach einer Uhr läuft. Ereignisgesteuerte Handler schlank halten – schnell zurückgeben, Arbeit einqueuen. Geplante Agenten parallel halten – nicht serialisieren, was parallelisiert werden kann. Die Architektur ist einfach. Sie zu verletzen ist die Quelle von Komplexität.