لديّ صديق يدير متجرًا صغيرًا عبر الإنترنت، وفي الشهر الماضي سمح لبرنامج نصي بإعادة طلب المخزون تلقائيًا. وبعد يومين، اكتشف أن البرنامج استهلك معظم ميزانيته الشهرية لدى مورّد واحد، لأن لا شيء أخبره متى يتوقف. والآن يوافق على كل دفعة يدويًا. تذكّرت تلك القصة حين ألقيت نظرة فاحصة على طريقة تعامل @KITE AI (KITE) مع مدفوعات الوكلاء.

المشكلة هي نفسها التي واجهها صديقي. إما أن توافق على كل شيء بنفسك، فيظل الوكيل منتظرًا، أو تمنحه صلاحية كاملة وتأمل خيرًا. وتصف وثائق Kite طريقة ثالثة: تنشئ جلسة إنفاق بميزانية إجمالية وحدّ لكل معاملة، وتوافق عليها مرة واحدة، وبعدها يستطيع الوكيل الإنفاق ضمن تلك الحدود من دون أن يطلب منك الموافقة مجددًا، إلى أن تنتهي صلاحية الجلسة أو تنفد ميزانيتها.

ما جعل فكرة Kite تتضح لي هو آلية العمل. يطلب الوكيل خدمةً ما، فتردّ الخدمة بالرمز 402 Payment Required مع شروطها، ثم يدفع وكيل Passport من الجلسة المعتمدة، وتتحقق الخدمة من إثبات الدفع قبل تقديم أي شيء. وهكذا يصبح الدفع جزءًا من الطلب نفسه، بدلًا من أن يكون خطوة منفصلة يتعين على شخص الإشراف عليها.

وبدا أن جانب السرعة مدروس أيضًا. معاملتان على السلسلة، واحدة للفتح وأخرى للإغلاق، وبينهما آلاف التحديثات الموقّعة خارج السلسلة، بزمن استجابة يقل عن مئة مللي ثانية، وبتكلفة دولار واحد لكل مليون طلب. هذا هو المستوى الذي تصبح عنده مدفوعات الوكلاء الصغيرة مجدية.

ما منعني من استبعاد Kite هو طبقات الهوية. فاختراق جلسة لا يؤثر إلا في تفويض واحد، والوكيل المخترق يظل ضمن الحدود التي وضعها المستخدم، كما تبقى مفاتيح المستخدم في بيئات آمنة محلية. لم يكن لدى برنامج صديقي النصي أيّ من هذه الحواجز.

ما زلت غير متأكد من قدرة Kite على الصمود حين تعمل أعداد كبيرة من الوكلاء وتتحرك أموال حقيقية عبرها في الوقت نفسه. فهل تكفي حدود الجلسات والهوية متعددة الطبقات فعلًا للحفاظ على أمان اقتصاد الوكلاء على نطاق واسع، أم أن المخاطر تنتقل ببساطة إلى الطريقة التي يضع بها الناس تلك الحدود من الأساس؟ هذا هو السؤال الذي سأتابع إجابته $KITE .
@KITE AI $KITE #KiteBBW