जुलैमध्ये ॲमस्टरडाममधील २०० रेस्टॉरंट्सवर केलेल्या एका चाचणीतून असे दिसून आले की, सध्याचे AI असिस्टंट्स टेबल रिझर्व्हेशन पूर्ण करू शकत नाहीत, कारण बुकिंग विजेट (widget) एका iframe मध्ये लपलेले असते.

iframe मुळे एजंट्स का अडखळतात

बहुतेक ऑनलाइन रिझर्व्हेशन टूल्स हे एम्बेड केलेल्या (embedded) iframe स्वरूपात असतात. एखादा व्हिजिटर “Reserve” बटणावर क्लिक करतो, त्यानंतर कॅलेंडर उघडते आणि वापरकर्ता वेळेचा स्लॉट निवडतो. माणसासाठी ही प्रक्रिया सुरळीत चालते; परंतु AI एजंटसाठी ती तिथेच थांबते.

  • एजंट मुख्य HTML पेज पार्स (parse) करतो.
  • बुकिंग बटण दुसऱ्या डोमेनवरील URL कडे निर्देश करते.
  • ब्राउझर ते URL एका iframe मध्ये लोड करतो, ज्यामुळे ते मूळ (parent) पेजपासून वेगळे होते.

'सेम-ओरिजिन पॉलिसी'मुळे (same-origin policy) मूळ पेजमधील स्क्रिप्ट्सना iframe चा DOM वाचण्यापासून किंवा त्याच्या नेटवर्क कॉल्समध्ये हस्तक्षेप करण्यापासून रोखले जाते. त्यामुळे, पेजमधील मजकूर वाचणारा आणि HTTP रिक्वेस्ट पाठवणारा AI एजंट फक्त बटणच पाहू शकतो. त्याला कॅलेंडर, वेळेचे स्लॉट्स किंवा कन्फर्मेशन फ्लो कधीच दिसत नाही. जरी त्याने बटणावर क्लिक केले तरी, त्याला कॅप्चा (captchas) सोडवावे लागतात, लेआउटमधील बदलांशी जुळवून घ्यावे लागते किंवा अनेक बुकिंग सेवांद्वारे वापरल्या जाणाऱ्या अँटी-ऑटोमेशन (anti-automation) संरक्षणापासून वाचून जावे लागते.

मशीन-रीडेबल (machine-readable) लिंकचा अभाव

१६३ कार्यरत रेस्टॉरंट साइट्सच्या स्वतंत्र ऑडिटमध्ये असे आढळले की, केवळ नऊ साइट्सनी मशीन-रीडेबल बुकिंग डेटा उपलब्ध करून दिला होता. त्या नऊ साइट्सनी schema.org मार्कअप वापरून नाव आणि पत्ता यांसारखी मूलभूत माहिती दिली होती, परंतु एजंटद्वारे कार्यान्वित (invoke) करता येतील असे कोणतेही रिझर्व्हेशन ॲक्शन्स त्यात नव्हते. Schema.org या उद्देशासाठी ReserveAction सारखे प्रकार परिभाषित करते, तरीही बहुतेक साइट्स केवळ वर्णनात्मक मेटाडेटा (descriptive metadata) प्रकाशित करतात, कृती करण्यायोग्य सूचना (actionable instructions) नाही.

व्यवहारात, असिस्टंट अशा स्ट्रक्चर्ड डेटाच्या शोधात असतो जो त्याला एखादे काम कसे करायचे हे सांगतो, केवळ ते काम काय आहे हे नाही. ReserveAction किंवा त्यासारख्या एंडपॉइंटशिवाय (endpoint), एजंट मानवी क्लिकची नक्कल करण्याचा प्रयत्न करतो, जे वर सांगितल्याप्रमाणे अविश्वसनीय आहे.

UI न बदलता सुचवलेला एक व्यावहारिक उपाय

  1. बुकिंग API प्रकाशित करा – उपलब्धता तपासण्यासाठी आणि रिझर्व्हेशन तयार करण्यासाठी JSON रिक्वेस्ट स्वीकारणारा एक हलका (lightweight) HTTP एंडपॉइंट तयार करा. API तारीख, वेळ, पाहुण्यांची संख्या आणि कन्फर्मेशन कोड यांसारखी माहिती देईल. कोणताही एजंट पेज रेंडर न करता ही माहिती वापरू शकतो.
  2. API शोधण्यायोग्य बनवा – /.well-known/booking सारख्या सुप्रसिद्ध ठिकाणी पॉइंटर ठेवा किंवा पेजच्या schema.org मार्कअपमध्ये ReserveAction एन्ट्री समाविष्ट करा. यामुळे स्क्रॅपिंगची (scraping) गरज न पडता एजंट्सना "येथे बुकिंग करण्याचा प्रोग्रामॅटिक मार्ग उपलब्ध आहे" हे समजते.
  3. Model Context Protocol (MCP) चा अवलंब करा – MCP असिस्टंट्सना थेट बाह्य टूल्स वापरण्याची परवानगी देते, ज्यामध्ये ते इनपुट पाठवू शकतात आणि स्ट्रक्चर्ड आउटपुट मिळवू शकतात. प्रमुख AI प्रदाते आधीच MCP ला सपोर्ट करतात, त्यामुळे जर एखाद्या रेस्टॉरंटने MCP-सुसंगत एंडपॉइंट लागू केला, तर एजंट्सद्वारे त्याला एखाद्या इन-बिल्ट फंक्शनप्रमाणे कॉल केले जाऊ शकते.

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

निष्कर्ष

iframe मध्ये कॅलेंडर एम्बेड केल्यामुळे मानवांसाठी व्हिज्युअल फ्लो सुरक्षित राहतो, परंतु AI असिस्टंट्ससाठी तो अपारदर्शक ठरतो. एक साधा, चांगल्या प्रकारे दस्तऐवजीकरण (well-documented) केलेला बुकिंग API जोडणे आणि तो स्टँडर्ड मेटाडेटा किंवा MCP द्वारे प्रसिद्ध करणे, वेबसाइटमध्ये मोठे बदल न करता रिझर्व्हेशनचा एक नवीन मार्ग उघडते. या प्रयत्नामुळे पुढील पिढीच्या डिजिटल असिस्टंट्समध्ये तुमची दृश्यमानता (visibility) वाढेल आणि सध्याच्या UI वर वापरल्या जाणाऱ्या सुरक्षा नियंत्रणांद्वारे (security controls) जोखीम व्यवस्थापित केली जाऊ शकते.