आपका एजेंट तब शुरू होता है जब
सचमुच कुछ होता है
एक ट्रिगर एक ही सवाल का जवाब देता है: यह एजेंट कब शुरू होता है? एक शेड्यूल किया गया टास्क एक समय बताकर जवाब देता है। एक webhook ट्रिगर बाहरी दुनिया के एक इवेंट से जवाब देता है। एक पुल रिक्वेस्ट खुलती है, एक बिल्ड टूटता है, एक अलर्ट जाता है, और एजेंट पहले से चल रहा होता है।
AgentsRoom हर ट्रिगर को एक सार्वजनिक URL और एक साइनिंग सीक्रेट देता है। उस URL को GitHub, GitLab, Slack, Linear, Sentry या JSON POST भेज सकने वाली किसी भी चीज़ में पेस्ट करें। अनुरोध आता है, हस्ताक्षर सत्यापित होता है, payload आपके प्रॉम्प्ट के वेरिएबल बन जाता है, और आपके प्रोजेक्ट में एक असली एजेंट शुरू होता है, अपने टर्मिनल और अपने ट्रांसक्रिप्ट के साथ।
एक ट्रिगर, एक सार्वजनिक URL। इवेंट आता है, हस्ताक्षर जाँचा जाता है, payload प्रॉम्प्ट वेरिएबल बन जाता है, और आपके प्रोजेक्ट में एक एजेंट शुरू होता है।
Scheduled Tasks ने आधी समस्या हल कर दी। आप पहले से किसी एजेंट से कह सकते हैं कि हर सुबह 8 बजे पुल रिक्वेस्ट की समीक्षा करे। लेकिन जो काम आप किसी एजेंट को सौंपना चाहेंगे, उसमें से ज़्यादातर 8 बजे नहीं होता: वह तब होता है जब कोई पुल रिक्वेस्ट खोलता है, जब बिल्ड लाल हो जाता है, जब कोई ग्राहक दोपहर 2 बजे एक बग दर्ज करता है।
अब तक इसे पकड़ने का एकमात्र तरीक़ा था किसी एजेंट से निगरानी करवाना: उसे छोटे शेड्यूल पर चलाएँ, उससे API पोल करवाएँ, पुछवाएँ 'कुछ नया है?', और दिन में कई सौ बार 'नहीं' जवाब के लिए टोकन चुकाएँ। यह महँगा है, प्रतिक्रिया में धीमा है, और जैसे ही आप तीन रिपॉज़िटरी पर नज़र रखना चाहें, यह ठीक से स्केल नहीं करता।
एक webhook ट्रिगर इसे उलट देता है। सेवा ख़ुद आपको बताती है। AgentsRoom आपको एक URL देता है, आप उसे GitHub, GitLab, Slack, Linear, Sentry या अपने CI में पेस्ट करते हैं, और जब तक वह सेवा अनुरोध नहीं भेजती तब तक कुछ नहीं चलता। जब वह भेजती है, एजेंट उस इवेंट के साथ शुरू होता है जो पहले से उसके प्रॉम्प्ट में है। दिन शांत रहे तो शून्य टोकन, और न रहे तो सेकंडों में एक एजेंट काम पर।
एक इवेंट पोलिंग लूप से बेहतर क्यों है
आप ख़ामोशी के पैसे देना बंद कर देते हैं। हर पाँच मिनट पर रिपॉज़िटरी जाँचने वाला एजेंट हर पाँच मिनट पर कॉन्टेक्स्ट का एक पूरा टर्न जला देता है, और उनमें से लगभग हर टर्न को कुछ नहीं मिलता। एक ट्रिगर इवेंट आने तक ठीक कुछ भी खर्च नहीं करता।
प्रतिक्रिया तुरंत होती है। कोई अंतराल ट्यून नहीं करना, ऐसी कोई खिड़की नहीं जहाँ कोई पुल रिक्वेस्ट ग्यारह मिनट पड़ी रहे क्योंकि पोल अभी-अभी चला था। एजेंट अनुरोध आते ही शुरू हो जाता है, इसलिए लेखक जब पेज रीफ़्रेश करता है तो समीक्षा उसका इंतज़ार कर रही होती है।
इवेंट अपना डेटा साथ लाता है। payload को ऐसे वेरिएबल में पार्स किया जाता है जिन्हें आप सीधे प्रॉम्प्ट में डालते हैं: शीर्षक, लेखक, URL, नंबर, ब्रांच, या पूरा कच्चा JSON। एजेंट को यह ढूँढ़ने नहीं जाना पड़ता कि उसे किसने ट्रिगर किया।
यह वही पैनल है जिसे आप पहले से जानते हैं। ट्रिगर वही सूची, वही चालू और बंद स्विच, वही प्रति-रन इतिहास, वही एजेंट चयन और शेड्यूल किए गए टास्क का वही प्रति-मशीन दायरा रखते हैं। एक webhook बस इस सवाल का एक और जवाब है कि यह कब सक्रिय हो।
एक ट्रिगर, सक्रिय होने के दो तरीके
पैनल दोनों रखता है। वह चुनें जो आपके इंतज़ार से मेल खाता हो।
शेड्यूल किया गया
मूल मोड, अपरिवर्तित। हर N मिनट, प्रति घंटा, दैनिक, साप्ताहिक या मासिक, बिना कोई cron एक्सप्रेशन लिखे। उस काम के लिए जो घड़ी का है: सुबह की समीक्षा, सोमवार की डिपेंडेंसी जाँच, शुक्रवार का चेंजलॉग।
Webhook
एजेंट किसी समय के बजाय किसी इवेंट का इंतज़ार करता है। AgentsRoom आपको एक सार्वजनिक URL और एक साइनिंग सीक्रेट देता है, आप URL को सेवा में पेस्ट करते हैं, और जब वह सेवा POST भेजती है तो ट्रिगर सक्रिय हो जाता है। उस काम के लिए जो किसी घटना का है: एक पुल रिक्वेस्ट, एक फ़ेल हुआ बिल्ड, एक नई बग रिपोर्ट।
क्या ट्रिगर करें
असली इवेंट, और वह एजेंट जिसे आप दूसरी तरफ़ चाहेंगे।
हर पुल रिक्वेस्ट खुलते ही उसकी समीक्षा करें
एक GitHub या GitLab webhook को ट्रिगर पर लगाएँ, पुल रिक्वेस्ट के खुलने पर फ़िल्टर लगाएँ, और सेकंडों में एक समीक्षक एजेंट diff पर काम शुरू कर देता है। लेखक को फ़ीडबैक तब मिलता है जब बदलाव अब भी उसके दिमाग़ में ताज़ा है।
लाल बिल्ड की अपने आप जाँच करें
आपका CI पाइपलाइन फ़ेल होने पर POST भेज सकता है। ट्रिगर एक एजेंट शुरू करता है जिसके प्रॉम्प्ट में ब्रांच और रन का URL होता है, इसलिए वह फ़ेल हुए जॉब को पढ़ता है और एक लाल बैज के बजाय एक कारण लेकर लौटता है।
क्रैश रिपोर्ट होते ही उसका ट्रायाज करें
एक Sentry अलर्ट को ट्रिगर से जोड़ें। प्रोडक्शन में एक नया एक्सेप्शन एक बैकएंड एजेंट शुरू करता है जिसके पास त्रुटि का शीर्षक और टिकट का URL होता है, इसलिए स्टैक ट्रेस पर पहली नज़र किसी के डैशबोर्ड खोलने से पहले ही पड़ जाती है।
Slack से एक एजेंट शुरू करें
एक Slack slash कमांड या एक आउटगोइंग webhook ट्रिगर URL पर आ सकता है। कोई चैनल में अपना अनुरोध टाइप करता है, payload प्रॉम्प्ट में पहुँचता है, और एजेंट उसे सही प्रोजेक्ट में उठा लेता है।
नया टिकट दर्ज होते ही उसका दायरा तय करें
GitHub, GitLab या Linear पर बना एक टिकट एक प्रोडक्ट एजेंट शुरू करता है जो रिपोर्ट पढ़ता है, छूटे हुए सवाल पूछता है और उसे ऐसी चीज़ में बदल देता है जिसे कोई डेवलपर उठा सके।
हर डिप्लॉय के बाद एक QA पास चलाएँ
आपका डिप्लॉय पाइपलाइन रिलीज़ जाते ही POST भेजता है। ट्रिगर एक QA एजेंट शुरू करता है जो अभी-अभी गए वर्ज़न के ख़िलाफ़ ऐप को परखता है, न कि ऐसे शेड्यूल पर जिसका रिलीज़ से कोई लेना-देना नहीं।
टैग पर रिलीज़ नोट्स लिखें
एक टैग पुश हुआ, एक रिलीज़ प्रकाशित हुई, और एक डॉक्युमेंटेशन एजेंट कमिट्स को पठनीय नोट्स में बदल देता है। इवेंट टैग का नाम साथ लाता है, इसलिए एजेंट ठीक-ठीक जानता है कि किस दायरे का सारांश बनाना है।
जो कुछ भी JSON POST कर सके
किसी इंटीग्रेशन सूची का इंतज़ार नहीं करना है। सर्वर पर एक cron, एक Zapier स्टेप, एक मॉनिटरिंग टूल, आपका अपना बैकएंड: अगर वह किसी URL पर हस्ताक्षरित POST भेज सकता है, तो वह आपके प्रोजेक्ट में एक एजेंट शुरू कर सकता है।
एक webhook ट्रिगर कैसे काम करता है, चरण दर चरण
एक ख़ाली फ़ॉर्म से प्रोडक्शन पर प्रतिक्रिया देने वाले एजेंट तक, कुछ ही मिनटों में।
एक ट्रिगर बनाएँ
अपने प्रोजेक्ट पर Triggers पैनल खोलें और एक नया बनाएँ। वही सूची, वही चालू और बंद स्विच, वही इतिहास जो एक शेड्यूल किए गए टास्क का है, क्योंकि यह वही पैनल है।
इसे Webhook पर स्विच करें
Scheduled के बजाय Webhook चुनें। AgentsRoom इस ट्रिगर के लिए एक सार्वजनिक URL और उसके बगल में एक साइनिंग सीक्रेट बनाता है। सीक्रेट जब चाहें दोबारा बनाया जा सकता है, ताकि जिसके पास पुराना था उसका रास्ता कट जाए।
URL को सेवा में पेस्ट करें
इसे किसी GitHub या GitLab webhook, किसी Slack ऐप, किसी Linear या Sentry इंटीग्रेशन, या अपने CI में डालें। सेवा को साइनिंग सीक्रेट भी दें, ताकि वह जो अनुरोध भेजे उन्हें सत्यापित किया जा सके।
छाँटें कि वास्तव में क्या सक्रिय होना चाहिए
एक रिपॉज़िटरी बहुत सारे इवेंट भेजती है। payload पर एक वैकल्पिक शर्त जोड़ें, उदाहरण के लिए action बराबर opened, और बाक़ी सब अनदेखा हो जाता है। एक बर्स्ट सीमा तय करें ताकि कोई शोरगुल वाली सेवा एक मिनट में बीस एजेंट न शुरू कर दे।
इवेंट को अपने प्रॉम्प्ट में डालें
प्रॉम्प्ट को इवेंट के वेरिएबल के साथ लिखें: शीर्षक, लेखक, URL, नंबर, ब्रांच, या पूरा payload। ट्रिगर सक्रिय होने पर ये हल हो जाते हैं, ठीक वैसे ही जैसे तारीख़ और समय के वे वेरिएबल जो शेड्यूल किए गए टास्क पहले से समर्थित करते हैं।
आख़िरी अनुरोध दोबारा भेजें और इसे चालू कर दें
एडिटर दिखाता है कि ट्रिगर को आख़िरी अनुरोध कौन सा मिला था, कच्चा JSON सहित, और एक क्लिक में उसे दोबारा भेज देता है। आप webhook को देखकर जोड़ते हैं, अंदाज़े से नहीं, और सही हो जाने पर ट्रिगर को चालू कर देते हैं।

सेवाओं की यह पंक्ति शॉर्टकट का एक सेट है, कोई अनुमत सूची नहीं। एडिटर चुनने वाली पंक्ति के नीचे यही कहता है, और इसीलिए पहली प्रविष्टि Any service (JSON) है: जो कुछ भी JSON बॉडी POST कर सके वह काम करता है। GitHub, GitLab, Slack, Linear या Sentry चुनने से ठीक दो चीज़ें जुड़ती हैं, सत्यापित करने के लिए उसका अपना हस्ताक्षर हेडर और उसके payload फ़ील्ड जो पहले से इवेंट वेरिएबल से जुड़े होते हैं। सूची में न होने की वजह से कुछ भी ठुकराया नहीं जाता।
वेरिएबल वाले चिप डॉक्युमेंटेशन नहीं, बटन हैं: किसी एक पर क्लिक करके उसे प्रॉम्प्ट में डालें, और जिन्हें आख़िरी अनुरोध ने वाक़ई भरा था वे उभरे हुए दिखते हैं। उनके नीचे वह आख़िरी अनुरोध बैठा होता है जो ट्रिगर को मिला था, इसलिए आप फ़िल्टर और प्रॉम्प्ट को एक असली payload के सामने लिखते हैं जिसे आप देख सकते हैं, उसे दोबारा भेजते हैं, और रन सही निकलने पर ही ट्रिगर चालू करते हैं।
- इवेंट आपके ट्रिगर URL पर आता है
सेवा अपना JSON POST करती है। AgentsRoom आपके सीक्रेट से हस्ताक्षर जाँचता है और बिना हस्ताक्षर वाली हर चीज़ ठुकरा देता है, फिर अगर आपने कोई फ़िल्टर लगाया है तो उसे लागू करता है।
- अगर कोई मौजूद नहीं है तो यह इंतज़ार करता है
आपकी मशीन बंद हो सकती है। इवेंट को गिरा देने के बजाय एक हफ़्ते तक रोक रखा जाता है और अगले लॉन्च पर फिर से भेजा जाता है, ठीक वही कैच-अप मॉडल जो शेड्यूल किए गए टास्क पहले से इस्तेमाल करते हैं।
- एक मशीन इसे लेती है, और सिर्फ़ एकऑफ़िस Macघर का Macबिल्ड मशीन
अगर कई कंप्यूटरों पर प्रोजेक्ट खुला है, तो इवेंट उठाने वाला पहला कंप्यूटर उसे लॉक कर देता है। बाक़ी देखते हैं कि वह लिया जा चुका है और आगे बढ़ जाते हैं, इसलिए एक इवेंट कभी दो एजेंट नहीं बनाता।
- एजेंट चलता है, एक बार
प्रोजेक्ट में एक असली एजेंट खुलता है, आपकी चुनी भूमिका, प्रोवाइडर और मॉडल के साथ, अपने टर्मिनल, अपने कन्वर्सेशन व्यू और एक संग्रहीत ट्रांसक्रिप्ट के साथ जिसे आप बाद में पढ़ सकते हैं।
एक सार्वजनिक URL जो खुला दरवाज़ा नहीं है
URL इंटरनेट से पहुँचा जा सकता है, इसलिए कुछ भी शुरू होने से पहले ट्रिगर तय करता है कि वह क्या स्वीकार करेगा।
हर अनुरोध हस्ताक्षरित होता है
कुछ भी शुरू होने से पहले AgentsRoom हर अनुरोध को आपके सीक्रेट के सामने सत्यापित करता है: GitHub के लिए X-Hub-Signature-256, Slack के लिए X-Slack-Signature, GitLab के लिए साझा टोकन X-Gitlab-Token, और Linear, Sentry व सामान्य स्रोतों के लिए कच्ची बॉडी का एक सादा HMAC। बिना हस्ताक्षर वाला अनुरोध ठुकरा दिया जाता है, इसलिए आपकी मशीन पर एजेंट शुरू करने के लिए URL जान लेना काफ़ी नहीं है।
सीक्रेट जब चाहें बदलें
साइनिंग सीक्रेट एडिटर में दिखता है और वहीं दोबारा बनाया जा सकता है। पुराने अनुरोध तुरंत सत्यापित होना बंद कर देते हैं, और यही आप उस दिन चाहते हैं जब कोई सेवा हटाई जाए या कोई सीक्रेट किसी लॉग में लीक हो जाए।
payload पर फ़िल्टर लगाएँ
एक वैकल्पिक शर्त तय करती है कि इवेंट किसी एजेंट के लायक़ है या नहीं। सिर्फ़ तब सक्रिय हों जब action बराबर opened हो, सिर्फ़ एक ब्रांच पर, सिर्फ़ एक लेबल के लिए। जो मेल नहीं खाता वह बिना कुछ शुरू किए गिरा दिया जाता है।
बर्स्ट सुरक्षा
प्रति समय-खिड़की अधिकतम एक रन। दस सेकंड में तीस इवेंट भेजने वाली सेवा तीस एजेंट शुरू नहीं करती: उस खिड़की के भीतर के अनुरोध समूहबद्ध कर दिए जाते हैं और एक ही रन उन्हें कवर करता है।
payload आपका प्रॉम्प्ट बन जाता है
सेवा जो JSON भेजती है उसे ऐसे वेरिएबल में पार्स किया जाता है जिन्हें आप सीधे प्रॉम्प्ट में लिखते हैं। ये सक्रिय होने के समय हल होते हैं, ठीक वैसे ही जैसे तारीख़ और समय के वे वेरिएबल जो शेड्यूल किए गए टास्क पहले से इस्तेमाल करते हैं।
प्रॉम्प्ट एक बार लिखें, और हर रन को उस इवेंट का डेटा मिलता है जिसने उसे ट्रिगर किया।
{{event.title}}इवेंट का शीर्षक: पुल रिक्वेस्ट का शीर्षक, टिकट का शीर्षक, अलर्ट का नाम।{{event.author}}इसका कारण कौन बना: पुल रिक्वेस्ट का लेखक, वह व्यक्ति जिसने टिकट खोला।{{event.url}}इवेंट पर वापस जाने का लिंक, ताकि एजेंट पुल रिक्वेस्ट या अलर्ट खोल सके।{{event.number}}पुल रिक्वेस्ट या टिकट का नंबर, जब सेवा उसे भेजती है।{{event.branch}}जिस ब्रांच से इवेंट जुड़ा है, किसी push, पुल रिक्वेस्ट या फ़ेल हुए बिल्ड के लिए।{{payload}}पूरा कच्चा JSON, उस सबके लिए जिसे नामित वेरिएबल कवर नहीं करते।
Review pull request #{{event.number}} "{{event.title}}" opened by {{event.author}} on branch {{event.branch}}. Read the diff at {{event.url}} and reply with the risky parts first.वेरिएबल के नाम प्रॉम्प्ट फ़ील्ड में दोहरे घुँघराले कोष्ठक के बीच लिखे जाते हैं, ठीक वैसे ही जैसे किसी शेड्यूल किए गए टास्क के तारीख़ और समय वाले वेरिएबल।
event.actionevent.numberevent.titleevent.bodyevent.authorevent.branchevent.baseevent.urlevent.repositoryevent.stateevent.actionevent.numberevent.titleevent.bodyevent.authorevent.branchevent.baseevent.urlevent.repositoryevent.stateevent.actionevent.titleevent.bodyevent.authorevent.channelevent.urlevent.teamevent.actionevent.numberevent.titleevent.bodyevent.authorevent.assigneeevent.stateevent.priorityevent.urlevent.teamevent.actionevent.titleevent.bodyevent.levelevent.projectevent.urlevent.countevent.actionevent.titleevent.bodyevent.authorevent.urlevent.idवास्तव में क्या चलता है, और कहाँ
शेड्यूल किए गए टास्क वाला वही ईमानदार निष्पादन मॉडल, इवेंट तक बढ़ाया हुआ।
इवेंट कहाँ से आते हैं
JSON बॉडी के साथ हस्ताक्षरित POST भेज सकने वाली कोई भी चीज़ एक एजेंट शुरू कर सकती है। ये वे हैं जिन्हें लोग सबसे पहले जोड़ते हैं।
आपका CI, आपका बैकएंड, कुछ भी
एक पाइपलाइन स्टेप, एक मॉनिटरिंग टूल, एक आंतरिक सेवा, curl वाली एक शेल स्क्रिप्ट। कोई इंटीग्रेशन माँगना नहीं है: JSON बॉडी और एक हस्ताक्षर वाला एक POST, बस यही पूरा अनुबंध है।
GitHub और GitLab
पुल रिक्वेस्ट और मर्ज रिक्वेस्ट का खुलना, समीक्षा होना या मर्ज होना, टिकट बनना, push, रिलीज़, फ़ेल होते वर्कफ़्लो। क्लासिक स्रोत, और सबसे उपयोगी payload वाला।
Slack
एक slash कमांड या एक आउटगोइंग webhook किसी चैनल के संदेश को सही प्रोजेक्ट में एक एजेंट रन में बदल देता है। Slack के हस्ताक्षर X-Slack-Signature से सत्यापित होते हैं।
Linear और Sentry
एक टिकट का किसी कॉलम में जाना, प्रोडक्शन में एक नया एक्सेप्शन, एक रिग्रेशन अलर्ट। ट्रैकर सक्रिय होता है, और एजेंट अपने प्रॉम्प्ट में टिकट या त्रुटि लेकर शुरू होता है।
उसी पैनल का दूसरा आधा हिस्सा
ट्रिगर और शेड्यूल किए गए टास्क एक ही फ़ीचर हैं, जिसमें एक ही सवाल के दो जवाब हैं। एक शेड्यूल किया गया टास्क एक ऐसा ट्रिगर है जिसका इवेंट एक घड़ी है। एक webhook ट्रिगर एक ऐसा शेड्यूल किया गया टास्क है जिसका शेड्यूल बाहरी दुनिया है। वे एक ही सूची में रहते हैं, वही एजेंट कॉन्फ़िगरेशन, वही चालू करने वाला स्विच, वही रन इतिहास और वही प्रति-मशीन दायरा साझा करते हैं।
इसलिए आप टूल के हिसाब से नहीं, काम के हिसाब से चुनते हैं। डिपेंडेंसी ऑडिट सोमवार सुबह पर ही रहता है, क्योंकि बाहर कुछ भी यह घोषणा नहीं करता कि कोई पैकेज पुराना पड़ गया। पुल रिक्वेस्ट की समीक्षा webhook पर चली जाती है, क्योंकि GitHub पहले से जानता है कि यह ठीक किस सेकंड होनी चाहिए। इस परिवार के घड़ी वाले पक्ष के लिए Scheduled Tasks का पेज पढ़ें।
Scheduled Tasks देखें, उसी पैनल का घड़ी वाला पक्षFAQ
AgentsRoom में एक webhook ट्रिगर क्या है?
यह एक ऐसा ट्रिगर है जो किसी तय समय पर नहीं, बल्कि तब एक AI एजेंट शुरू करता है जब कोई बाहरी सेवा उसे एक इवेंट भेजती है। AgentsRoom ट्रिगर को एक सार्वजनिक URL और एक साइनिंग सीक्रेट देता है; आप उस URL को GitHub, GitLab, Slack, Linear, Sentry या JSON POST भेज सकने वाले किसी भी टूल में पेस्ट करते हैं। जब वह सेवा अनुरोध भेजती है, हस्ताक्षर सत्यापित होता है, आपका वैकल्पिक फ़िल्टर लागू होता है, और आपके प्रोजेक्ट में एक एजेंट शुरू होता है जिसके पास payload पहले से प्रॉम्प्ट वेरिएबल के रूप में उपलब्ध होता है।
यह एक शेड्यूल किए गए टास्क से कैसे अलग है?
सिर्फ़ यह सवाल बदलता है कि यह कब सक्रिय हो। एक शेड्यूल किया गया टास्क घड़ी पर सक्रिय होता है: हर N मिनट, प्रति घंटा, दैनिक, साप्ताहिक या मासिक। एक webhook ट्रिगर बाहर से आए इवेंट पर सक्रिय होता है। बाक़ी सब साझा है: वही सूची, वही चालू और बंद स्विच, वही एजेंट कॉन्फ़िगरेशन, वही प्रति-रन इतिहास, वही प्रति-मशीन दायरा।
एजेंट से API पोल ही क्यों न करवाएँ?
क्योंकि पोलिंग हर चक्कर पर टोकन खर्च करती है, और लगभग हर चक्कर को कुछ नहीं मिलता। हर पाँच मिनट पर रिपॉज़िटरी जाँचने वाला एजेंट 'नहीं' कहने के लिए हर पाँच मिनट पर एक पूरा टर्न चलाता है। एक webhook ट्रिगर तब तक कुछ खर्च नहीं करता जब तक कुछ होता नहीं, और जब कुछ होता है तो सेकंडों में प्रतिक्रिया देता है। यही इस फ़ीचर का पूरा आर्थिक तर्क है।
क्या ट्रिगर URL को सार्वजनिक रखना सुरक्षित है?
अकेला URL कुछ भी शुरू करने के लिए काफ़ी नहीं है। हर अनुरोध को यह साबित करना होता है कि वह उसी सेवा से आया है जिसके पास आपका सीक्रेट है: GitHub के लिए X-Hub-Signature-256, Slack के लिए X-Slack-Signature, GitLab के लिए साझा टोकन X-Gitlab-Token, और Linear, Sentry व सामान्य स्रोतों के लिए कच्ची बॉडी का एक सादा HMAC। जिस अनुरोध पर हस्ताक्षर हेडर नहीं है वह ठुकरा दिया जाता है, उसे कभी यूँ ही नहीं जाने दिया जाता। सीक्रेट एडिटर में दिखता है और किसी भी समय दोबारा बनाया जा सकता है, जिससे पुराना इस्तेमाल कर रही हर चीज़ तुरंत अमान्य हो जाती है।
क्या मैं सिर्फ़ कुछ इवेंट पर सक्रिय हो सकता हूँ?
हाँ। एक रिपॉज़िटरी उससे कहीं ज़्यादा इवेंट भेजती है जितनों पर आप एजेंट चाहते हैं, इसलिए एक ट्रिगर payload पर एक वैकल्पिक शर्त लेता है, उदाहरण के लिए action बराबर opened। जो इवेंट मेल नहीं खाते वे अनदेखे रह जाते हैं और कुछ भी शुरू नहीं होता। एक बर्स्ट सीमा भी है: प्रति समय-खिड़की अधिकतम एक रन, और उस खिड़की के भीतर आने वाले अनुरोध एक साथ समूहबद्ध कर दिए जाते हैं।
इवेंट आने पर अगर AgentsRoom बंद हो तो क्या होता है?
इवेंट सर्वर पर कतार में रख दिया जाता है और अगली बार ऐप लॉन्च करने पर फिर से भेजा जाता है, इसलिए वह कभी नहीं चलने के बजाय देर से चलता है। कतार में पड़े इवेंट एक हफ़्ते तक रखे जाते हैं, जो किसी लंबे वीकेंड में बंद पड़े लैपटॉप को कवर कर लेता है, और लौटने पर महीने भर का बासी काम दोबारा नहीं चलता। यह वही इन-ऐप प्लस कैच-अप मॉडल है जो शेड्यूल किए गए टास्क इस्तेमाल करते हैं। Webhook ट्रिगर आपके एजेंट को क्लाउड में नहीं चलाते: एजेंट हमेशा आपकी मशीन पर, आपके प्रोजेक्ट में चलता है।
मेरे पास प्रोजेक्ट दो कंप्यूटरों पर खुला है। क्या एजेंट दो बार चलेगा?
नहीं। एक इवेंट एक ही बार खपता है। उसे उठाने वाली पहली मशीन उसे लॉक कर देती है, और बाक़ी देखती हैं कि वह लिया जा चुका है और उसे छोड़ देती हैं। आप चाहें तो किसी ट्रिगर को ख़ास मशीनों पर पिन भी कर सकते हैं, ठीक एक शेड्यूल किए गए टास्क की तरह, अगर आप चाहते हैं कि कोई एक कंप्यूटर ही उसका ज़िम्मेदार हो।
इवेंट से मैं प्रॉम्प्ट में क्या डाल सकता हूँ?
payload को ऐसे वेरिएबल में पार्स किया जाता है जिन्हें आप सीधे प्रॉम्प्ट फ़ील्ड में, दोहरे घुँघराले कोष्ठक के बीच लिखते हैं: event.title, event.author, event.url, event.number, event.branch, और पूरे कच्चे JSON के लिए payload। ट्रिगर सक्रिय होने पर ये हल हो जाते हैं, ठीक वैसे ही जैसे किसी शेड्यूल किए गए टास्क के तारीख़ और समय वाले वेरिएबल।
मुझे कैसे पता चलेगा कि मेरा webhook सही जुड़ा है?
एडिटर दिखाता है कि ट्रिगर को आख़िरी अनुरोध कौन सा मिला था, कच्ची JSON बॉडी सहित, और उसे एक क्लिक में दोबारा भेजने देता है। इसलिए आप फ़िल्टर और प्रॉम्प्ट को एक असली payload के सामने कॉन्फ़िगर करते हैं जिसे आप देख सकते हैं, फिर रन सही होने तक उसे दोबारा भेजते रहते हैं, न कि पता लगाने के लिए टेस्ट कमिट पुश करते हैं।
कौन सी सेवाएँ समर्थित हैं?
कोई भी सेवा जो JSON बॉडी के साथ हस्ताक्षरित POST भेज सके। GitHub, GitLab, Slack, Linear और Sentry वे हैं जिन्हें लोग सबसे पहले जोड़ते हैं, क्योंकि उनके payload समृद्ध हैं, लेकिन कोई अनुमत सूची नहीं है: एक CI जॉब, एक मॉनिटरिंग टूल, आपका अपना बैकएंड या किसी शेल स्क्रिप्ट का curl बिल्कुल उसी तरह काम करते हैं।
क्या यह मल्टी-स्टेप सिनेरियो वाला एक विज़ुअल ऑटोमेशन बिल्डर है?
नहीं, और यह ऐसा बनने की कोशिश भी नहीं कर रहा। एक ट्रिगर का एक ही काम है: तय करना कि एजेंट कब शुरू हो और उसे इवेंट सौंप देना। मल्टी-स्टेप हिस्सा ख़ुद एजेंट है, जो कोड पढ़ता है, टूल चलाता है और काम करता है। अगर आप चाहते हैं कि कई एजेंट एक-दूसरे को काम सौंपें, तो वह Teams है, कोई सिनेरियो कैनवास नहीं।
क्या AgentsRoom दूसरी सेवाओं को webhook भेज सकता है?
ट्रिगर सिर्फ़ इनबाउंड हैं: AgentsRoom इवेंट प्राप्त करता है, भेजता नहीं। अगर आप चाहते हैं कि कोई एजेंट रन के अंत में किसी बाहरी सेवा को कॉल करे, तो यह ख़ुद एजेंट का काम है, उन टूल और MCP सर्वरों के साथ जो आपने उसे दिए हैं।
इसके साथ अच्छा चलता है
Scheduled Tasks
उसी पैनल का घड़ी वाला पक्ष। हर N मिनट, प्रति घंटा, दैनिक, साप्ताहिक या मासिक, बिना कोई cron एक्सप्रेशन लिखे।
Backlog टास्क बोर्ड
एक टिकट को किसी कॉलम में खींचें और एक एजेंट उसे उठा लेता है। एक ट्रिगर वही करता है, बस खींचने का काम कोई बाहरी इवेंट करता है।
एजेंट टीम
Dev, QA और PM एजेंट जो एक-दूसरे को काम सौंपते हैं। किसी ट्रिगर को एक टीम पर लगाएँ और एक इवेंट पूरा रूटीन शुरू कर देता है।
AgentsRoom MCP
वे टूल जिनसे एक एजेंट बैकलॉग, मेमोरी और प्रॉम्प्ट लाइब्रेरी पढ़ता है। ट्रिगर से शुरू हुए एजेंट को भी ये किसी और एजेंट की तरह ही मिलते हैं।
एजेंट सूचनाएं
ट्रिगर के सक्रिय होते ही जान जाएँ, डेस्कटॉप पर और अपने फ़ोन पर, और एक टैप से उस एजेंट को खोलें जो उसने शुरू किया।
रिमोट फ्लीट
एक अकाउंट पर कई मशीनें। किसी ट्रिगर को उस मशीन पर पिन करें जिसे जवाब देना चाहिए, और सिर्फ़ वही मशीन एजेंट चलाती है।
पोल करना बंद करें। प्रतिक्रिया देना शुरू करें।
AgentsRoom डाउनलोड करें, एक URL को GitHub, GitLab, Slack, Linear या Sentry में पेस्ट करें, और इवेंट को एजेंट शुरू करने दें। जब तक कुछ नहीं होता, कुछ नहीं चलता।
कंपेनियन ऐप: चलते-फिरते अपने एजेंट्स मॉनिटर करें
Claude, Codex, Antigravity CLI या किसी अन्य AI प्रदाता का उपयोग करें।
बग और अनुरोध सीधे अपने सार्वजनिक बैकलॉग में भेजें।
AgentsRoom को कार्य करते देखें।