జూలైలో జరిగిన 200 ఆమ్‌స్టర్‌డామ్ రెస్టారెంట్ల పరీక్షలో, బుకింగ్ విడ్జెట్ ఒక iframe లోపల దాగి ఉండటం వల్ల ప్రస్తుత AI అసిస్టెంట్‌లు టేబుల్ రిజర్వేషన్‌ను పూర్తి చేయలేకపోతున్నాయని తేలింది.

iframe ఎందుకు ఏజెంట్‌లను అడ్డుకుంటుంది

చాలా ఆన్‌లైన్ రిజర్వేషన్ సాధనాలు ఎంబెడెడ్ iframe రూపంలో ఉంటాయి. సందర్శకుడు “Reserve” బటన్‌పై క్లిక్ చేసినప్పుడు, ఒక క్యాలెండర్ కనిపిస్తుంది మరియు వినియోగదారు ఒక సమయాన్ని ఎంచుకుంటారు. మనుషులకు ఈ ప్రక్రియ సులభంగా ఉంటుంది; కానీ AI ఏజెంట్‌కు ఇది ఆగిపోతుంది.

  • ఏజెంట్ ప్రధాన HTML పేజీని విశ్లేషిస్తుంది (parses).
  • బుకింగ్ బటన్ వేరొక డొమైన్‌లోని URLని సూచిస్తుంది.
  • బ్రౌజర్ ఆ URLని ఒక iframe లోపల లోడ్ చేస్తుంది, దీనివల్ల అది పేరెంట్ పేజీ నుండి వేరు చేయబడుతుంది.

సేమ్-ఓరిజిన్ పాలసీ (same-origin policy) కారణంగా, పేరెంట్ పేజీలోని స్క్రిప్ట్‌లు iframe యొక్క DOMని చదవలేవు లేదా దాని నెట్‌వర్క్ కాల్స్‌ను అడ్డుకోలేవు. కాబట్టి, పేజీ కంటెంట్‌ను చదివి HTTP రిక్వెస్ట్‌లను పంపే AI ఏజెంట్‌కు కేవలం బటన్ మాత్రమే కనిపిస్తుంది. దానికి క్యాలెండర్, టైమ్ స్లాట్లు లేదా కన్ఫర్మేషన్ ప్రక్రియ కనిపించవు. ఒకవేళ అది బటన్‌ను క్లిక్ చేసినప్పటికీ, అది క్యాప్చాలను (captchas) పరిష్కరించాల్సి ఉంటుంది, లేఅవుట్ మార్పులకు అనుగుణంగా మారాల్సి ఉంటుంది లేదా అనేక బుకింగ్ సర్వీసులు ఉపయోగించే యాంటీ-ఆటోమేషన్ రక్షణ చర్యల నుండి తప్పించుకోవాల్సి ఉంటుంది.

లేని మెషిన్-రీడబుల్ లింక్

163 పని చేసే రెస్టారెంట్ సైట్‌లపై చేసిన ప్రత్యేక ఆడిట్‌లో, మెషిన్-రీడబుల్ బుకింగ్ డేటాను అందించేవి కేవలం తొమ్మిది మాత్రమే అని తేలింది. ఆ తొమ్మిది సైట్లు schema.org మార్కప్‌ను ఉపయోగించి పేరు మరియు చిరునామా వంటి ప్రాథమిక సమాచారాన్ని జాబితా చేశాయి, కానీ ఏదీ ఏజెంట్ ఉపయోగించగల రిజర్వేషన్ చర్యలను (reservation actions) చేర్చలేదు. Schema.org ఈ ప్రయోజనం కోసం ReserveAction వంటి రకాలను నిర్వచిస్తుంది, అయినప్పటికీ చాలా సైట్లు కేవలం వివరణాత్మక మెటాడేటాను మాత్రమే ప్రచురిస్తాయి, అమలు చేయగల సూచనలను (actionable instructions) కాదు.

వాస్తవానికి, ఒక అసిస్టెంట్ ఒక పనిని ఎలా చేయాలో చెప్పే స్ట్రక్చర్డ్ డేటా కోసం వెతుకుతుంది, కేవలం పని ఏమిటో మాత్రమే కాదు. ReserveAction లేదా దానికి సమానమైన ఎండ్‌పాయింట్ లేకపోతే, ఏజెంట్ మనిషి క్లిక్ చేసినట్లుగా అనుకరించడానికి ప్రయత్నిస్తుంది, ఇది పైన వివరించినట్లుగా నమ్మదగినది కాదు.

UIని మార్చకుండా చేయగల ఒక ఆచరణాత్మక పరిష్కారం

  1. బుకింగ్ APIని ప్రచురించండి – లభ్యత (availability) కోసం మరియు రిజర్వేషన్ సృష్టి కోసం JSON రిక్వెస్ట్‌లను స్వీకరించే తేలికపాటి HTTP ఎండ్‌పాయింట్‌ను సృష్టించండి. ఈ API తేదీ, సమయం, వ్యక్తుల సంఖ్య మరియు కన్ఫర్మేషన్ కోడ్ వంటి ఫీల్డ్‌లను తిరిగి ఇస్తుంది. ఏ ఏజెంట్ అయినా పేజీని రెండర్ చేయకుండానే దీనిని ఉపయోగించుకోవచ్చు.
  2. APIని సులభంగా కనుగొనేలా చేయండి/.well-known/booking వంటి సుపరిచితమైన ప్రదేశంలో ఒక పాయింటర్‌ను ఉంచండి లేదా పేజీ యొక్క schema.org మార్కప్‌లో ReserveAction ఎంట్రీని చేర్చండి. ఇది స్క్రాపింగ్ అవసరం లేకుండానే, "ఇక్కడ బుక్ చేయడానికి ప్రోగ్రామాటిక్ మార్గం ఉంది" అని ఏజెంట్‌లకు తెలియజేస్తుంది.
  3. Model Context Protocol (MCP)ని అనుసరించండి – MCP అసిస్టెంట్‌లు నేరుగా బాహ్య సాధనాలను (external tools) ఉపయోగించుకోవడానికి, ఇన్‌పుట్‌లను పంపడానికి మరియు స్ట్రక్చర్డ్ అవుట్‌పుట్‌లను పొందడానికి అనుమతిస్తుంది. ప్రధాన AI ప్రొవైడర్లు ఇప్పటికే MCPని సపోర్ట్ చేస్తున్నారు, కాబట్టి MCP-అనుకూల ఎండ్‌పాయింట్‌ను అమలు చేసే రెస్టారెంట్, ఏజెంట్‌ల ద్వారా ఒక బిల్ట్-ఇన్ ఫంక్షన్‌లా పిలవబడగలదు.

ఈ దశల వల్ల మానవ వినియోగదారుల కోసం విజువల్ iframe అలాగే ఉంటుంది, అదే సమయంలో ఏజెంట్‌లకు అదే రిజర్వేషన్ డేటా కోసం ఒక స్పష్టమైన, నమ్మదగిన మార్గం లభిస్తుంది.

ముఖ్య అంశం

ఒక iframe లోపల క్యాలెండర్‌ను ఎంబెడ్ చేయడం వల్ల మనుషులకు విజువల్ ఫ్లో సురక్షితంగా ఉంటుంది కానీ AI అసిస్టెంట్‌లు దాన్ని గుర్తించలేవు. ఒక చిన్న, చక్కగా డాక్యుమెంట్ చేయబడిన బుకింగ్ APIని జోడించడం మరియు దానిని స్టాండర్డ్ మెటాడేటా లేదా MCP ద్వారా ప్రచారం చేయడం వల్ల వెబ్‌సైట్‌ను పూర్తిగా మార్చకుండానే కొత్త రిజర్వేషన్ ఛానెల్‌ను అందుబాటులోకి తీసుకురావచ్చు. ఈ ప్రయత్నం తదుపరి తరం డిజిటల్ అసిస్టెంట్‌లకు కనిపించేలా (visibility) చేస్తుంది, మరియు దీనివల్ల కలిగే రిస్క్‌ను ఇప్పటికే ఉన్న UIలో ఉపయోగిస్తున్న భద్రతా నియంత్రణలతోనే నిర్వహించవచ్చు.