प्रत्येक प्रॉडक्ट रोडमॅपमध्ये "AI Agent" असा एक बुलेट पॉईंट असतो. हा शब्द प्रगतीचा भास निर्माण करतो. तो नेतृत्वाला (leadership) असा संकेत देतो की तुमची टीम केवळ वर्तमानकाळ टिकवून ठेवत नाहीये, तर भविष्य घडवत आहे. पण एक अस्वस्थ करणारा सत्य आहे जो बहुतेक डेमो व्हिडिओ तुम्हाला दाखवणार नाहीत: एखादे काम पूर्ण करण्याचा 'एजंट' हा सर्वात महागडा आणि सर्वात कमी अंदाज लावता येण्याजोगा (least predictable) मार्ग आहे. बहुतांश व्यावसायिक कामांसाठी, हा पूर्णपणे चुकीचा पर्याय आहे. सर्वोत्तम इंजिनिअर्स ते नसतात जे तो बनवण्यासाठी घाई करतात, तर ते असतात ज्यांना कधी थांबायचे हे माहित असते.

वर्गीकरणाचा सापळा (The Classification Trap)

एखादी टीम त्यांचा पहिला एजंट ठरवताना (scope) पहा, तर तुम्हाला सहसा असे काहीतरी दिसेल. एक सपोर्ट ईमेल येतो. एक Large Language Model त्याचा विषय आणि मजकूर वाचतो, तो बिलिंगचा प्रश्न आहे की तांत्रिक त्रुटी (technical bug) हे ठरवतो आणि त्याला योग्य रांगेत (queue) टाकतो. टीम याला 'एजंट' म्हणते. पण तो नाही.

त्यांनी जे तयार केले आहे ते केवळ एका मॉडेल कॉलसह असलेला एक डिटरमिनिस्टिक फ्लो (deterministic flow) आहे. पायऱ्या निश्चित आहेत: ईमेल स्वीकारणे, मॉडेलला कॉल करणे, रांगेत पाठवणे. यात कोणतीही लूप (loop) नाही, टूलचा वापर नाही, किंवा पहिली попыत अयशस्वी झाल्यामुळे सिस्टीमने आपला प्लॅन पुन्हा विचार करण्यासाठी थांबण्याचा कोणताही क्षण नाही. ते नॉलेज बेस शोधत नाही, कोड लिहित नाही किंवा प्रक्रियेदरम्यान ऑर्डरची स्थिती तपासत नाही. ते एक निर्णय घेते आणि पुढे जाते. त्या एका कॉलला मायक्रोसर्व्हिसमध्ये गुंडाळल्याने (wrapping) तो एजंट बनत नाही.

फ्लोला एजंट समजून चूक करण्याचा खरा खर्च केवळ अतिरिक्त इन्फ्रास्ट्रक्चरपुरता मर्यादित नाही. तर तो असा 'नॉन-डिटरमिनिझम' (non-determinism) आहे जो तुम्ही कोणत्याही फायद्याशिवाय आमंत्रित केला आहे. मंगळवार सकाळी आणि बुधवार दुपारी तोच ईमेल वेगवेगळ्या प्रकारे रांगेत पाठवला जाऊ शकतो, कारण 'टेम्परेचर' (temperature) शून्य नाही किंवा प्रॉम्प्टमध्ये बदल (drift) झाला आहे. तुम्ही लेटन्सी (latency), टोकन खर्च आणि इव्हॅल्युएशन ओव्हरहेडसाठी एजंटच्या किमती मोजता, तर एक क्लासिफिकेशन स्टेप असलेला फ्लो तोच प्रश्न अधिक वेगाने आणि स्वस्त्या सोडवू शकतो.

शिडीच्या पायऱ्यांनुसार काम करा (Work Down the Ladder)

बहुतेक समस्यांसाठी अशा काही सोप्या पद्धती आहेत ज्या तितक्याच चांगल्या प्रकारे काम करतात. याला एक शिडी समजा आणि खालून सुरुवात करा.

प्रक्रिया सुधारा (Fix the process). कधीकधी काम केवळ दोन सिस्टीममधील विसंगतीमुळे अस्तित्वात असते. तुमच्या CRM मधील कस्टमर रेकॉर्ड तुमच्या टिकेटिंग प्लॅटफॉर्मशी सिंक होत नाही, म्हणून प्रत्येक सकाळी मानवाला तो फरक भरून काढण्यासाठी मॅन्युअली काम करावे लागते. त्यातील अंतर भरून काढण्यासाठी एजंट वापरून ऑटोमेशन करू नका. ते अंतरच काढून टाका. जर डेटा पाईपलाईन निरोगी असेल, तर ते काम आपोआप नाहीसे होईल.

क्वेरी वापरा (Use a query). जर उत्तर शोधणे किंवा डेटा एकत्रित करणे (aggregation) सोपे असेल, तर तसाच वापर करा. "गेल्या मंगळवारी आम्ही किती रिफंड प्रोसेस केले?" यासाठी तर्काची (reasoning) गरज नाही. त्यासाठी SQL ची गरज आहे. नैसर्गिक भाषा (natural language) चे SQL मध्ये रूपांतर करणारा एजंट ऐकायला छान वाटतो, जोपर्यंत तुम्हाला हे लक्षात येत नाही की त्याचा मेंटेनन्सचा भार तुमच्या डॅशबोर्डवरून चालवल्या जाणाऱ्या तीन डॉक्युमेंटेड क्वेरीज लिहिण्यापेक्षा जास्त आहे.

डिटरमिनिस्टिक फ्लो तयार करा (Build a deterministic flow). जेव्हा नियम निश्चित असतात आणि परिणाम पुन्हा पुन्हा मिळवता येतात, तेव्हा स्पष्ट लॉजिक वापरा. जर ऑर्डरची किंमत एका मर्यादेपेक्षा जास्त असेल, तर ती फायनान्स विभागाकडे पाठवा. जर वापरकर्ता तीस दिवसांपासून सक्रिय नसेल, तर त्याला पुन्हा गुंतवण्यासाठी (re-engagement) ईमेल पाठवा. कोड हे काम शून्य व्हेरिएन्स आणि पूर्ण ऑब्झर्व्हेबिलिटीसह हाताळतो. तुम्ही त्याची युनिट-टेस्टिंग करू शकता. तुम्ही 'व्हायब'ची (vibe) युनिट-टेस्टिंग करू शकत नाही.

एका मॉडेल कॉलसह फ्लो वापरा (Use a flow with one model call). क्लासिफिकेशन, सेंटीमेंट टॅगिंग किंवा डेटा एक्सट्रॅक्शन या गोष्टी येथे येतात. मॉडेल एका कठोर स्क्रिप्टमध्ये एक निर्णय घेते. तुम्ही एक दस्तऐवज स्वीकारता, इनव्हॉइस नंबर काढता आणि तो डेटाबेसमध्ये लिहिता. आजूबाजूच्या पायऱ्या हार्डकोडेड असतात. मॉडेल पुढे काय करायचे हे ठरवत नाही; ते फक्त जे दिसते त्याला लेबल लावते. ही एक शक्तिशाली पद्धत आहे, पण तरीही तो एक फ्लोच आहे.

एजंट सर्वात शेवटी तयार करा (Build an agent last). ही पायरी अशा कामांसाठी राखून ठेवा जिथे पुढची कृती खरोखरच मॉडेलने प्रक्रियेदरम्यान काय शोधले यावर अवलंबून असते. जर सिस्टीमला ईमेल वाचणे आवश्यक असेल, लॉजिस्टिक API मध्ये शिपमेंट शोधण्याची गरज भासली, शिपमेंटला उशीर झाला आहे हे समजले आणि त्यानंतर त्या ताज्या डेटावर आधारित एक सानुकूल (custom) प्रतिसाद तयार करणे आवश्यक असेल, तर तुम्ही 'एजंट' क्षेत्रात आहात. मॉडेल प्रत्येक नवीन तथ्यानंतर काय करायचे हे ठरवते, त्यामुळे मार्ग आधीच आखता येत नाही.

व्हाईटबोर्ड टेस्ट (The Whiteboard Test)

मीटिंगमधील वाद मिटवण्याचा एक जलद मार्ग आहे. तुमच्या टीमला व्हाईटबोर्डवर निर्णयांच्या शाखा (decision branches) काढण्यास सांगा.

जर मॉडेल चालण्यापूर्वी तुम्ही प्रत्येक मार्ग मॅप करू शकत असाल, तर फ्लो तयार करा. डायमंड आकार काढा, 'if-statements' लिहा आणि काम संपवा. प्रेडिक्टेबिलिटी (Predictability) हे एक वैशिष्ट्य आहे, मर्यादा नाही.

जर मॉडेललाच पुढची पायरी काय असेल हे ठरवावे लागत असेल, जर ते टूल निवडते, पॅरामीटर्स सेट करते आणि पुन्हा विचार करण्यासाठी लूपमध्ये जाते, तर तुम्हाला एजंटची गरज आहे. ते डायनॅमिक राउटिंग (dynamic routing) हीच विभागणी करणारी रेषा आहे. केवळ नवीन API वापरायची इच्छा असल्यामुळे चुकून ती रेषा ओलांडू नका.

छुपे कर (The Hidden Tax)

डेमोमध्ये एजंट्स अगदी सहज वाटतात. पण प्रत्यक्ष वापरामध्ये (Production) चार प्रकारचे 'टॅक्स' समोर येतात जे वेगाने वाढत जातात.

नॉन-डिटरमिनिझम (Non-determinism). तोच...