तुमचा पहिला एजंट वर्कफ्लो एका प्रॉम्प्टपासून आणि काही टूल्सपासून सुरू होतो. तो प्रश्नांची उत्तरे देतो. तो ऑर्डर स्टेटस शोधतो. तो व्यवस्थित काम करतो, म्हणून तुम्ही तो लाँच करता.

त्यानंतर उत्पादन (product) वाढते. सेल्स टीम मीटिंग नोट्स सिंक करणारा CRM updater मागतो. सपोर्ट टीमला असा रिफंड वर्कफ्लो हवा असतो जो तीन अंतर्गत सिस्टिम्सना स्पर्श करतो. इंजिनिअरिंग टीम व्हेंडर फॉर्म भरण्यासाठी ब्राउझर ॲक्शन्स जोडते. प्रत्येक विनंती लहान वाटते. प्रत्येक विनंतीसाठी स्वतःची प्रॉम्प्ट फाईल, स्वतःचा Slack थ्रेड आणि स्वतःचा "क्विक फिक्स" असतो. सहा महिन्यांनंतर, तुमचा एजंट आता एक सिस्टिम राहत नाही. तो कॉपी केलेल्या प्रॉम्प्ट्सचा, लपवलेल्या बिझनेस रूल्सचा आणि जुन्या चॅट थ्रेड्समध्ये घेतलेल्या निर्णयांचा एक विखुरलेला ढिगारा बनतो, जे आता कोणालाही सापडत नाहीत. यालाच 'प्रॉम्प्ट स्प्राउल' (prompt sprawl) म्हणतात. यामुळे तुमचे AI उत्पादन टेस्ट करणे, रिव्ह्यू करणे कठीण होते आणि आत्मविश्वासाने रोल बॅक (roll back) करणे अशक्य होते.

याचे निराकरण म्हणजे 'AI agent skill registry' आहे.

स्किल (Skill) म्हणजे नक्की काय असते

स्किल म्हणजे केवळ फोल्डरमध्ये सेव्ह केलेला प्रॉम्प्ट नाही. ते एक व्हर्जन केलेले (versioned), टेस्ट करण्यायोग्य पॅकेज आहे जे एजंट काय करतो, तो कोणती टूल्स वापरू शकतो आणि त्याने काय कधीही करू नये हे परिभाषित करते. याला तुमच्या टीम आणि मशीनमधील एक करार (contract) समजा. जेव्हा एखादा एजंट स्किल लोड करतो, तेव्हा त्याला त्याच्या मर्यादा नक्की कुठे आहेत आणि यश म्हणजे काय, हे स्पष्टपणे माहित असावे.

या संरचनेशिवाय, प्रत्येक प्रॉम्प्ट एक लहान, घोषित न केलेली प्रोडक्शन सिस्टिम बनते. त्यामध्ये लपलेले परवानग्या (permissions), एम्बेड केलेले बिझनेस रूल्स आणि कोणाचेही लक्ष न गेलेले खर्चाचे परिणाम (cost impacts) असतात. ते प्रत्यक्ष उत्पादनापासून विलग होत जाते कारण प्रॉडक्ट रोडमॅप पुढे सरकतो आणि प्रॉम्प्ट मागेच राहतो. सर्वात वाईट म्हणजे, त्याची कॉपी केली जाते. कोणीतरी डेमोसाठी त्याची 'फोर्क' (fork) काढते किंवा ती नवीन मायक्रोसर्व्हिसमध्ये पेस्ट करते, आणि आता तुमच्याकडे सत्याचे दोन वेगवेगळे स्रोत (sources of truth) तयार होतात जे एकमेकांपासून विलग होतात.

केवळ प्रॉम्प्ट्स का अपयशी ठरतात

प्रॉम्प्ट्स मजकुरासारखे (text) दिसतात, म्हणून टीम्स त्यांना कॉन्फिगरेशनप्रमाणे वागवतात. प्रत्यक्षात, ते कोणालाही मान्य असण्यापेक्षा कोडच्या (code) अधिक जवळ असतात. प्रोडक्शन प्रॉम्प्टमध्ये सहसा सिक्वेन्सिंग, फॉरमॅटिंग, एरर हँडलिंग आणि ॲक्सेस कंट्रोलबद्दलचे लॉजिक एनकोड केलेले असते. जेव्हा ते लॉजिक केवळ नैसर्गिक भाषेत असते, तेव्हा संदिग्धता निर्माण होते. एजंटला CRM अपडेट करण्याची परवानगी आहे की प्रॉम्प्टने फक्त तसा सल्ला दिला आहे? जर बिलिंग API बंद पडला, तर प्रॉम्प्टला सुरक्षितपणे फेल (fail) कसे व्हायचे हे माहित आहे का, की तो यशाचा खोटा संदेश (hallucinate) देतो?

खर्च हा आणखी एक मूक शत्रू आहे. "टप्प्याटप्प्याने विचार करा आणि सखोल शोध घ्या" असे सांगणारा प्रॉम्प्ट प्रत्येक रनमध्ये मोठ्या प्रमाणात टोकन्स (tokens) खर्च करू शकतो. जेव्हा तो प्रॉम्प्ट हाय-ट्रॅफिक सपोर्ट फ्लोमध्ये कॉपी केला जातो, तेव्हा तुमचे मासिक इन्फरन्स बिल (inference bill) दुप्पट होते आणि कोणालाही त्याचे कारण माहित नसते.

जेव्हा व्यवसाय बदलतो पण मजकूर बदलत नाही, तेव्हा 'ड्रिफ्ट' (drift) होते. समजा तुमची रिफंड पॉलिसी आता एका विशिष्ट मर्यादेच्या वर मॅनेजरची मंजुरी मागते. जर तो नियम पॉलिसी लेअरऐवजी प्रॉम्प्टमध्ये असेल, तर तुम्हाला अपडेट करण्याची गरज असलेल्या कॉपी शोधण्यासाठी प्रत्येक डिप्लॉयमेंटमध्ये शोध घ्यावा लागेल. एकही सुटले, तर तुमचे एजंट्स अशा वेळी पैसे परत करू लागतील जेव्हा त्यांना तसे करायला नको असते.

प्रोडक्शन स्किलची रचना (Anatomy)

जर तुम्हाला या गोंधळातून सुटका करून घ्यायची असेल, तर प्रत्येक स्किलला सॉफ्टवेअर आर्टिफॅक्ट (software artifact) प्रमाणे वागवा. एका उपयुक्त प्रोडक्शन स्किलमध्ये केवळ मजकूर नसतो. त्याला खालील गोष्टींची आवश्यकता असते:

  • नाव आणि उद्देश. "prompt_v3_final" असे न ठेवता, व्यवसायाचे ध्येय स्पष्ट करणारे "process_standard_refund" असे नाव असावे.
  • इनपुट स्कीमा (Input schema) आणि आवश्यक संदर्भ. स्किलला नेमकी कोणती फील्ड्स अपेक्षित आहेत ते परिभाषित करा. त्याला युजर आयडी (user ID), संभाषणाचा इतिहास (conversation history) किंवा टेनंट आयडेंटिफायर (tenant identifier) आवश्यक आहे का? येथे 'स्ट्रॉन्ग टायपिंग' (strong typing) एजंटला स्वतःचे अंदाज लावण्यापासून रोखते.
  • टूल परवानग्या आणि सुरक्षा मर्यादा. स्किल कोणती टूल्स वापरू शकते याची स्पष्ट यादी द्या. रिट्रायज (retries), खर्चाच्या मर्यादा आणि रेट कॅप्सवर (rate caps) गार्डरेल्स (guardrails) सेट करा. जर स्किलने युजर डिलीशन API ला स्पर्श करू नये असे वाटत असेल, तर ते केवळ वर्णनात न सांगता कोडमध्ये सांगा.
  • यशाचे निकष आणि टेस्ट केसेस. एखादे स्किल केवळ चालते म्हणून ते "काम करते" असे म्हणता येत नाही. आउटपुटमध्ये काय असावे हे परिभाषित करा. रिफंड स्किलसाठी, यश म्हणजे एक व्हॅलिडेटेड ट्रान्झॅक्शन रेकॉर्ड, पाठवलेला ईमेल कन्फर्मेशन आणि तयार केलेली ऑडिट लॉग एंट्री असू शकते.
  • व्हर्जन हिस्ट्री आणि मालकी हक्क. कोणीतरी याची जबाबदारी घेणे आवश्यक आहे. चेंजलॉगमध्ये (changelog) v2.3 का अस्तित्वात आहे आणि v2.2 मध्ये काय बिघडले होते, याचे स्पष्टीकरण असावे.

तुमचे लेयर्स (Layers) वेगळे करा

टीम्स केलेली सर्वात मोठी चूक म्हणजे सर्व काही एकाच प्रॉम्प्टमध्ये कोंबणे. ते मैत्रीपूर्ण मार्गदर्शन, टूल डॉक्युमेंटेशन, सुरक्षा धोरण आणि एरर हँडलिंग सर्व काही मजकुराच्या एका मोठ्या ढिगाऱ्यात मिसळतात. हे मेंटेन करणे अशक्य आहे.

ते वेगळे करा:

  • सूचना (Instructions) या एजंटसाठी मार्गदर्शक आहेत. त्या टोन (सूर), फॉरमॅट आणि सामान्य दृष्टिकोन स्पष्ट करतात.
  • टूल नियम (Tool Rules) एजंटला कोणते टूल्स उपलब्ध आहेत आणि ते काय करतात हे सांगतात. ही माहिती शोधण्यासाठी (discovery) आहे, परवानगीसाठी नाही.
  • धोरण (Policy) हे कोडद्वारे लागू केले जाते, केवळ आशेवर अवलंबून नसते. जर $500 पेक्षा जास्त रिफंडसाठी दुसऱ्या व्यक्तीच्या मान्यतेची गरज असेल, तर ती तपासणी एका 'validation function' मध्ये असते, जे टूल कॉल करण्यापूर्वीच चालते.
  • Evals हे असे टेस्ट्स आहेत जे कोणत्याही बदलांनंतरही स्किल व्यवस्थित काम करत आहे हे सिद्ध करतात.

उदाहरणार्थ, "कृपया ग्राहकाचा पूर्ण क्रेडिट कार्ड नंबर कधीही उघड करू नका" असे लिहू नका. त्याऐवजी, असा डेटा फॉरमॅटर तयार करा जो एजंटला दिसण्यापूर्वीच PAN नंबर लपवेल (redact). धोरण कोडमध्ये असणे आवश्यक आहे, कारण चतुर युजर इनपुटद्वारे कोडला त्याचे काम करण्यापासून रोखता येत नाही.

प्रोडक्शनला "Latest" कडे निर्देश करणे थांबवा

प्रॉम्प्टमधील एखादे शांत अपडेट (silent update) तुमच्या शुक्रवारची संध्याकाळ उद्ध्वस्त करण्यासारखे दुसरे काहीही नाही. जर तुमचे प्रोडक्शन एजंट नेहमी स्किलची "latest" आवृत्ती घेत असेल, तर 'main' मध्ये होणारा प्रत्येक मर्ज हा संभाव्य लाइव्ह इन्सिडेंट (live incident) ठरू शकतो. तुम्हाला dev, staging, आणि prod सारखे अलिआसेस (aliases) आवश्यक आहेत. या टप्प्यांतून एक ज्ञात आणि टेस्ट केलेली आवृत्ती पुढे न्या. जेव्हा prod v2.1.4 कडे निर्देश करते, तेव्हा तुम्ही ते चालताना पाहू शकता, त्याचे वर्तन मोजू शकता आणि शांतपणे झोपू शकता. जर काही चुकले, तर तुम्ही अलिआस मागे घेऊ शकता. मध्यरात्री दबावाखाली असताना तुम्ही नॅचरल लँग्वेज (natural language) डीबग करू शकत नाही.

ही शिस्त तुमच्या टीमला 'backwards compatibility' बद्दल विचार करण्यास भाग पाडते. v2.2 ही v2.1 प्रमाणेच इनपुट हाताळू शकते का? नसेल तर, प्रमोशन 'staging' मध्येच अयशस्वी होईल आणि ग्राहकापर्यंत पोहोचण्यापूर्वीच तुम्हाला ते समजेल.

सुरक्षा पॅकेजच्या आतून सुरू होते

ऑडिट न केलेले प्रॉम्प्ट्स असलेले रजिस्ट्री हे एक संभाव्य धोका (vulnerability) आहे. तुम्हाला तुमच्या स्किल्समध्ये त्याच जोखमींची तपासणी करणे आवश्यक आहे ज्याप्रमाणे तुम्ही कोडमध्ये करता.

प्रॉम्प्ट टेम्पलेट्समध्ये लपवलेले हार्डकोडेड सीक्रेट्स किंवा API की शोधा. डेटा बाहेर पाठवणारे (exfiltrate) बाह्य वेबहुक्स किंवा शेल कमांड्स तपासा. सिस्टम पॉलिसी ओव्हरराइड करण्याचा प्रयत्न होत आहे का ते पहा, जसे की "ignore previous instructions" असे असलेले प्रॉम्प्ट्स किंवा एजंटला त्याची स्वतःची कॉन्फिगरेशन उघड करण्यास सांगणारे प्रॉम्प्ट्स. हे केवळ सैद्धांतिक नाहीत. हे प्रॉम्प्ट-इंजेक्शन हल्ल्यांमधील सामान्य पॅटर्न आहेत आणि ते धोकादायक आहेत कारण ते अनेकदा कोणाकडूनही तपासले न गेलेल्या कॉपी केलेल्या मजकुरासोबत येतात.

तुमच्या स्किल पॅकेजेसवर 'static analysis' चालवा. जर एखाद्या स्किल फाईलमध्ये 'allowlist' मध्ये नसलेला URL असेल, तर बिल्ड फेल करा. जर ते मंजूर मॅनिफेस्टमध्ये नसलेल्या टूलचा संदर्भ देत असेल, तर ते नाकारून टाका.

जर तुम्ही त्याची टेस्ट करू शकत नसाल, तर तुम्ही त्यावर विश्वास ठेवू शकत नाही

इव्हॅल्युएशन्सशिवाय असलेली रजिस्ट्री म्हणजे केवळ प्रॉम्प्ट्सचा एक फोल्डर आहे. प्रत्येक स्किलला एक टेस्ट सेट आवश्यक आहे जो happy path, edge cases, आणि failure modes तपासेल. उच्च-जोखीम असलेल्या स्किल्ससाठी, तुम्हाला केवळ फंक्शनल टेस्ट्सपेक्षा अधिकची गरज आहे. एजंट दुसऱ्या वापरकर्त्याचा डेटा पाहू शकत नाही याची खात्री करण्यासाठी तुम्हाला परमिशन बाउंड्रीज (permission boundaries) तपासाव्या लागतील. धोरण एखाद्या कृतीला रोखत असताना एजंट "नाही" म्हणतो की नाही, हे तपासण्यासाठी 'refusal behavior checks' आवश्यक आहेत. तुमच्या कोड-स्तरीय संरक्षणांना (code-level protections) ॲडव्हर्सरिअल इनपुट (adversarial inputs) बगल करणार नाहीत याची खात्री करण्यासाठी 'prompt-injection resistance tests' आवश्यक आहेत.

तुमच्या टेस्ट्सना स्पष्ट नावे द्या. "refund_skill_rejects_negative_amount" नावाचा टेस्ट पुढच्या इंजिनिअरला नेमके कोणते वर्तन संरक्षित आहे हे सांगतो. जेव्हा व्हर्जन प्रमोशन दरम्यान एखादी टेस्ट फेल होते, तेव्हा तुमच्याकडे ठोस पुरावा असतो की ती बिल्ड असुरक्षित आहे.

खरा उद्देश नियंत्रण (Control) मिळवणे हा आहे

पुन्हा वापरणे (Reuse) चांगले आहे, पण नियंत्रण तुम्हाला नोकरीवर टिकवून ठेवते. स्किल रजिस्ट्री तुमच्या टीमला खात्रीने सांगू देते: हे मंजूर वर्कफ्लो आहे. हे प्रोडक्शनमध्ये चालणारे व्हर्जन आहे. ही ती टूल्स आहेत जी ते वापरू शकते. आम्ही हे नक्की कसे रोलबॅक (roll back) करू शकतो.

ही स्पष्टता तुम्हाला केवळ हुशार डेमो पाठवण्यापासून विश्वासार्ह सॉफ्टवेअर चालवण्याकडे नेते. डेमो स्टेकहोल्डर्सना दहा मिनिटे प्रभावित करतात. पण विश्वासार्ह सॉफ्टवेअर पहाटे तीन वाजताही चालते, अपवाद (exceptions) व्यवस्थित हाताळते आणि केवळ मंगळवारी दुपारी कोणीतरी 'pull request' मर्ज केल्यामुळे त्याचे वर्तन बदलत नाही.

तुमची रजिस्ट्री तयार करा. तुमच्या स्किल्सचे व्हर्जन करा. तुमचे धोरण कोडमध्ये लागू करा. तुमच्या झोपण्याच्या वेळापत्रकावर अवलंबून असल्यासारखे टेस्ट करा. तुमचे भविष्य तुमचे आभार मानेल.