ब्लॉग · गाइड · 28 अक्टूबर 2026
AEGIS के साथ शेड्यूल किया गया एजेंट चलाएँ: शेड्यूल, रन और कोई रन विफल हो तो आप क्या देखते हैं
खुलासा: AEGIS को 100monkeys.ai बनाता है, इसलिए इस गाइड को निर्माता का विवरण मानकर पढ़ें। इसका मसौदा हमारे एक AI एजेंट ने AEGIS के सार्वजनिक दस्तावेज़ों से तैयार किया, मुख्यतः Schedules पन्ने और Schedule Tools रेफ़रेंस से, और कंपनी ने इसकी समीक्षा की; यह हिन्दी संस्करण मूल अंग्रेज़ी गाइड का अनुवाद है। नीचे का हर फ़ील्ड, route और संदेश उन्हीं पन्नों से उद्धृत है, अंग्रेज़ी में और साथ में अनुवाद। इस गाइड के लिए हमने ये कॉल नहीं चलाए, और जहाँ डॉक्स कोई चरण खुला छोड़ते हैं, वहाँ हम यह बताते हैं।
AEGIS by 100monkeys.ai, in beta, एक सेल्फ़-होस्टेड ऑर्केस्ट्रेटर है जो स्वायत्त एजेंटों को अलग-थलग, नीति से नियंत्रित रनटाइम में चलाता है। यह गाइड आपके एक एजेंट को टाइमर पर रखती है, हर ट्रिगर ने क्या किया यह वापस पढ़ती है, और ट्रिगर के चार संभावित नतीजे दिखाती है, ताकि जो रन नहीं हुआ वह भी उतना ही दिखे जितना वह जो हुआ।
शेड्यूल क्या है
डॉक्स इसे एक वाक्य में परिभाषित करते हैं: "A schedule starts one of your agents or workflows as you, either once at a time you choose or again and again on a recurrence." (शेड्यूल आपके किसी एजेंट या वर्कफ़्लो को आपकी ओर से शुरू करता है, या तो आपके चुने समय पर एक बार, या किसी आवृत्ति पर बार-बार।) इससे तीन बातें निकलती हैं, और हर एक नीचे के चरणों को आकार देती है।
- शेड्यूल आपकी अपनी वस्तु है, "never a field of the agent or workflow it runs" (कभी उस एजेंट या वर्कफ़्लो का फ़ील्ड नहीं जिसे वह चलाता है)।
- यह एक इंसान के रूप में चलता है। "A schedule always runs as a person. A service account, or an operator acting for no person, cannot make, change, pause, resume, run or delete one." (शेड्यूल हमेशा एक इंसान के रूप में चलता है। सर्विस अकाउंट, या किसी इंसान की ओर से काम न करने वाला ऑपरेटर, उसे न बना सकता है, न बदल सकता है, न रोक सकता है, न फिर शुरू कर सकता है, न चला सकता है, न मिटा सकता है।)
- हर ट्रिगर एक सामान्य रन है। "At each fire the orchestrator starts the run exactly as
aegis.task.executeoraegis.workflow.runwould for you, with the schedule's intent, input and connections." (हर ट्रिगर पर ऑर्केस्ट्रेटर रन ठीक वैसे ही शुरू करता है जैसे आपके लिएaegis.task.executeयाaegis.workflow.runकरते, शेड्यूल के उद्देश्य, इनपुट और कनेक्शन के साथ।)
चरण 1. एजेंट और समय चुनें
ऐसा एजेंट लें जिसे आप पहले एक बार हाथ से aegis task execute <AGENT> से चला चुके हैं, ताकि आपको पता हो कि अच्छा रन कैसा दिखता है।
फिर दो तरह के समय में से एक चुनें। आप ठीक एक ही देते हैं।
- एक बार:
at, एक RFC 3339 समय, "at least one minute from now and at most a year ahead" (अब से कम से कम एक मिनट बाद और अधिकतम एक साल आगे)। - बार-बार:
recurrence,cron,timezoneऔरjitter_secondsके साथ। cron में पाँच फ़ील्ड होते हैं (मिनट, घंटा, महीने का दिन, महीना, हफ़्ते का दिन), "no seconds field and no@daily-style shorthand" (सेकंड का कोई फ़ील्ड नहीं और@dailyजैसा कोई शॉर्टहैंड नहीं)। टाइम ज़ोन एक IANA नाम है और डिफ़ॉल्टUTCहै। jitter हर रन को उतने सेकंड तक की किसी यादृच्छिक देरी से टालता है, अधिकतम 3600।
योजना में रखने लायक दो सीमाएँ: "A schedule runs at most once every 5 minutes" (शेड्यूल अधिकतम हर 5 मिनट में एक बार चलता है), और आपके पास अधिकतम 25 ऐसे शेड्यूल हो सकते हैं जो मिटाए न गए हों।
चरण 2. चुनें कि रन किन चीज़ों तक पहुँच सकता है
शेड्यूल किया गया रन सिर्फ़ उन्हीं कनेक्शन तक पहुँचता है जिनका नाम उसके profile या contexts में हो, और "a schedule with neither reaches none of your connections." (जिस शेड्यूल में दोनों में से कुछ नहीं, वह आपके किसी कनेक्शन तक नहीं पहुँचता।) शेड्यूल में एक या दूसरा होता है, दोनों कभी नहीं। अगर आपका एजेंट मेल या कोई रिपॉज़िटरी पढ़ता है, तो प्रोफ़ाइल का नाम अभी दें; वरना ट्रिगर किसी कनेक्शन के न होने पर अस्वीकृत होगा, और अस्वीकृति यही बताएगी।
चरण 3. शेड्यूल बनाएँ
CLI Reference में aegis schedule नाम का कोई शेल कमांड नहीं है। शेड्यूल आप REST route POST /v1/schedules (scope schedule:write) से, MCP टूल aegis.schedule.create से, या Zaru के Schedules पन्ने से बनाते हैं। टूल ये आर्ग्युमेंट लेता है, जैसे रेफ़रेंस इन्हें गिनाता है:
aegis.schedule.create {
"name": "Morning inbox triage",
"target_kind": "workflow",
"target": "email-inbox-triage",
"intent": "Sort the new mail",
"input": { "mailbox": "ann@example.com" },
"recurrence": { "cron": "*/30 * * * *", "timezone": "UTC", "jitter_seconds": 300 }
}
यह उदाहरण डॉक्स का अपना शेड्यूल है। target_kind को agent और target को अपने एजेंट के नाम में बदलें। जवाब {"schedule": {...}} है, उसके state, next_run_at और last_run के साथ। जाने से पहले next_run_at वापस पढ़ लें।
चरण 4. इसे एक बार, अभी चलाएँ
यह जानने के लिए कि यह काम करता है, पहले तय समय का इंतज़ार न करें। मालिक POST /v1/schedules/{id}/run या aegis.schedule.run_now से तुरंत एक रन शुरू कर सकता है। यह चलता है "exactly as a fire starts it: as the owner, with the schedule's target, input, connections or profile, and attachments" (ठीक वैसे जैसे ट्रिगर उसे शुरू करता है: मालिक के रूप में, शेड्यूल के लक्ष्य, इनपुट, कनेक्शन या प्रोफ़ाइल, और अटैचमेंट के साथ), और "nothing else changes" (और कुछ नहीं बदलता): शेड्यूल की स्थिति और समय वही रहते हैं।
चरण 5. रन पढ़ें
aegis.schedule.runs { "schedule_id": "<id>", "limit": 20 }
route है GET /v1/schedules/{id}/runs?limit=। रन सबसे नए से शुरू होकर आते हैं, हर एक के साथ scheduled_time (अभी शुरू किए रन के लिए null), fired_at, outcome, detail और execution (उसका id, kind और status)। रन को ख़ुद पढ़ने के लिए execution id को CLI में ले जाएँ: aegis task logs <EXECUTION_ID>, और सिर्फ़ विफलताएँ देखनी हों तो --errors-only के साथ।
चरण 6. चार नतीजे जानें
हर ट्रिगर हर तय समय के लिए एक बार दर्ज होता है, इसलिए जिस ट्रिगर को Temporal दोहराता है, वह "answers the first fire's record instead of starting a second run" (दूसरा रन शुरू करने के बजाय पहले ट्रिगर का रिकॉर्ड लौटाता है)। हर रिकॉर्ड का एक ही नतीजा होता है:
started: रन शुरू हुआ, और ट्रिगर उसका execution id दर्ज करता है।skipped_overlap: "The run the previous fire started is still running, so this fire starts nothing." (पिछले ट्रिगर का शुरू किया रन अभी चल रहा है, इसलिए यह ट्रिगर कुछ शुरू नहीं करता।) Zaru इसे "Skipped: the last run was still running" (छोड़ा गया: पिछला रन अभी चल रहा था) के रूप में दिखाता है।skipped_paused: शेड्यूल रुका हुआ है।refused: "The run could not start. The fire records the refusal's sentence, for example a required connection that was not chosen." (रन शुरू नहीं हो सका। ट्रिगर अस्वीकृति का वाक्य दर्ज करता है, जैसे कोई ज़रूरी कनेक्शन जो चुना नहीं गया था।)
started नतीजा बताता है कि रन शुरू हुआ, यह नहीं कि वह सफल हुआ। रन की अपनी स्थिति execution.status में है, और विफलता का कारण उसके लॉग में।
चरण 7. जानें कि ट्रिगर बार-बार विफल हों तो क्या होता है
"When the last three fires of a recurring schedule were all refused, the schedule pauses itself, with the reason 'Paused after three runs could not start: <the last refusal>.'" (जब किसी आवर्ती शेड्यूल के आख़िरी तीनों ट्रिगर अस्वीकृत हुए हों, तो शेड्यूल ख़ुद को बताए गए कारण के साथ रोक देता है।) शेड्यूल पर paused_reason पढ़ें, कारण ठीक करें, फिर aegis.schedule.resume से दोबारा शुरू करें। ऑर्केस्ट्रेटर के रीस्टार्ट के दौरान छूटा ट्रिगर "is still made up to 10 minutes late; later than that, the time is skipped." (10 मिनट तक की देरी से फिर भी चलाया जाता है; उससे ज़्यादा देर हो तो वह समय छोड़ दिया जाता है।)
चरण 8. अनुमोदन अब भी लागू होते हैं
शेड्यूल किया गया रन आपकी ओर से काम करता है, "so every tool call that waits for your approval in a conversation waits for it in a scheduled run too" (इसलिए जो भी टूल कॉल बातचीत में आपके अनुमोदन का इंतज़ार करता है, वह शेड्यूल किए रन में भी इंतज़ार करता है)। Zaru में अनुरोध Approvals पन्ने पर "From your schedule <name>" (आपके शेड्यूल <नाम> से) के रूप में दिखता है।
डॉक्स क्या खुला छोड़ते हैं
- शेल कमांड। CLI Reference में शेड्यूल का कोई सबकमांड नहीं है, इसलिए सेल्फ़-होस्ट करने वाले REST route या MCP क्लाइंट इस्तेमाल करते हैं।
- लोकल स्टैक पर "आप" कौन हैं। शेड्यूल एक इंसान के रूप में चलते हैं और उन्हें
schedule:writeचाहिए, जबकिaegis initवाला स्टैक बिना IAM के चलता है। डॉक्स यह नहीं बताते कि वहाँ शेड्यूल का मालिक कौन होता है; हमने इसे परखा नहीं।
आगे
शेड्यूल किए एजेंट और उसके भेजे हर संदेश के बीच एक इंसान रखने के लिए पढ़ें ऑर्केस्ट्रेटर को अनुमोदन का चरण कैसे दें। किसी रन ने क्या किया, यह पढ़ने के लिए देखें AEGIS का execution लॉग पढ़ना।