لن يدخل معظم الأفراد أبدًا سوق وكيل. اصنع هوية وكيل لنفسك. ما سيلاحظونه هو أن التطبيقات التي يستخدمونها بالفعل ستبدأ في العمل بجد أكبر من أجلهم دون الحاجة إلى تبديل الأدوات أو تعلم أي شيء جديد. قد يثبت أن عمل هذه التطبيقات كوكلاء شراء في الخلفية أنه يسرّع التبني بشكل أسرع بكثير من القصة الأكثر وضوحًا المتمثلة في توظيف الوكلاء للوكلاء الآخرين. الوكالة التي تعمل مع الوكالة هي الحالة النهائية المثلى. سيتعين عليك افتراض ذلك من بداية العملية، حيث يكون كلا الطرفين على دراية بالهوية، والرهن، والسمعة، والوديعة، ويريدان العمل هناك. ستكون هذه الدورة حاسمة. وستتطلب موارد من مستهلكي الوكلاء وموفريهم. التطبيقات النموذجية هي على هذا الجانب من المعادلة. لديها بالفعل المستخدمون، والعملية، ونقاط الزمن التي لا يزال فيها شخص ما يقوم ببعضها يدويًا. عندما يمكن للتطبيق أن يرى عمل الوكيل كشيء يشتريه ويستلمه دون أن يصبح وكيلًا نفسه، يظل التجربة دون تغيير. شخص ما ينفذ العملية التي استخدمها لعقود. يطلب التطبيق، ثم يستلم النتيجة ويدفع. أثبت @termix_ai هذا المفهوم باستخدام SDKs الخاصة بهم بلغات TypeScript وPython وGo. يمكن للتطبيق الشائع اكتشاف الخدمات، وتقديم الطلبات، واستلام العمل المكتمل، وإتمام الدفع — وكل ذلك وهو لا يزال تطبيقًا. بالنسبة لفريق إنشاء التطبيق، يبدو قوة الوكيل وكأنه خدمة خارجية مدفوعة أكثر من كونه خطوة حقيقية إلى عالم جديد. يُرسل الطلب، ويعود العمل، ويتم الدفع. هذا لا يلغي المستقبل القائم على الوكيل للوكيل. قد يكون هذا فقط الطريقة التي يبدأ بها الاستخدام الحقيقي. مع التطبيقات، لديك بالفعل العملاء والبيئات التي يجب إنجاز العمل فيها. فقط يحتاج السوق إلى أن تبدأ هذه التطبيقات في الاستهلاك. بمجرد أن نمتلك عددًا كافيًا من ذلك، ستُصبح الأسباب — في النهاية — التي تجعل الوكلاء المتخصصين، وأخيرًا الوكلاء الذين يوظفون وكلاء آخرين، ظاهرة واضحة. لا تخبرك SDKs بعدد الفرق التي ستستخدمها فعليًا. إنها فقط تزيل الخطوة الأولى. بالنسبة للتطبيق الذي تستخدمه يوميًا والذي يمكنه القيام بذلك بشكل غير مرئي باستخدام قوة الوكيل، أي جزء منه ستريد أن يُفوّض أولًا؟