इवेंट-ट्रिगर्ड बनाम शेड्यूल्ड एजेंट्स: किस काम के लिए कौन सा पैटर्न

विषय सूची

मई 2026 में अपडेट किया गया।

TL;DR: इवेंट-ट्रिगर्ड एजेंट्स तब उपयोग करें जब यूज़र एक्शन को तुरंत प्रतिक्रिया चाहिए — कुछ सेकंड से ज़्यादा की देरी अनुभव को तोड़ देती है। शेड्यूल्ड एजेंट्स बैच या आवधिक काम के लिए उपयोग करें जहाँ समय का अनुमान लगाया जा सके। बाधा: इवेंट-ट्रिगर्ड एजेंट्स stateless और तेज़ होने चाहिए; शेड्यूल्ड एजेंट्स stateful और धीमे हो सकते हैं।

[ऑपरेटर का नज़रिया] मैं अपने कंसल्टिंग ब्रांड और Pickleland — Pflugerville, TX में एक पिकलबॉल सुविधा — के लिए 30+ प्रोडक्शन एजेंट्स चलाता हूँ। इनमें से हर एक दो पैटर्न में से किसी एक में आता है: एक इवेंट पर फायर होता है, या एक घड़ी पर। यहाँ गलती करना पैसे बर्बाद करता है और टूटे हुए अनुभव देता है।

दो पैटर्न सरल भाषा में

इवेंट-ट्रिगर्ड एजेंट जागता है क्योंकि कुछ हुआ। एक बुकिंग आई। एक कमेंट पोस्ट हुआ। एक फॉर्म सबमिट हुआ। ट्रिगर बाहरी है और समय में अप्रत्याशित है। काम: तेज़ी से जवाब देना।

शेड्यूल्ड एजेंट जागता है क्योंकि घड़ी ने कहा। हर सुबह 7 बजे। हर रविवार शाम 6 बजे। हर घंटे के ठीक ऊपर। ट्रिगर आंतरिक है और पूरी तरह पूर्वानुमानित है। काम: गहन कार्य करना।

बस इतना ही। जटिल मत बनाओ। आर्किटेक्चर एक सवाल के जवाब से आता है: क्या यूज़र या सिस्टम को अभी तुरंत जवाब चाहिए, या किसी निश्चित समय तक रुक सकते हैं?

इवेंट-ट्रिगर्ड: सोशल रिप्लाई एजेंट

मेरा सोशल रिप्लाई एजेंट तब फायर होता है जब कोई मॉनिटर किए गए Facebook पोस्ट पर नया कमेंट आता है। एजेंट कमेंट पढ़ता है, इरादे को classify करता है (सवाल, शिकायत, तारीफ, spam), जवाब draft करता है और पोस्ट करता है — या अगर confidence कम हो तो human review के लिए flag करता है।

पूरा राउंड ट्रिप 30 सेकंड से कम में खत्म होना चाहिए नहीं तो जवाब बासी लगता है। यह एक इवेंट-ट्रिगर्ड समस्या है।

यहाँ एक simplified Cloudflare Worker है जो social monitoring service के webhook को handle करता है:

// 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 signature verify करें
    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;

    // classify करें और reply करें — 200 जल्दी return करने के लिए async रखें
    env.REPLY_QUEUE.send(event);

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

// Queue consumer — असली AI काम करता है
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();
    }
  };

दो बातें ध्यान देने योग्य हैं। पहली, fetch handler तुरंत 200 return करता है और असली काम queue को सौंपता है। यह webhook response को तेज़ रखता है और monitoring service को retry करने से रोकता है। दूसरी, queue consumer असली AI call करता है — classify और draft — बिना open HTTP connection के समय दबाव के।

शेड्यूल्ड: Pickleland इवेंट प्रमोटर

Pickleland courts और events manage करता है। हर हफ्ते, किसी को आगामी events को सही Facebook groups में push करना होता है ताकि seats भर सकें। यह pure periodic batch काम है — इसे कोई user action trigger नहीं करता, और इसे real-time में होने की ज़रूरत नहीं है।

Pickleland इवेंट प्रमोटर cron पर चलता है, अगले 4 दिनों में events के लिए booking system check करता है, हर matched Facebook group के लिए venue-specific posts draft करता है, और उन्हें मेरी review के लिए present करता है — 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> {
  // booking system से events fetch करें
  const upcomingEvents = await fetchUpcomingEvents(env, { daysAhead: 4 });

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

  const drafts: PromoDraft[] = [];

  for (const event of upcomingEvents) {
    // हर event को सही FB groups से match करें
    const groups = await matchFacebookGroups(event, env);

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

  // review के लिए Airtable में drafts save करें — कुछ automatically post नहीं होता
  await saveDraftsForReview(drafts, env);

  // Slack पर मुझे notify करें
  await notifyOperator(
    `${drafts.length} promo drafts review के लिए तैयार`,
    env
  );
}

wrangler config जो सब जोड़ता है:

# wrangler.toml
[[triggers]]
crons = ["0 18 * * 0"]  # हर रविवार शाम 6 बजे UTC

ध्यान दें कि scheduled agent क्या कर सकता है जो event-triggered नहीं कर सकता: कई events पर iterate करना, database में लिखना, और summary notification भेजना। यह batch काम कर रहा है। इवेंट-ट्रिगर्ड एजेंट को lean रहना और तेज़ respond करना होता है।

शेड्यूल्ड: डेली ब्रीफ

हर सुबह 7 बजे मेरा daily brief agent चलता है। यह overnight emails, मेरी calendar, top tasks, और जो news मैंने relevant mark की है वो fetch करता है। सब कुछ एक document में format करता है और AI Workspace folder में डालता है।

यह pure scheduled है। कोई event नहीं है जो इसे trigger करे — मैं बस इसे हर सुबह काम शुरू करने से पहले चाहता हूँ।

// 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 * * *"]  # हर दिन सुबह 7 बजे UTC

parallel Promise.all जानबूझकर है। Scheduled agents के पास इंतज़ार करता हुआ इंसान नहीं होता — लेकिन फिर भी ज़रूरत से ज़्यादा slow नहीं होने चाहिए। सभी data sources को parallel में fetch करो, फिर एक बार AI synthesis करो।

इवेंट-ट्रिगर्ड कब fail होते हैं

सबसे आम failure mode: कोई एक event-triggered agent बनाता है जो handler में बहुत ज़्यादा काम करता है।

एक बुकिंग आती है। एजेंट customer profile fetch करता है, तीन external APIs से enrich करता है, personalization model चलाता है, CRM में लिखता है, confirmation email भेजता है, और dashboard update करता है। पूरी चीज़ 45 सेकंड लेती है। Booking platform retry करता है क्योंकि उसे जल्दी 200 नहीं मिला। अब एजेंट दो बार चलता है।

ठीक करें — social reply agent की तरह: तुरंत 200 return करें, event को queue में push करें, queue consumer को async में heavy lifting करने दें।

दूसरा failure mode: event-triggered का उपयोग ऐसे काम के लिए जो actually periodic है। “Weekly summary भेजना” कोई event नहीं है। इसे synthetic cron webhook से मत जोड़ो — proper scheduled trigger use करो।

शेड्यूल्ड कब fail होते हैं

Scheduled agents fail होते हैं जब काम actually latency-sensitive हो। अगर एक user form submit करे और उसे process करने वाला agent 5-minute cron पर चले, तो user 5 मिनट तक spinner देखता रहेगा। यह scheduled job नहीं है — यह slow event-triggered job है जो scheduled होने का नाटक कर रहा है।

दूसरी failure: scheduled agents जो unbounded काम तक फैल जाते हैं। अगर cron हर मिनट चले और हर invocation सैकड़ों records process करे, तो Cloudflare के CPU limits जल्दी hit होंगे। या तो cron interval बढ़ाओ, per invocation काम bound करने के लिए queue जोड़ो, या long-running coordination के लिए Durable Objects में switch करो।

पैटर्न मिलाना: बुकिंग pipeline

कुछ workflows को genuinely दोनों की ज़रूरत होती है। Pickleland booking pipeline इस तरह काम करती है:

1. इवेंट-ट्रिगर्ड: नई booking webhook → booking confirm करो, customer को receipt भेजो, availability update करो। 10 सेकंड से कम में complete होना चाहिए।
2. शेड्यूल्ड: हर रविवार → पिछले हफ्ते की सभी bookings review करो, summary report बनाओ, anomalies flag करो (duplicate bookings, unusual cancellation rates)।

Same domain, दो patterns, दो agents। Event-triggered real-time user experience का मालिक है। Scheduled weekly operations review का मालिक है। वे एक database share करते हैं लेकिन और कुछ नहीं।

इन्हें एक agent में combine करने की कोशिश मत करो जो “सब कुछ करे।” आप किसी ऐसी चीज़ के साथ खत्म होंगे जो events के लिए बहुत slow है और batch काम के लिए real-time flow से बहुत coupled है।

Cloudflare Workers: दोनों के लिए सही infrastructure क्यों

Cloudflare Workers दोनों patterns को natively handle करता है:

• fetch handler → event-triggered (webhooks, API calls)
• scheduled handler → cron-based (wrangler.toml में [[triggers]] के ज़रिए)
• queue consumer → HTTP layer से decoupled async processing

Edge deployment का मतलब है कि event-triggered agents globally तेज़ respond करते हैं। Free tier दोनों patterns prototype करने के लिए बिना कुछ खर्च किए काफी generous है। और unified wrangler.toml config का मतलब है कि आप दो patterns के लिए दो अलग infrastructure setups manage नहीं कर रहे।

एक चीज़ जो Workers अच्छी तरह solve नहीं करता: agents जिन्हें कुछ मिनटों से ज़्यादा चलना हो। उनके लिए Durable Objects या longer-running backend का सहारा लें।

ऑपरेटर की निष्कर्ष

Agent code की एक भी line लिखने से पहले अपना pattern चुनें। Event-triggered हर उस चीज़ के लिए जिसका एक इंसान इंतज़ार कर रहा हो; scheduled हर उस चीज़ के लिए जो clock पर चले। Event-triggered handlers को lean रखो — तेज़ return करो, काम queue करो। Scheduled agents को parallel रखो — जो parallelize हो सकता है उसे serialize मत करो। Architecture simple है। इसे तोड़ना ही complexity का स्रोत है।