ആംസ്റ്റർഡാമിലെ 200 റെസ്റ്റോറന്റുകളിൽ ജൂലൈ മാസത്തിൽ നടത്തിയ ഒരു പരീക്ഷണം കാണിക്കുന്നത്, ബുക്കിംഗ് വിഡ്ജറ്റ് (widget) ഒരു iframe-നുള്ളിൽ ഒളിഞ്ഞിരിക്കുന്നതിനാൽ നിലവിലെ AI അസിസ്റ്റന്റുകൾക്ക് ടേബിൾ റിസർവേഷൻ പൂർത്തിയാക്കാൻ കഴിയില്ല എന്നാണ്.

എന്തുകൊണ്ടാണ് iframe ഏജന്റുകളെ തടയുന്നത്

മിക്ക ഓൺലൈൻ റിസർവേഷൻ ടൂളുകളും എംബെഡഡ് (embedded) iframe ആയിട്ടാണ് നൽകുന്നത്. ഒരു സന്ദർശകൻ “Reserve” ബട്ടണിൽ ക്ലിക്ക് ചെയ്യുമ്പോൾ ഒരു കലണ്ടർ പ്രത്യക്ഷപ്പെടുകയും ഉപയോക്താവിന് ഒരു സമയക്രമം (time slot) തിരഞ്ഞെടുക്കാൻ സാധിക്കുകയും ചെയ്യുന്നു. ഒരു മനുഷ്യനെ സംബന്ധിച്ചിടത്തോളം ഈ പ്രക്രിയ സുഗമമാണ്; എന്നാൽ ഒരു AI ഏജന്റിനെ സംബന്ധിച്ചിടത്തോളം ഇത് തടസ്സപ്പെടുന്നു.

  • ഏജന്റ് പ്രധാന HTML പേജ് വിശകലനം ചെയ്യുന്നു (parses).
  • ബുക്കിംഗ് ബട്ടൺ മറ്റൊരു ഡൊമൈനിലെ ഒരു URL-ലേക്ക് വിരൽ ചൂണ്ടുന്നു.
  • ബ്രൗസർ ആ URL ഒരു iframe-നുള്ളിൽ ലോഡ് ചെയ്യുന്നു, ഇത് അതിനെ പാരന്റ് പേജിൽ നിന്ന് വേർതിരിക്കുന്നു.

സെയിം-ഒറിജിൻ പോളിസി (same-origin policy) കാരണം, പാരന്റ് പേജിലെ സ്ക്രിപ്റ്റുകൾക്ക് iframe-ന്റെ DOM വായിക്കാനോ അതിന്റെ നെറ്റ്‌വർക്ക് കോളുകൾ തടയാനോ (intercept) കഴിയില്ല. അതിനാൽ, പേജ് ഉള്ളടക്കം വായിക്കുകയും HTTP റിക്വസ്റ്റുകൾ അയക്കുകയും ചെയ്യുന്ന ഒരു AI ഏജന്റിന് ബട്ടൺ മാത്രമേ കാണാൻ കഴിയൂ. കലണ്ടറോ, സമയക്രമങ്ങളോ, കൺഫർമേഷൻ പ്രക്രിയയോ അതിന് കാണാൻ കഴിയില്ല. ബട്ടണിൽ ക്ലിക്ക് ചെയ്താലും, കാപ്‌ചകൾ (captchas) പരിഹരിക്കുകയോ, ലേഔട്ട് മാറ്റങ്ങളോട് പൊരുത്തപ്പെടുകയോ, അല്ലെങ്കിൽ പല ബുക്കിംഗ് സേവനങ്ങളും ഉപയോഗിക്കുന്ന ആന്റി-ഓട്ടോമേഷൻ പ്രതിരോധങ്ങളെ മറികടക്കുകയോ ചെയ്യേണ്ടി വരും.

വിട്ടുപോയ മെഷീൻ-റീഡബിൾ ലിങ്ക്

പ്രവർത്തനക്ഷമമായ 163 റെസ്റ്റോറന്റ് സൈറ്റുകളിൽ നടത്തിയ പ്രത്യേക ഓഡിറ്റിൽ, മെഷീൻ-റീഡബിൾ ബുക്കിംഗ് ഡാറ്റ ലഭ്യമാക്കുന്ന ഒൻപത് സൈറ്റുകൾ മാത്രമാണ് കണ്ടെത്തിയത്. ആ ഒൻപത് സൈറ്റുകളും schema.org മാർക്കപ്പ് ഉപയോഗിച്ച് പേരും വിലാസവും പോലുള്ള അടിസ്ഥാന വിവരങ്ങൾ നൽകിയിരുന്നു, എന്നാൽ ഒരു ഏജന്റിന് ഉപയോഗിക്കാൻ കഴിയുന്ന റിസർവേഷൻ ആക്ഷനുകൾ (reservation actions) അവയിൽ ഉണ്ടായിരുന്നില്ല. Schema.org ഇതിനായി ReserveAction പോലുള്ള ടൈപ്പുകൾ നിർവചിച്ചിട്ടുണ്ടെങ്കിലും, മിക്ക സൈറ്റുകളും വിവരണാത്മകമായ മെറ്റാഡാറ്റ (descriptive metadata) മാത്രമാണ് പ്രസിദ്ധീകരിക്കുന്നത്, പ്രവർത്തനക്ഷമമായ നിർദ്ദേശങ്ങളല്ല.

പ്രായോഗികമായി പറഞ്ഞാൽ, ഒരു അസിസ്റ്റന്റ് ഒരു ടാസ്ക് എന്താണെന്ന് അറിയുന്നതിനേക്കാൾ ഉപരിയായി, അത് എങ്ങനെ ചെയ്യണമെന്ന് പറയുന്ന സ്ട്രക്ചേർഡ് ഡാറ്റയാണ് (structured data) തിരയുന്നത്. ഒരു ReserveAction അല്ലെങ്കിൽ സമാനമായ എൻഡ്പോയിന്റ് (endpoint) ഇല്ലാതെ, ഏജന്റ് ഒരു മനുഷ്യന്റെ ക്ലിക്കിനെ അനുകരിക്കാൻ ശ്രമിക്കുന്നു, ഇത് മുകളിൽ പറഞ്ഞതുപോലെ വിശ്വസനീയമല്ല.

UI മാറ്റം വരുത്താതെ ചെയ്യാവുന്ന ഒരു പ്രായോഗിക പരിഹാരം

  1. ഒരു ബുക്കിംഗ് API പ്രസിദ്ധീകരിക്കുക – ലഭ്യത പരിശോധിക്കുന്നതിനും (availability queries) റിസർവേഷൻ ചെയ്യുന്നതിനുമായി JSON റിക്വസ്റ്റുകൾ സ്വീകരിക്കുന്ന ഒരു ലഘുവായ HTTP എൻഡ്പോയിന്റ് നിർമ്മിക്കുക. തീയതി, സമയം, ആളുകളുടെ എണ്ണം, കൺഫർമേഷൻ കോഡ് തുടങ്ങിയ വിവരങ്ങൾ API നൽകുന്നു. ഒരു പേജ് റെൻഡർ ചെയ്യാതെ തന്നെ ഏത് ഏജന്റിനും ഇത് ഉപയോഗിക്കാം.
  2. API കണ്ടെത്താൻ എളുപ്പമാക്കുക – /.well-known/booking പോലുള്ള സുപരിചിതമായ ഒരു സ്ഥലത്ത് ഒരു പോയിന്റർ നൽകുക, അല്ലെങ്കിൽ പേജിന്റെ schema.org മാർക്കപ്പിൽ ഒരു ReserveAction എൻട്രി ഉൾപ്പെടുത്തുക. ഇത് സ്ക്രാപ്പിംഗ് (scraping) ആവശ്യമില്ലാതെ തന്നെ, "ഇവിടെ പ്രോഗ്രാമാറ്റിക് ആയി ബുക്ക് ചെയ്യാൻ ഒരു വഴിയുണ്ട്" എന്ന് ഏജന്റുകളെ അറിയിക്കുന്നു.
  3. Model Context Protocol (MCP) സ്വീകരിക്കുക – ഇൻപുട്ടുകൾ കൈമാറാനും സ്ട്രക്ചേർഡ് ഔട്ട്പുട്ടുകൾ സ്വീകരിക്കാനും MCP അസിസ്റ്റന്റുകളെ നേരിട്ട് ബാഹ്യ ടൂളുകൾ ഉപയോഗിക്കാൻ അനുവദിക്കുന്നു. പ്രമുഖ AI പ്രൊവൈഡർമാർ ഇതിനകം തന്നെ MCP പിന്തുണയ്ക്കുന്നുണ്ട്, അതിനാൽ ഒരു MCP-അനുയോജ്യമായ എൻഡ്പോയിന്റ് നടപ്പിലാക്കുന്ന റെസ്റ്റോറന്റിനെ ഒരു ഇൻ-ബിൽറ്റ് ഫംഗ്ഷൻ പോലെ ഏജന്റുകൾക്ക് ഉപയോഗിക്കാം.

ഈ നടപടികൾ വഴി മനുഷ്യ ഉപയോക്താക്കൾക്കായി വിഷ്വൽ iframe നിലനിർത്തുന്നതോടൊപ്പം തന്നെ, ഏജന്റുകൾക്ക് റിസർവേഷൻ ഡാറ്റയിലേക്ക് സുഗമവും വിശ്വസനീയവുമായ ഒരു പാതയും നൽകാൻ സാധിക്കും.

ചുരുക്കത്തിൽ

ഒരു കലണ്ടർ iframe-നുള്ളിൽ ഉൾപ്പെടുത്തുന്നത് മനുഷ്യർക്കുള്ള വിഷ്വൽ പ്രക്രിയയെ സംരക്ഷിക്കുന്നുണ്ടെങ്കിലും AI അസിസ്റ്റന്റുകളെ അന്ധരാക്കുന്നു. ലളിതവും കൃത്യമായി രേഖപ്പെടുത്തിയതുമായ ഒരു ബുക്കിംഗ് API ചേർക്കുന്നതും അത് സ്റ്റാൻഡേർഡ് മെറ്റാഡാറ്റയിലൂടെയോ MCP വഴിയോ പ്രമോട്ട് ചെയ്യുന്നതും വെബ്‌സൈറ്റ് പൂർണ്ണമായി മാറ്റാതെ തന്നെ പുതിയൊരു റിസർവേഷൻ ചാനൽ തുറക്കുന്നു. ഈ ശ്രമം അടുത്ത തലമുറയിലെ ഡിജിറ്റൽ അസിസ്റ്റന്റുകൾക്കിടയിൽ വെബ്‌സൈറ്റിന്റെ ദൃശ്യപരത വർദ്ധിപ്പിക്കും, കൂടാതെ നിലവിലുള്ള UI-ൽ ഉപയോഗിക്കുന്ന അതേ സുരക്ഷാ നിയന്ത്രണങ്ങളിലൂടെ തന്നെ ഇതിലെ റിസ്ക് മാനേജ് ചെയ്യാനും സാധിക്കും.