हर प्रोडक्ट रोडमैप में एक बुलेट पॉइंट होता है जिसमें "AI Agent" लिखा होता है। यह शब्द प्रगति जैसा लगता है। यह नेतृत्व (leadership) को संकेत देता है कि आपकी टीम भविष्य का निर्माण कर रही है, न कि केवल वर्तमान को बनाए रख रही है। लेकिन यहाँ वह असहज सच्चाई है जो अधिकांश डेमो वीडियो आपको नहीं दिखाएंगे: किसी काम को पूरा करने के लिए एजेंट सबसे महंगा और सबसे कम अनुमानित (least predictable) तरीका है। अधिकांश व्यावसायिक कार्यों के लिए, यह पूरी तरह से गलत टूल है। सबसे अच्छे इंजीनियर वे नहीं हैं जो इसे बनाने की जल्दबाजी करते हैं। वे वे हैं जो जानते हैं कि कब रुकना है।

Classification का जाल

किसी टीम को अपना पहला एजेंट तय करते हुए देखें, तो आपको आमतौर पर ऐसा कुछ दिखाई देगा। एक सपोर्ट ईमेल आता है। एक Large Language Model विषय और बॉडी को पढ़ता है, यह तय करता है कि यह बिलिंग संबंधी प्रश्न है या तकनीकी बग, और इसे उचित कतार (queue) में डाल देता है। टीम इसे एजेंट कहती है। यह नहीं है।

उन्होंने जो बनाया है वह एक deterministic flow है जिसके अंदर एक सिंगल मॉडल कॉल है। चरण निश्चित हैं: ईमेल प्राप्त करना, मॉडल को कॉल करना, कतार में भेजना। इसमें कोई लूप नहीं है, कोई टूल का उपयोग नहीं है, और न ही ऐसा कोई क्षण है जहाँ सिस्टम अपनी योजना पर पुनर्विचार करने के लिए रुकता है क्योंकि पहला प्रयास विफल हो गया। यह knowledge base को ब्राउज़ नहीं करता, कोड नहीं लिखता, या बीच में ऑर्डर स्टेटस चेक नहीं करता। यह एक निर्णय लेता है और आगे बढ़ जाता है। उस सिंगल कॉल को एक microservice में लपेट देने से वह एजेंट नहीं बन जाता।

एक flow को एजेंट समझने की असली लागत केवल अतिरिक्त इंफ्रास्ट्रक्चर नहीं है। यह वह non-determinism है जिसे आपने बिना किसी लाभ के आमंत्रित किया है। वही ईमेल मंगलवार की सुबह और बुधवार की दोपहर में अलग तरह से रूट किया जा सकता है क्योंकि temperature नॉन-जीरो है या prompt बदल गया है। आप latency, token costs, और evaluation overhead के लिए एजेंट वाली कीमतें चुकाते हैं, जबकि एक classification चरण वाला flow समस्या को तेज़ी से और सस्ते में हल कर देता है।

सीढ़ी के नीचे से काम शुरू करें

अधिकांश समस्याओं के सरल विकल्प होते हैं जो उन्हें उतनी ही अच्छी तरह से हल करते हैं। इसे एक सीढ़ी के रूप में सोचें, और नीचे से शुरुआत करें।

प्रक्रिया को ठीक करें। कभी-कभी काम केवल इसलिए होता है क्योंकि दो सिस्टम आपस में असहमत होते हैं। आपके CRM में एक कस्टमर रिकॉर्ड आपके टिकटिंग प्लेटफॉर्म के साथ सिंक नहीं होता है, इसलिए हर सुबह एक इंसान को मैन्युअल रूप से उस अंतर को भरना पड़ता है। उस अंतर को एजेंट के साथ ऑटोमेट न करें। उसे खत्म करें। यदि डेटा पाइपलाइन स्वस्थ होती, तो वह काम गायब हो जाता।

क्वेरी का उपयोग करें। यदि उत्तर एक साधारण लुकअप या एग्रीगेशन है, तो उसके साथ वैसा ही व्यवहार करें। "पिछले मंगलवार को हमने कितने रिफंड प्रोसेस किए?" के लिए reasoning की आवश्यकता नहीं है। इसके लिए SQL की आवश्यकता है। एक एजेंट जो natural language को SQL में बदलता है, सुनने में शानदार लगता है जब तक कि आपको यह एहसास न हो जाए कि इसका maintenance का बोझ उन तीन डॉक्यूमेंटेड क्वेरीज़ को लिखने से कहीं अधिक है जिन्हें आपकी टीम एक डैशबोर्ड से चलाती है।

एक deterministic flow बनाएं। जब नियम निश्चित हों और परिणाम दोहराने योग्य (repeatable) हों, तो स्पष्ट लॉजिक का उपयोग करें। यदि ऑर्डर वैल्यू एक सीमा से अधिक हो जाती है, तो फाइनेंस को भेजें। यदि कोई यूजर तीस दिनों तक निष्क्रिय रहता है, तो re-engagement ईमेल भेजें। कोड इसे zero variance और पूर्ण observability के साथ संभालता है। आप इसका unit-test कर सकते हैं। आप किसी vibe का unit-test नहीं कर सकते।

एक मॉडल कॉल वाले flow का उपयोग करें। यहीं पर classification, sentiment tagging, या data extraction का काम होता है। मॉडल एक कठोर स्क्रिप्ट के भीतर एक एकल निर्णय लेता है। आप एक दस्तावेज़ प्राप्त करते हैं, invoice number निकालते हैं, और उसे डेटाबेस में लिखते हैं। आस-पास के चरण hardcoded होते हैं। मॉडल यह नहीं चुनता कि आगे क्या करना है; यह केवल वही लेबल करता है जो वह देखता है। यह एक शक्तिशाली पैटर्न है, लेकिन यह अभी भी एक flow है।

एजेंट को अंत में बनाएं। इस चरण को उन कार्यों के लिए सुरक्षित रखें जहाँ अगला कदम वास्तव में इस बात पर निर्भर करता है कि मॉडल रन के दौरान क्या खोजता है। यदि सिस्टम को एक ईमेल पढ़ना चाहिए, यह महसूस करना चाहिए कि उसे एक logistics API में शिपमेंट देखना होगा, यह पता लगाना चाहिए कि शिपमेंट में देरी हुई है, और फिर उस ताज़ा डेटा के आधार पर एक कस्टम रिस्पॉन्स ड्राफ्ट करना चाहिए, तो आप एजेंट के क्षेत्र में हैं। रास्ता पहले से नहीं बनाया जा सकता क्योंकि मॉडल हर नए तथ्य के बाद तय करता है कि क्या करना है।

व्हाइटबोर्ड टेस्ट

मीटिंग में बहस को सुलझाने का एक तेज़ तरीका है। अपनी टीम से व्हाइटबोर्ड पर decision branches को खींचने के लिए कहें।

यदि आप मॉडल चलने से पहले हर रास्ते को मैप कर सकते हैं, तो एक flow बनाएं। डायमंड शेप बनाएं, if-statements लिखें, और काम पूरा करें। Predictability एक फीचर है, सीमा नहीं।

यदि मॉडल को खुद तय करना होगा कि अगला कदम क्या है, यदि वह टूल चुनता है, पैरामीटर सेट करता है, और फिर से सोचने के लिए लूप करता है, तो आपको एक एजेंट की आवश्यकता है। वह dynamic routing ही विभाजक रेखा है। गलती से इसे पार न करें क्योंकि आप एक नया API उपयोग करना चाहते थे।

छिपा हुआ टैक्स

डेमो एजेंटों को frictionless दिखाते हैं। प्रोडक्शन चार टैक्स को उजागर करता है जो तेज़ी से बढ़ते हैं।

Non-determinism. वही