على مدى العقدين الماضيين، كادت صناعة الإنترنت بأكملها أن تنشغل بشيء واحد: جعل استخدام البشر للبرمجيات أكثر سهولة.
حلّت Google مشكلة البحث عن المعلومات، وحلّت Amazon مشكلة التسوق عبر الإنترنت، وحلّت Uber مشكلة تنسيق خدمات النقل، وحلّت Salesforce مشكلة إدارة علاقات العملاء. أما منتجات البرمجيات كخدمة (SaaS) المختلفة، فتغطي مجالات المالية والموارد البشرية والتسويق وإدارة المشاريع داخل الشركات.
تشترك هذه المنتجات في افتراض أساسي واحد: أن البشر هم المستخدمون الرئيسيون للبرمجيات. ولذلك، تحتاج شركات البرمجيات إلى مواصلة تحسين واجهات المستخدم، وتسهيل استخدامها، والارتقاء بتجربة التفاعل، ثم تحقيق الإيرادات من خلال الاشتراكات أو الإعلانات أو عمولات المعاملات.
لكن ظهور AI Agent يغير هذا الافتراض. فعندما يستطيع الوكيل فهم المهمة، واستدعاء الأدوات الخارجية، والوصول إلى قواعد البيانات، وتشغيل البرامج، وإتمام المعاملة ضمن حدود التفويض، فلن يعود الإنسان بحاجة إلى تشغيل كل برنامج يدويًا.
الأمر ليس مجرد تغير في أسلوب التفاعل. فعندما ينتقل الفاعل الرئيسي للتشغيل تدريجيًا من البشر إلى الوكلاء، فإن نماذج الأعمال التي بُنيت على مدى عشرين عامًا حول حركة المرور، والاحتفاظ بالمستخدمين، والاشتراكات البرمجية، قد تواجه كلها إعادة تسعير.
البرمجيات الأكثر قيمة في المستقبل قد لا تكون تلك التي يملكها أكبر عدد من المستخدمين البشر، بل تلك التي تستدعيها أكبر عدد من الوكلاء باستمرار.
أولًا: إنفاق SaaS بقيمة 234 مليار دولار يواجه إعادة تسعير
في يوليو 2026، أصدرت Gartner توقعًا يستحق اهتمام صناعة البرمجيات: بحلول عام 2030 قد يؤثر الذكاء الاصطناعي الوكيلي في ما يصل إلى 234 مليار دولار من إنفاق برمجيات التطبيقات المؤسسية، أي نحو 20% من إنفاق SaaS المؤسسي في ذلك الوقت.
تسمي Gartner هذه الظاهرة Agentic Arbitrage (مراجحة الوكلاء)، وتشير إلى قيام الوكلاء بتنفيذ المهام عبر عدة أنظمة، مما يقلل اعتماد الشركات على واجهات التشغيل البرمجية التقليدية وما يرتبط بها من مقاعد المستخدمين.
في الماضي، قد تحتاج شركة تضم 1000 موظف إلى شراء عدد كبير من تراخيص البرمجيات لـCRM وERP وإدارة المشاريع ونظم ذكاء الأعمال. لكن إذا تمكنت بعض الأعمال مستقبلًا من أن تُسند إلى الوكلاء، فلن تحتاج الشركة بالضرورة إلى تخصيص مقعد تشغيل بشري مستقل لكل مرحلة تنفيذ.
لنأخذ عملية المبيعات مثالًا. في الماضي كان موظفو المبيعات يحتاجون إلى إدخال معلومات العملاء يدويًا، وتحديث CRM، وإنشاء عروض الأسعار، وإرسال البريد الإلكتروني، ثم مزامنة بيانات الصفقة مع النظام المالي. أما الآن فأصبحت هذه الخطوات قابلة للربط عبر API وأدوات الأتمتة. والاتجاه القادم هو أن يحدد الوكيل بنفسه، استنادًا إلى أهداف العمل، أي الأنظمة يجب أن يستدعي وأي العمليات يجب أن ينفذ.
لن تفقد CRM وERP قيمتهما بسبب ذلك. فما زالت بيانات العملاء وسجلات الطلبات وبيانات المخزون والدفاتر المالية تحتاج إلى أن تحفظها أنظمة موثوقة، لكن الشركات قد لا تحتاج بعد الآن إلى هذا العدد الكبير من الموظفين لفتح هذه الأنظمة يوميًا وإنجاز العمليات واحدة تلو الأخرى.
سيؤثر هذا مباشرة في تسعير SaaS التقليدي القائم على المقاعد (Seat-based Pricing)، أي نموذج العمل الذي يفرض رسومًا حسب مقعد المستخدم. في الماضي كان أحد أهم مصادر نمو إيرادات شركات البرمجيات هو زيادة عدد الموظفين وحسابات البرامج لدى العميل. وفي المستقبل قد تقل بعض مقاعد التشغيل البشرية، بينما تزداد ميزانيات استدعاءات API والمهام الآلية وتنفيذ الوكلاء.
وقد يتحول نموذج إيرادات شركات البرمجيات أيضًا تدريجيًا من فرض الرسوم حسب عدد الأشخاص إلى فرضها حسب حجم الاستدعاءات وسير العمل ونتائج المهام.
لم تختفِ قيمة البرمجيات، لكن طريقة قياس هذه القيمة قد تتغير.
ثانيًا: Google وAnthropic تبنيان معايير اتصال بين الوكلاء
عندما أحكم على ما إذا كانت تقنية ما قد دخلت فعليًا مرحلة التطبيق الصناعي، فإنني عادةً لا أكتفي بالنظر إلى عدد القدرات الجديدة التي عرضها النموذج، بل أرى هل بدأت الشركات تضخ موارد لبناء معايير تقنية مشتركة.
في عام 2025، أطلقت Google بروتوكول Agent2Agent Protocol (A2A). وفي أبريل 2026، أعلنت Linux Foundation أن A2A حصل على دعم أكثر من 150 منظمة، بما في ذلك شركات مثل Google وMicrosoft وAWS وSalesforce وSAP وServiceNow.
هدف A2A هو تمكين الوكلاء المبنيين على أطر تطوير مختلفة والموزعين من قبل مزودين مختلفين من اكتشاف بعضهم البعض، والتواصل، وتفويض المهام، وتبادل النتائج.
وفي الوقت نفسه، يعمل Model Context Protocol (MCP) الذي طرحته Anthropic في البداية على حل نوع آخر من المشكلات: تمكين أنظمة الذكاء الاصطناعي من الاتصال بالأدوات الخارجية ومصادر البيانات عبر واجهات موحدة.
لا يتطابق التموضع بينهما. فـMCP يحل أساسًا مشكلة Agent-to-Tool، أي كيف يستدعي الوكيل الأدوات؛ بينما A2A يحل أساسًا مشكلة Agent-to-Agent، أي كيف يتعاون الوكلاء المختلفون.
إن تطور هاتين المجموعتين من البروتوكولات يعني أن أنظمة البرمجيات في المستقبل لن تحتاج بالضرورة إلى إجراء التفاعل عبر واجهات بشرية.
لنفترض أن شركة متعددة الجنسيات تحتاج إلى شراء دفعة من الخوادم. يمكن لوكيل المشتريات أولًا الحصول على معلومات المخزون والميزانية، ثم يطلب عرض سعر من وكيل المورّد، ويستدعي خدمة لوجستية لحساب وقت التسليم، وفي النهاية يتحقق نظام المالية من صلاحية الدفع.
ويمكن تنفيذ كل خطوة من هذه الخطوات بواسطة أنظمة طورتها شركات مختلفة. في الماضي كانت الشركات تحتاج إلى كثير من الواجهات المخصصة والتنسيق اليدوي. أما الآن فالصناعة تحاول خفض تكلفة التعاون بين الأنظمة عبر بروتوكولات موحدة.
وبالطبع، توحيد البروتوكولات لا يعني أن كل الأنظمة أصبحت قادرة على التكامل بسلاسة. ما زالت المصادقة وإدارة الصلاحيات وصيغ البيانات ومعالجة الأخطاء تحتاج إلى بناء إضافي، لكن من حيث اتجاه التطور التقني بدأت البرمجيات بالفعل بتصميم طرق التواصل للمستخدمين غير البشريين.
في الماضي كنا نطوّر API أساسًا كي تتمكن البرمجيات المختلفة من تبادل البيانات. أما في المستقبل فقد تصبح هذه الواجهات أساسًا لتمكين الوكلاء من تنفيذ المهام ذاتيًا، وتنسيق الموارد، وشراء الخدمات.
ثالثًا: بدأت Stripe بتمكين الوكلاء من الدفع مباشرة، وأصبحت الآلات فاعلًا استهلاكيًا جديدًا
في عام 2026، أطلقت Stripe بالتعاون مع Tempo بروتوكول Machine Payments Protocol (MPP)، بهدف تمكين الوكلاء من الدفع مباشرة مقابل API والبيانات وغيرها من الموارد الرقمية.
عمليات الدفع في الإنترنت التقليدي موجّهة أساسًا للبشر. يسجل المستخدم حسابًا، ويختار باقة، ويملأ معلومات الدفع، ثم يؤكد الشراء. لكن عند تنفيذ المهام قد يحتاج الوكيل فقط إلى استدعاء واجهة واحدة.
على سبيل المثال، يحتاج وكيل بحث مالي لتحليل أحد الأصول إلى شراء ثلاث خدمات مؤقتًا: بيانات السوق اللحظية، واتجاهات الأموال على السلسلة، وبيانات التقلب التاريخي.
لنفترض أن سعر الاستدعاء الواحد لكل خدمة هو 0.003 و0.005 و0.002 دولار على التوالي. إذا تم الدفع وفق نموذج بطاقات الائتمان التقليدي، فقد تتجاوز الرسوم الثابتة سعر الخدمة نفسه. أما بروتوكولات الدفع الآلي مثل MPP وx402 فهي تحاول جعل هذا النوع من المعاملات الصغيرة، المدفوعة لكل مرة، ممكنًا.
كما بدأت دراسة Visa وArtemis الصادرة في 2026 بمراقبة تطور الدفع الآلي عبر المعاملات الفعلية على السلسلة. وتُظهر الإحصاءات المبكرة ذات الصلة أن الأسابيع الأولى بعد إطلاق MPP عالجت نحو 115 ألف معاملة، بقيمة تسوية تقارب 25 ألف دولار، ومتوسط يقارب 0.22 دولار للمعاملة الواحدة.
ولا تزال هذه البيانات تحتاج إلى الدمج مع معايير القياس وطبيعة المعاملة وظروف الاستخدام الفعلية في بيئة الإنتاج للحكم عليها، ولا يمكن مساواتها مباشرةً بوجود طلب تجاري حقيقي على نطاق واسع. لكن أنماط الدفع التي تعكسها تستحق الدراسة.
في الماضي كانت الخدمات الرقمية تعتمد غالبًا على اشتراك شهري أو سنوي، لأن تحصيل بضع سنتات من مستخدم واحد لم يكن اقتصاديًا. أما في المستقبل، فإذا تمكن الوكيل من الدفع بتكلفة منخفضة، فسوف تتاح لمزودي البيانات فرصة فرض رسوم على كل استعلام، وكل عملية حساب، وكل تنفيذ.
يمكن لشركة لا تملك تطبيقًا للمستهلكين أن تبيع خدمات API احترافية مباشرةً للوكلاء، من دون الحاجة أولًا إلى بناء قناة جذب مرور موجهة للمستخدم العادي.
بالنسبة إلى قطاع التشفير، قد يؤدي هذا إلى طلب جديد على المدفوعات بالعملات المستقرة. لكن العملات المستقرة ليست الخيار الوحيد. فشركات مثل Stripe وVisa تستكشف أيضًا بيانات الاعتماد الخاصة بالبطاقات، وتفويضات الدفع، وعدة طرق للتسوية.
إن كان انتشار الدفع الآلي سيتحقق في النهاية، فذلك يعتمد على التكلفة والسرعة والامتثال التنظيمي وآليات الاسترداد واحتياجات العمل الفعلية، وليس فقط على أي سلسلة كتل يُستخدم عليها.
أحد أهم مستخدمي العملات المستقرة في المستقبل قد لا يكون البشر، بل الوكلاء الذين حصلوا على تفويض ويمكنهم شراء الخدمات الرقمية ذاتيًا.
رابعًا: قد لا يحتاج الإنترنت القادم إلى هذا العدد الكبير من المداخل الموجهة للبشر
في عصر الإنترنت المحمول، كانت الشركات تتنافس على انتباه المستخدمين. فترتيب متاجر التطبيقات، وحركة المرور من محركات البحث، والإعلانات، والاحتفاظ بالمستخدمين، وDAU وMAU، شكّلت منظومة النمو لعدد كبير من المنتجات الرقمية.
لكن سلوك الوكلاء يختلف عن البشر. فقد يتأثر الإنسان عند شراء خدمة بعلامتها التجارية، وإعلاناتها، وتصميم الصفحة، وعاداته في الاستخدام. أما الوكيل، فعند تنفيذ المهمة يمكنه مقارنة الخدمات وفق شروط مسبقة.
على سبيل المثال، إذا احتاج وكيل ما إلى شراء خدمة بيانات فورية، فقد تكون شروط اختياره هي:
زمن تأخر البيانات أقل من 500 مللي ثانية.
إتاحة تتجاوز 99.9% خلال آخر 30 يومًا.
سعر الاستدعاء الواحد أقل من 0.01 دولار.
توفير مصادر بيانات قابلة للتحقق.
دعم API موحّد.
إذا استوفى عدة مزودين الشروط، يمكن للوكيل أن يقارن أيضًا السعر وسرعة الاستجابة ومعدل الأخطاء التاريخي وصلاحيات الخدمة.
في مثل هذا السيناريو، تكاد قيمة تصميم واجهة المستخدم بالنسبة لاستدعاء الآلات تكون معدومة مباشرةً. بل تصبح استقرار الخدمة، وجودة البيانات، وتكلفة الاستدعاء، ووثائق الواجهة القابلة للقراءة آليًا، مؤشرات تنافسية أهم.
وطبعًا لن تختفي العلامة التجارية والسمعة بالكامل. فقد تظل الشركات تطلب من الوكلاء تفضيل المورّدين المعتمدين، أو استدعاء الخدمات التي تتوافق فقط مع سياسات الأمن الداخلية.
لكن طريقة توزيع البرمجيات في المستقبل قد تنقسم بوضوح. جزء سيواصل خدمة البشر عبر التطبيقات والمواقع والبحث ووسائل التواصل الاجتماعي؛ وجزء آخر سيخدم الوكلاء عبر API والبروتوكولات وسجلات الخدمات ووصف القدرات القابل للقراءة آليًا.
سيستمر النظامان في التعايش طويلًا، لكن المنطق التجاري ليس متماثلًا بالكامل. في الماضي كان على المطورين التفكير في كيفية جعل المستخدمين يعثرون على تطبيقاتهم. أما في المستقبل فسيتعين عليهم أيضًا التفكير في كيفية جعل الوكلاء يعثرون على خدماتهم، وكيف يثبتون أنها أكثر موثوقية من غيرها.
وهذا جعلني أبدأ بالتفكير في سؤال واحد:
إذا كان بإمكان الوكلاء مستقبلًا اكتشاف الخدمات ومقارنتها وشرائها ذاتيًا، فمن الذي سيتحكم في مداخل توزيع هذه الخدمات؟
في الماضي كانت Google تسيطر على مدخل البحث، وكانت Apple تسيطر على App Store، وكانت Microsoft تملك عددًا كبيرًا من مداخل العمل المؤسسي. لكن في اقتصاد الوكلاء، قد يحدث اختيار الخدمة بين النموذج، ومنصة تشغيل الوكيل، ونظام التفويض المؤسسي، وشبكة اكتشاف الخدمات.
ولا تحدد هذه الأنظمة فقط ما هي الخدمات التي يستطيع الوكيل العثور عليها، بل قد تؤثر أيضًا في الجهة التي يفضل استدعاءها أولًا.
إذا نضج هذا النظام التوزيعي تدريجيًا، فلن تكون منافسة بوابة الجيل القادم من الإنترنت محصورة بين المتصفحات ومتاجر التطبيقات فقط.
خامسًا: قد لا يكون لدى شركات البرمجيات المستقبلية أي منتج موجه للعامة أصلًا
إذا أنجزت الوكلاء عددًا كبيرًا من المهام في المستقبل، فقد تظهر فرص ريادية جديدة حول البنية التحتية اللازمة لتشغيل هؤلاء الوكلاء.
ما يستحق الدراسة هنا ليس تطوير روبوت محادثة آخر، بل حل مشكلات التعاون الفعلي بين الوكلاء.
أولًا: الهوية والتفويض (Agent Identity & Authorization).
عندما تنشر شركة مئات الوكلاء، يجب أن يمتلك كل وكيل صلاحيات مختلفة. يمكن لوكيل المشتريات شراء البرمجيات، لكنه لا يستطيع تحويل أموال الشركة كلها. ويمكن لوكيل المالية دفع الفواتير، لكنه يجب أن يكون خاضعًا لقيود الميزانية وجهة التحصيل وقواعد الموافقة.
وهذا يعني أن الوكلاء يحتاجون إلى هوية قابلة للتحقق، ونطاق تفويض واضح، وآلية لإلغاء الصلاحيات، وسجل تدقيق كامل للعمليات. خصوصًا في مجالات المالية والمشتريات المؤسسية، قدرة الوكيل على التنفيذ لا تعني أنه يجب أن يمتلك صلاحيات غير محدودة.
ثانيًا: اكتشاف الخدمات (Agent Discovery).
قد يحتاج الوكلاء مستقبلًا إلى البحث عن خدمات خارجية حسب المهمة. فالوكيل المالي يحتاج إلى بيانات على السلسلة، والوكيل القانوني يحتاج إلى قاعدة بيانات تشريعية، والوكيل المطور يحتاج إلى بيئة اختبار.
إذا كان على كل وكيل أن يدمج مسبقًا كل خدمة، فستكون تكاليف التطوير والصيانة مرتفعة جدًا. لذلك قد يحتاج السوق إلى بنية Agent Discovery متخصصة، تتيح للوكيل العثور على المورّدين وفق قدرات الخدمة، والسعر، والصلاحيات، والموثوقية.
ثم يأتي: السمعة والتحقق (Agent Reputation & Verification).
يمكن للبشر الحكم على موثوقية المورّد عبر العلامة التجارية والتقييمات والتعاون الطويل الأمد، لكن الوكلاء يحتاجون إلى مؤشرات أسهل للتحقق الآلي، مثل معدل نجاح المهام، وسجل الإتاحة، ومتوسط زمن الاستجابة، ودقة البيانات، وآليات التعويض والتصحيح عند حدوث الأخطاء.
أكبر تحدٍ تقني هنا ليس إنشاء لوحة ترتيب، بل كيفية التحقق من أن المهمة أُنجزت فعلًا، وكيفية منع مزودي الخدمات من تزوير البيانات أو التلاعب بالتصنيفات.
حتى لو كُتبت السجلات على سلسلة الكتل، فهذا لا يعني أن السجل نفسه صحيح بالضرورة. وما زالت أنظمة السمعة الموثوقة تحتاج إلى تحقق مستقل، ومصادر بيانات قابلة للتتبع، وآليات مسؤولية واضحة.
وأخيرًا: الدفع والتسوية (Agent Payment & Settlement).
عندما يستطيع الوكيل اكتشاف الخدمات، والتحقق من الهوية، وتأكيد السعر، فسيظل بحاجة أيضًا إلى إتمام الدفع بالتفويض، وتسليم الخدمة، وتأكيد النتيجة. وإذا أمكن لهذه الوظائف أن تتشكل كبنية تحتية مستقرة، فقد تدعم عددًا كبيرًا من المعاملات التجارية بين الآلات.
وقد لا يكون Agent Marketplace في المستقبل متجر تطبيقات يتصفحه البشر أصلًا. بل قد يكون مجرد مجموعة API يرسل إليها الوكيل متطلبات المهمة، فيعيد النظام مزودي الخدمة المطابقين للشروط، ثم يُكمل الاستدعاء والفوترة والتحقق من النتيجة.
قد لا يعرف المستهلك العادي بوجود هذه الشركة أصلًا، لكنها قد تعالج ملايين طلبات الخدمة يوميًا.
لم تعد الميزة التنافسية الأساسية لهذه الشركات هي مدى جمال واجهة المستخدم، بل عدد الوكلاء الذين يدمجون خدماتها في سير العمل اليومي.
سادسًا: SaaS التقليدي لن يختفي بالكامل، لكن الحواجز التنافسية ستُعاد توزيعها
هنا يجب التمييز بين أمرين: القيمة الوظيفية للبرمجيات، وواجهة التشغيل البشرية للبرمجيات. قد يقلل AI Agent بدرجة كبيرة من الحاجة إلى الثانية، لكنه لا يعني أن الأولى ستختفي.
ولا تزال الشركات بحاجة إلى قواعد البيانات، والنظم المالية، والمصادقة، وسجلات المعاملات، وإدارة الامتثال. كما يمكن لمورّدي البرمجيات التقليديين الذين يملكون بيانات حصرية وعلاقات مع العملاء المؤسسيين أن يحولوا منتجاتهم طوعًا إلى خدمات للوكلاء.
ليس بالضرورة أن تستبدل الشركات مثل Salesforce وSAP وMicrosoft من قبل شركات جديدة. فهذه الشركات نفسها لديها فرصة لتصبح مورّدًا مهمًا للبنية التحتية في اقتصاد الوكلاء.
الجهات التي ستشعر بالضغط فعلًا هي تلك الشركات التي تفتقر إلى بيانات حصرية، وتفتقر إلى خندق أعمال حقيقي، وتعتمد أساسًا على تعقيد سير العمل وتكاليف انتقال المستخدمين للحفاظ على الإيرادات.
عندما يستطيع الوكيل تشغيل عدة أنظمة مباشرة، قد تضعف ميزة العادة التي توفرها واجهات البرمجيات.
لكن الوكلاء أنفسهم ما زالوا بعيدين جدًا عن النضج بما يكفي لتولي جميع أعمال الشركات. فقد توقعت Gartner أن أكثر من 40% من مشاريع Agentic AI قد تُلغى قبل نهاية عام 2027، ويرجع ذلك أساسًا إلى ارتفاع التكاليف، وعدم وضوح القيمة التجارية، وضعف التحكم في المخاطر.
وهذا يوضح أيضًا أن قدرة النموذج على إنجاز المهمة لا تعني أن الشركة تستطيع نشره على المدى الطويل بتكلفة معقولة.
حتى لو تمكن وكيل ما من إنجاز 95% من المهام في بيئة اختبار، فهذا لا يعني أن الشركة يمكن أن تثق به لإدارة المشتريات والمالية وبيانات العملاء بشكل مستقل. لأن الـ5% المتبقية قد تنطوي على دفع خاطئ، أو تسرب بيانات، أو طلبات مكررة، أو عمليات تجارية غير قابلة للاسترجاع.
لذلك فإن البنية التحتية الحقيقية القيمة للوكلاء في المستقبل ليست بالضرورة المنتج الأكثر ميزات، بل الأنظمة القادرة على العمل باستقرار في بيئات الأعمال الحقيقية، وإدارة مخاطر الأخطاء والصلاحيات والأموال بفعالية.
ولهذا أيضًا قد تصبح المصادقة والتحكم في الصلاحيات وتدقيق التنفيذ والتحقق من نتائج المهام مكونات مهمة في اقتصاد الوكلاء.
سابعًا: لمن يجب أن يطور رواد الأعمال منتجات المستقبل فعلًا؟
في الماضي كان رواد الأعمال عادةً يبدؤون بالتفكير في حجم المستخدمين، وكان الهدف الحصول على مئة ألف أو مليون أو حتى عشرة ملايين مستخدم. وكانت المنتجات تحتاج إلى تحسين الواجهة باستمرار، ورفع الاحتفاظ، ثم تحقيق الدخل عبر الإعلانات أو الاشتراكات أو اقتطاع نسبة من المعاملات.
لكن إذا كان الإنترنت في المستقبل سيضم عددًا كبيرًا من الوكلاء القادرين على تنفيذ المهام ذاتيًا، فعلى رائد الأعمال أن يعيد التفكير فيمن يكون العميل أصلًا.
شركة تقدم بيانات مالية قد لا تحتاج بعد الآن إلى جذب مئة ألف مستثمر يفتحون الموقع يوميًا؛ بل يمكنها أن تقدم مباشرةً واجهات بيانات لعشرات الآلاف من وكلاء الاستثمار.
شركة تقدم خدمة التعرف على الصور، لا تحتاج بالضرورة إلى تطوير تطبيق كامل لتحرير الصور؛ بل يمكنها أن تصبح خدمة احترافية تستدعيها الوكلاء الآخرون عند معالجة المهام البصرية.
ولا تحتاج شركة تقدم خدمات التحقق من الهوية إلى أن تجعل المستهلك العادي يسجل الدخول إلى منصتها يوميًا. طالما أن وكيل المؤسسة لا بد أن يمر عبر نظام التفويض الخاص بها عند تنفيذ المهام الحساسة، فقد يتشكل طلب خدمة مستمر.
أكبر تغيير في هذا النموذج التجاري هو أن الإيرادات لن تعتمد بالكامل بعد الآن على وتيرة استخدام البشر للبرمجيات، بل قد تأتي من استدعاءات المهام المستمرة بين الآلات.
وطبعًا هذا لا يعني أن الوكلاء سيملكون قدرة إنفاق غير محدودة ومستقلة عن البشر. فميزانياتهم ما زالت تأتي من الأفراد والشركات، كما يجب أن تبقى صلاحيات المعاملات تحت السيطرة.
لكن المنفذ الفعلي للميزانية قد ينتقل تدريجيًا من البشر إلى البرمجيات. وعندما يتغير الطرف المنفذ، فإن تصميم المنتج وتوزيع الخدمة وطريقة التسعير ستتغير معه.
في الماضي كان رواد الأعمال يحتاجون إلى دراسة كيفية رفع الاحتفاظ بالمستخدمين وخفض تكلفة اكتساب العملاء. وفي المستقبل قد تولي بعض الشركات الأصلية للذكاء الاصطناعي اهتمامًا أكبر لحجم استدعاءات API، ومعدل إكمال المهام، ومتوسط تكلفة التنفيذ، وعدد الوكلاء الذين يعتمدون باستمرار على خدماتها.
وهذا يعني أيضًا أنه قد تظهر في المستقبل مجموعة من الشركات التقنية تختلف تمامًا عن SaaS التقليدية.
هذه الخدمات لا تملك واجهات أمامية معقدة، ولا تعتمد على ترتيب متاجر التطبيقات، ولا تحتاج إلى أن يسجل عدد كبير من المستهلكين الدخول يوميًا. وقد لا تقدم سوى قدرة متخصصة جدًا، مثل الاستعلام عن البيانات، أو التحقق من الهوية، أو تسوية المدفوعات، أو تنفيذ المهام.
ما دامت هذه القدرة تستدعيها أعداد كافية من الوكلاء بشكل مستمر، فهناك فرصة لتكوين مصدر دخل مستقر.
ثمانية، الوقت المتبقي للبشر ليس كثيرًا
والمقصود بـ"البشر" هنا ليس أن البشر على وشك أن يستبدلهم الذكاء الاصطناعي، بل إن منظومة البرمجيات التي بُنيت خلال العقدين الماضيين حول النقر البشري والتصفح والتشغيل قد تكون دخلت مرحلة تحول.
في عصر الإنترنت المحمول، كان رواد الأعمال يدرسون كيف يجعلون البشر يحمّلون المزيد من التطبيقات. أما في عصر الوكلاء، فيحتاج رواد الأعمال إلى دراسة كيفية جعل خدماتهم تُكتشف وتُستدعى من قبل عدد أكبر من الوكلاء.
في الماضي كانت شركات البرمجيات تعتمد على عدد المستخدمين، ومدة الاستخدام، ونمو مقاعد الاشتراك لتحقيق النمو. وفي المستقبل قد تعتمد بعض شركات البرمجيات على استدعاءات API، وتنفيذ المهام، وتبادل البيانات، والخدمات الآلية لتحقيق الإيرادات.
كانت المداخل التجارية الأساسية في الإنترنت الماضي هي محركات البحث، والمتصفحات، ومتاجر التطبيقات. أما في المستقبل فقد تظهر أيضًا شبكات اكتشاف وهوية وسمعة ودفع وتنفيذ مخصصة لخدمة الوكلاء.
وهذا أيضًا غيّر حكمي على شركات التكنولوجيا الناشئة من الجيل التالي.
لم أعد أعتقد أن كل شركة برمجيات ذات قيمة يجب أن تمتلك تطبيقًا موجهًا للمستهلك العادي. فإذا كانت الشركة قادرة على توفير بيانات أو أدوات أو بنية تحتية يحتاج إليها ملايين الوكلاء يوميًا، فقد تبني حجمًا تجاريًا كبيرًا حتى من دون واجهة مستخدم معقدة.
أما البرمجيات التي ما زالت تعتمد على النقر المتكرر من الإنسان، والنسخ، والملء، والتنقل بين الصفحات لإنجاز العمل، فستواجه على الأرجح ضغطًا متزايدًا في المستقبل.
في الماضي كنا نطوّر البرمجيات كي يستخدم البشر الحاسوب. أما في المستقبل فقد نطوّر البرمجيات كي تستخدم الوكلاء برمجيات أخرى.
إذا بدأت اليوم شركة تقنية من الصفر، فسأفكر بجدية في سؤال نادرًا ما طرحه أحد من قبل:
لماذا يجب أن يُصمم منتجي ليُستخدم من قبل البشر أصلًا؟
إذا كان هناك مستقبل يحتاج فيه ملايين الوكلاء إلى شراء البيانات، والتحقق من الهوية، واستدعاء الأدوات، ودفع الرسوم، والبحث عن وكلاء آخرين لإنجاز المهام، فإن بناء البنية التحتية لهذه الاحتياجات قد يكون أكثر جدوى من تطوير تطبيق عادي للمستهلكين مرة أخرى.