Sierra ने वैयक्तिक एजंट प्रोटोकॉलचा मसुदा 0.1, म्हणजे Poppy, 9 ऑक्टोबर रोजी, तीन दिवसांनी Meta आणि इतर भागीदारांसह प्रकल्पाची घोषणा केल्यानंतर तीन दिवसांनी. कंपनीचा एजंट इंटरफेस शोधणे, वैयक्तिक एजंट ओळखणे, ग्राहकाला साइन इन करणे आणि वेबसाइट, API व कंपनीच्या एजंटवर एकच भेट चालू ठेवणे यासाठीचे प्रस्तावित नियम हा नवा दस्तऐवज सुरुवातीच्या व्यापक आश्वासनाला तपशील देतो.

हा अजून मसुदाच आहे. स्थिर आवृत्तीपूर्वी कोणताही भाग बदलू शकतो, अगदी विसंगत पद्धतीनेही, असे तपशीलपत्र सांगते. Sierra ने आणखी 35 डिझाइन भागीदारांची नावे जाहीर केली. डिझाइन प्रक्रियेत सहभाग म्हणजे त्या कंपन्यांनी Poppy इंटरफेस तैनात केले आहेत असा पुरावा नाही.

मोठा बदल

  • काय बदलले: 6 ऑक्टोबरच्या घोषणेत वैयक्तिक एजंट व्यवसायांसोबत कसे काम करू शकतात हे सांगितले होते. 9 ऑक्टोबरचा मसुदा कंपनी आणि एजंटने अंमलात आणावयाच्या प्रस्तावित ओळख, परवानगी आणि सत्र-विनिमयाची रूपरेषा स्पष्ट करतो.
  • हे महत्त्वाचे का: ग्राहक एजंटला खाते-संबंधित कामांसाठी अधिकृत करू शकतो, तर कंपनी एजंटची ओळख पटवून त्याचा प्रवेश मर्यादित करते. मसुदा हे नियंत्रण वेबसाइट ब्राउझिंग, API आणि संभाषणांशी जोडतो; मात्र कोणते माध्यम आणि परवानग्या द्यायच्या हे कंपनी ठरवते.
  • कशावर लक्ष ठेवावे: अंमलबजावणी करणाऱ्यांसाठी आता तपासण्याजोगे ठोस इंटरफेस आहेत; त्याच वेळी देयके, सूचना आणि संलग्नकांचे नियम अजून बाकी आहेत. Sierra पुढील महिन्यात डिझाइन कार्यशाळा आणि संदर्भ-अंमलबजावणी प्रकाशित करण्याची योजना आखते; यापैकी काहीही व्यापक आंतरकार्यक्षमतेचा पुरावा नाही.

शोधाची सुरुवात कंपनीच्या डोमेनपासून होते

मसुदा तपशीलपत्रानुसार, सहभागी कंपनी HTTPS द्वारे /.well-known/poppy.json प्रकाशित करते. त्या दस्तऐवजात संस्थेचे नाव आणि OAuth issuer, समर्थित साइन-इन पद्धती आणि उपलब्ध असल्यास वेबसाइट-सत्र endpoint, OpenAPI किंवा MCP API, अथवा कंपनी-एजंट संभाषण endpoint दिलेले असते. कंपनीला प्रत्येक मार्ग द्यावा लागत नाही. वेबसाइटला एकमेव प्रवेशद्वार मानण्याऐवजी एजंट उपलब्ध पर्याय शोधण्यासाठी ही फाइल वापरेल.

फाइल स्वतः एजंटला अधिकृत करू शकत नाही. संस्थेचे डोमेन एजंटने मागितलेल्या डोमेनशी जुळले पाहिजे. एजंटने OAuth सर्व्हरचा मेटाडेटाही तपासला पाहिजे: issuer फाइलशी जुळला पाहिजे आणि त्याच्या poppy_domains यादीत संस्थेचे डोमेन असले पाहिजे. असंबंधित डोमेनने दुसऱ्या कंपनीचा issuer असल्याचा दावा करून टोकन मिळवू नये, यासाठी या तपासण्या आहेत.

वैयक्तिक एजंट स्वतःची ओळख HTTPS client_id URL द्वारे करून देतो; त्यावर सार्वजनिक स्वाक्षरी-कळा आणि मान्य redirect पत्त्यांसह क्लायंट मेटाडेटा उपलब्ध असतो. कंपनी पूर्वनोंदणी मागू शकते, एजंट ID रोखू किंवा रद्द करू शकते आणि सत्रनिर्मिती मर्यादित करू शकते. ही मसुद्याने कंपनीला दिलेली नियंत्रणे आहेत; प्रत्येक कंपनीने प्रत्येक एजंट स्वीकारलाच पाहिजे अशी अट नाही.

अतिथी सत्र खाते-सत्रात बदलू शकते

वैयक्तिक एजंट वापरकर्त्याला प्रत्येक कंपनीसाठी वेगळा स्थिर, अपारदर्शक ID देतो आणि स्वाक्षरी केलेल्या दाव्याने सत्र सुरू करतो. कंपनी साइन-आउट सत्र टोकन परत करते. त्यामुळे व्यक्ती साइन इन झाल्याचे न मानता वेगवेगळ्या सत्रांमध्ये तोच एजंट आणि वापरकर्ता ओळखता येतो. नाव, ईमेल पत्ता किंवा फोन नंबरवरून—की-आधारित हॅशनेही—वापरकर्ता ID तयार करण्यास मसुदा मनाई करतो.

खाते वापरण्यासाठी कंपनी समर्थित साइन-इन पद्धती जाहीर करते. थेट साइन-इन वापरकर्त्याच्या ब्राउझरमध्ये OAuth authorization पेज आणि PKCE वापरते. डिव्हाइस साइन-इनमध्ये वापरकर्त्याने लिंक आणि कोड वापरून कंपनीचे पेज उघडायचे असते. मध्यस्थ साइन-इनमध्ये वापरकर्त्याने एजंटला दिलेली क्रेडेन्शियल्स एजंट विशिष्ट कंपनी endpoint कडे पाठवतो; हा स्वतंत्र, ऐच्छिक मार्ग असून क्रेडेन्शियल हाताळणी आणि दर-मर्यादांचे स्पष्ट नियम आहेत. विश्वासाची एक मर्यादा मसुदा मान्य करतो: थेट साइन-इन पेज माणसाने पूर्ण केले की एजंटने, हे कंपनी नेहमी पडताळू शकत नाही.

परवानग्या scope द्वारे व्यक्त केल्या जातात. Poppy व्यापक poppy:read आणि poppy:write scope परिभाषित करते; कंपनीला त्याऐवजी अधिक अरुंद custom scope देता येतात. एजंटने मागितल्यापेक्षा किंवा विशिष्ट साइन-इन पद्धतीने परवानगी दिल्यापेक्षा अधिक प्रवेश कंपनी देऊ शकत नाही. साइन-इननंतर दिलेले खाते टोकन मंजूर scope मध्ये पुढील साइन-इन सत्र टोकन मिळवू देते. कामासाठी अधिक प्रवेश हवा असल्यास वापरकर्त्याने त्या scope साठी पुन्हा साइन इन केले पाहिजे.

दोन टोकनमधील फरक महत्त्वाचा आहे. सत्र टोकन अल्पकाळ वैध असते आणि API कॉल व संभाषणांसाठी वापरले जाते. खाते टोकन ही दीर्घकाळ वैध OAuth refresh credential असून फक्त कंपनीच्या token आणि revocation endpoint वर वापरायची असते. एजंटने ती model context, संदेश, logs आणि URL पासून दूर ठेवावी, असे मसुदा सांगतो. साइन-आउट केल्याने खाते टोकन रद्द होते आणि त्याच्याशी जोडलेली सत्रे साइन आउट होतात; कंपनी ती सत्रे स्वतंत्रपणे संपवू शकते. आधी दिलेली सत्र टोकन वैध राहू शकतात, म्हणून प्रत्येक विनंतीवेळी सत्रस्थिती तपासावी किंवा खूप कमी token lifetime वापरावा असा मसुदा कंपन्यांना सल्ला देतो.

एक सत्र, तीन शक्य मार्ग

Poppy वैयक्तिक एजंटद्वारे वापरकर्त्याच्या क्रियांसाठी एकच कंपनी-सत्र सुचवते. OpenAPI कॉल आणि कंपनी-एजंट संभाषणांसाठी एजंट authorization header मध्ये सत्र टोकन पाठवतो. मसुदा सामान्यतः ही टोकने एजंटकडे असलेल्या कळीशी DPoP पुराव्याने बांधतो; कंपनी प्रत्येक विनंतीवर ते तपासते. MCP हा स्पष्ट अपवाद आहे: त्याच्या authorization मध्ये नमूद MCP सर्व्हरपुरते मर्यादित bearer token वापरले जाते, आणि bearer प्रकाराला मसुदा फक्त MCP API साठी परवानगी देतो. या प्रोटोकॉलच्या अटी आहेत; एखादी अंमलबजावणी सुरक्षित असल्याचा निष्कर्ष नाही.

वेबसाइट ब्राउझिंग त्याच सत्रात वेगळ्या प्रकारे सामील होते. कंपनीने browser session endpoint प्रकाशित केला असल्यास एजंटचा ब्राउझर अल्पकालीन स्वाक्षरी केलेला दावा पाठवतो आणि कंपनीची स्वतःची session cookie मिळवतो. वेबसाइट मग सत्राची सध्याची साइन-इन स्थिती आणि scope लागू करते. असा endpoint नसेल तर एजंट सामान्य साइन-आउट अभ्यागताप्रमाणे ब्राउझ करतो. Sierra च्या लॉन्च खात्याने विविध माध्यमांमधील एक भेट सांगितली; सामायिक सत्राखाली browser आणि API वाहतुकीसाठी वेगवेगळी क्रेडेन्शियल्स मसुदा निर्दिष्ट करतो.

कंपनी discovery फाइलमध्ये OpenAPI वर्णने, MCP सर्व्हर आणि संभाषण endpoint देऊ शकते. कंपनीच्या एजंटशी बोलण्यासाठी आणि गरज पडल्यास माणसाला जोडण्यासाठी Poppy संभाषण स्वरूप मसुदा सांगतो. प्रत्येक API ची स्वतःची schema त्या API कडेच राहते. कंपनी कोणते मार्ग उघडते ते ठरवते आणि साइन-इन सत्रातही एजंट काय करू शकतो ते मर्यादित ठेवू शकते.

मसुद्यात अजून काय ठरलेले नाही

प्रोटोकॉलच्या उघड्या विषयांच्या पानावर तीन मोठ्या उणिवा नमूद आहेत: देयके, विनंती उघडी नसताना push notifications, आणि पावत्या, लेबले, प्रतिमा किंवा फॉर्म यांसारखी संलग्नके. यादी अपूर्ण असल्याचे पान सांगते. मसुद्यातील उदाहरणे काल्पनिक कंपन्या आणि placeholder क्रेडेन्शियल्स वापरतात.

Sierra च्या 9 ऑक्टोबरच्या पोस्टमध्ये Meta च्या Muse आणि Rocket सह परिषदेत केलेले प्रात्यक्षिक वर्णन केले आहे. हे नियोजित प्रात्यक्षिकाबद्दल Sierra चे वर्णन आहे; उत्पादनातील तैनातीचे स्वतंत्र परीक्षण नाही. पुढील महिन्यात डिझाइन कार्यशाळा घेऊन संदर्भ-अंमलबजावणी प्रकाशित करू असे Sierra म्हणते. सध्या Poppy हा अंमलबजावणी तपशील आणि वाढती डिझाइन-पार्टनर यादी असलेला प्रकाशित प्रस्ताव आहे. त्याचा प्रत्यक्ष आवाका कोणत्या कंपन्या आणि वैयक्तिक एजंट निर्माते सुसंगत आवृत्त्या अंमलात आणतात आणि ते कोणता प्रवेश देतात यावर अवलंबून आहे.

स्रोत आणि पुढील वाचन

  • वैयक्तिक एजंट प्रोटोकॉल तपशीलपत्र, मसुदा 0.1, 9 ऑक्टोबर 2026 रोजी अद्ययावत. शोध, ओळख, साइन-इन, scope, token, सत्र आणि माध्यम-नियमांचा प्राथमिक स्रोत. स्थिर आवृत्तीपूर्वी विसंगत बदल स्पष्टपणे मान्य; उदाहरणे काल्पनिक आहेत.
  • Poppy चे खुले विषय, 9 ऑक्टोबर 2026 रोजी अद्ययावत. सध्याच्या मसुद्यात नसलेल्या देयके, push notifications आणि संलग्नकांची प्राथमिक यादी; इतर उणिवा पुढे दिसू शकतात असे पान सांगते.
  • Sierra ची 9 ऑक्टोबरची घोषणा. प्रकाशन दिनांक, आणखी 35 डिझाइन भागीदार, सांगितलेले परिषद प्रात्यक्षिक आणि नियोजित कार्यशाळा/संदर्भ-अंमलबजावणी नोंदवते. ही Sierra ची विधाने आहेत, तैनातीचा पुरावा नाही.
  • Sierra ची 6 ऑक्टोबरची ओळख. सुरुवातीच्या घोषणेतील प्रस्ताव आणि नंतरच्या तांत्रिक मसुद्याने केलेला बदल दाखवते.