يحتوي موقع Latch على سطر في أسفل وثائق واجهة برمجة تطبيقات طلب الوصول: "هل يملأ الوكيل هذا النموذج؟ POST /access-requests (انظر /llms.txt)." هذه تفصيلة صغيرة تعكس شيئًا محددًا حول كيفية تصميم المنتج. معظم أدوات المطورين مصممة للبشر الذين يقرأون الوثائق ويكتبون الكود. أما Latch، فهو مصمم مع توقع أن الكيان الذي يطلب الوصول قد يكون برنامجًا نفسه، وأن هذا البرنامج يحتاج إلى وثيقة سياسة قابلة للقراءة آليًا لفهم ما يُسمح له بطلبه. إن معيار /llms.txt يظهر كمعيار لتقديم معلومات منظمة لأنظمة الذكاء الاصطناعي حول خدمة معينة. إن تطبيق Latch لهذا المعيار للتحكم في الوصول يعني أن الوكيل يمكنه قراءة السياسة التي تحكم وصوله قبل تقديم طلب. ليس إنسانًا يقرأ الوثائق وينفذ إعدادات الوكيل، بل الوكيل نفسه الذي يقرأ الوثائق ويعمل ضمن الحدود المحددة. هذا يُغلق حلقة تتركها معظم بنى تحتية للوكيلات مفتوحة. قام @RialoHQ ببناء Latch لفرض ما يُسمح للوكيلات بفعله. يعني نقطة النهاية /llms.txt أن الوكيلات يمكنها أيضًا فهم ما يُسمح لها بفعله قبل محاولة القيام به. تصبح طبقة الحوكمة قابلة للقراءة من قبل الخاضعين لها. بالنسبة لأي شخص يبني أنظمة ذاتية تحتاج للعمل بمسؤولية ضمن حدود محددة، فهذا ليس ملاحظة صغيرة. بل هو فلسفة التصميم التي تحوّلت إلى واقع ملموس.