وكلاء الذكاء الاصطناعي داخل أدوات العمل: ما الذي يكشفه Buzz لفرق العمليات

تخيّل مدير العمليات لديك يفتح أداةً واحدة في الصباح — وبداخلها، وكيل ذكاء اصطناعي سبق أن رتّب رسائل الموردين الواردة خلال الليل، وأشار إلى شذوذ في أمر شراء داخل الـ ERP، وفتح إصلاحاً برمجياً في الخيط ذاته. هذا ليس عرضاً تسويقياً. هذا بالضبط ما أطلقته Block في 21 يوليو 2026، بمنصة اسمها Buzz. ^[1]

الأهمية ليست في أن Jack Dorsey بنى منافساً لـ Slack. الأهمية أن Buzz تجعل بيئة تشغيل الوكيل — أي البيئة التنفيذية التي تعمل فيها وكلاء الذكاء الاصطناعي وتتصرف — جزءاً لا يتجزأ من المكان الذي يعمل فيه فريقك أصلاً. هذا يُعيد صياغة قرار شراء لم تتخذه معظم فرق العمليات في منطقة الخليج بالشكل الصحيح بعد.

ما هو Buzz فعلاً — ولماذا ليس مجرد تطبيق دردشة آخر

Buzz هو بيئة عمل مفتوحة المصدر تجمع الموظفين ووكلاء الذكاء الاصطناعي ومستودعات الأكواد والمحادثات خلف نظام هوية موحّد. ^[1] كل رسالة، وكل خطوة في سير العمل، وكل حدث برمجي، وكل موافقة — يُخزَّن كحدث موقَّع تشفيرياً على ترحيل Nostr قابل للاستضافة الذاتية. الموظفون البشريون والوكلاء على حدٍّ سواء يمتلكون أزواج مفاتيح خاصة بهم، وعضويات في القنوات، ومسارات تدقيق مستقلة.

هذه التفصيلة الأخيرة مهمة تشغيلياً. الوكلاء في Buzz ليسوا روبوتات دردشة تستعلم منها. إنهم مشاركون بهويات قابلة للتحقق. يمكنهم البحث في النقاشات السابقة، وفتح المستودعات، وتقديم تعديلات، ومراجعة الأكواد، وتشغيل سير العمل. ^[1] كانت ردة فعل Hacker News لافتة: أظهرت لقطات الشاشة وكلاءً بـ"أسماء لطيفة" يتبادلون إيموجيات مرحة في منتصف نقاشات هندسية جدية، مما أزعج المهندسين الذين يفضّلون العمل مع بشر. ^[2] الجماليات قابلة للنقاش. البنية التقنية ليست كذلك.

المبرر المُعلَن من Dorsey هو أن الذكاء الاصطناعي يجب أن يُغيّر كيفية تنسيق المؤسسات، لا أن يكون مجرد إضافة لتحسين الإنتاجية. Buzz هو طبقة البنية التحتية لهذه الفرضية، بُنيت لتقليل اعتماد Block على Slack وGitHub في آنٍ واحد. ^[1]

نمط الوكيل المُدمَج: سطح واحد يهيمن على الجميع

Buzz ليس تجربة معزولة. إنه أوضح تعبير حتى الآن عن نمط بات واضحاً عبر برمجيات المؤسسات: يقوم الموردون بدمج الدردشة والتنفيذ الذكي والتكامل في سطح واحد، وبيئة تشغيل الوكيل هي الجائزة الحقيقية.

Microsoft تلعب اللعبة ذاتها من الاتجاه المعاكس. بدلاً من بناء سطح تعاون جديد، تضمّن بيئات تشغيل الوكلاء داخل منصتها القائمة — Teams وCopilot وDynamics 365 — انطلاقاً من مبدأ أنه إذا أصبح الوكلاء طبقة التطبيقات الجديدة، فإن المنصة التي تستضيفهم ستصبح ذات أهمية بالغة. ^[4] تناولنا هذه الديناميكية بعمق أكبر في هل وكلاء الذكاء الاصطناعي أكبر تحوّل في Dynamics 365 منذ السحابة؟

التعريف التقني يُفيد هنا. بيئة تشغيل وكيل الذكاء الاصطناعي هي البيئة التنفيذية التي يعمل فيها الوكلاء — تتولى التنسيق وإدارة الحالة والأمان والتكامل مع الأنظمة الخارجية. ^[5] الأطر البرمجية تساعد في بناء الوكلاء؛ بيئات التشغيل هي ما يجعل الوكلاء يعملون في الإنتاج الفعلي. المورد الذي يمتلك بيئة التشغيل لديك يمتلك الطبقة العليا من كل قرار آلي تتخذه. هذا هو ما يتعلق به الأمر فعلاً في موجة الوكيل المُدمَج.

بالنسبة للفرق التي تقيّم استثمارات أتمتة سير العمل، يُدمج هذا ما بدا قرارين منفصلين — "أي أداة تعاون؟" و"أي طبقة أتمتة ذكاء اصطناعي؟" — في قرار واحد. المنصة التي تمتلك بيئة تشغيل وكيلك ستحدد حدود ما يمكن لوكلائك رؤيته والتصرف فيه والمساءلة عليه.

ما يعنيه هذا للفرق التي تشغّل بالفعل أنظمة ERP وأتمتة في منطقة الخليج

تواجه فرق العمليات في الخليج نسخةً خاصة من هذه المشكلة. الشركة المتوسطة الحجم النموذجية في أبوظبي أو الخبر تعمل على النحو التالي: ERP (SAP أو Oracle أو Dynamics) يتولى المشتريات والمالية، وطبقة أتمتة منفصلة (Power Automate أو Zapier أو middleware مخصص) تربط الأنظمة، وسلاسل موافقات غير رسمية تجري عبر WhatsApp، وسبعة عشر جدول بيانات تسدّ الفجوات بين كل ما سبق.

هذا ليس افتراضياً — إنه ما نراه في كل تقريباً تدقيق في سير العمل نُجريه. المنظومة تعمل، لكن ليس فيها نقطة حوكمة واحدة للقرارات الآلية. حين تحلّ بيئة تشغيل وكيل داخل منصة تعاون، فهي لا تُحلّ محلّ أيٍّ من هذه الطبقات بشكل نظيف. إنها تجلس فوقها، والآن لديك مشارك جديد — الوكيل — يقرأ من أنظمة ويكتب إليها لم تُصمَّم منطق تكاملها قط مع وجود فاعل مستقل في الاعتبار.

أتمتة سير العمل القائمة على الوكلاء تُضاعف هذا التعقيد. على خلاف قواعد اللعب أو المحفّزات القائمة على القواعد، يُشكّل وكيل الذكاء الاصطناعي نيّته في وقت التشغيل ويسلسل الإجراءات عبر الأنظمة بتسلسلات لم يؤلفها أحد مسبقاً. ^[3] تطالب مجالس الإدارة في آنٍ واحد باعتماد الذكاء الاصطناعي وبحوكمة محكمة. فرق العمليات العالقة في المنتصف تحتاج إلى خريطة واضحة لما يمكن لوكلائها لمسه قبل أن تمنحهم مفاتيح الترحيل.

التمييز بين لوحة المعلومات وطبقة القرار يصبح حاسماً هنا: لوحات المعلومات تُبلّغ عمّا حدث؛ بيئة تشغيل الوكيل المحكومة بشكل صحيح تتصرف. الخلط بين الاثنين — معاملة سطح وكيل مُدمَج جديد كترقية لإعداد التقارير بدلاً من طبقة تنفيذية — هو كيف تنتهي الفرق بنتائج غير محكومة وغير متوقعة. ^[3]

أربعة أسئلة تطرحها قبل شراء أتمتة سير العمل التالية

قبل التوقيع على أي شيء، على مسؤولي العمليات وتقنية المعلومات في الخليج التعامل مع هذه الأسئلة الأربعة بالترتيب:

1. أين تعيش بيئة تشغيل وكيلك حالياً؟ إن لم تستطع الإجابة، فأنت لا تملك واحدة — مما يعني أن المنصة التالية التي تعتمدها ستَرث هذا الدور تلقائياً، لا بتصميم مدروس. ارسمها أولاً.

2. من أي أنظمة يحتاج الوكيل القراءة والكتابة؟ ERP وCRM وموافقات المشتريات ومراسلات الموردين — لكل منها نمط تكامل قائم. بيئة تشغيل وكيل لا تستطيع الاندماج بسلاسة مع الـ ERP لديك ستتعثر أو ستُنشئ ظلاً للبيانات لا يحكمه أحد.

3. هل يضمّن بالفعل مورد الـ ERP أو التعاون لديك بيئة تشغيل وكيل؟ Microsoft وSAP وSalesforce كلها تتحرك في هذا الاتجاه. ^[4] إن كان مورّدك الحالي يبني هذه الطبقة، فإن شراء أداة أتمتة سير عمل مستقلة فوق ذلك قد ينتج عنه تداخل خلال ثمانية عشر شهراً.

4. ما نموذج الحوكمة لديك لإجراءات الوكيل؟ وكيل يمكنه الموافقة على أمر شراء، أو تسديد مدفوعة لمورّد، أو فتح تذكرة حادثة إنتاج — يحتاج إلى مسار تدقيق ومسار تصعيد واضح للحالات الاستثنائية. إن كانت إجابتك "سنحسم ذلك لاحقاً"، فاللاحق هو الآن. ^[3]

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

رأي تارسين: دقّق في طبقة التشغيل أولاً، واشترِ السطح اللامع ثانياً

Buzz لافت للاهتمام. البنية المفتوحة المصدر القابلة للاستضافة الذاتية مع الأحداث الموقّعة وهوية على مستوى الوكيل — هي فعلاً تصميم أكثر أمانةً من معظم أغلفة الذكاء الاصطناعي المؤسسية. إنها تُظهر مشكلة الحوكمة بدلاً من إخفائها خلف واجهة مستخدم أنيقة.

لكن فرق العمليات في الخليج التي نعمل معها ينبغي أن تقاوم الجذب نحو تقييم Buzz — أو أي منصة وكيل مُدمَج — كمقارنة ميزات. السؤال الصحيح ليس "هل لديها تكاملات وكيل أفضل من أداتنا الحالية؟" بل "أي منصة نريدها أن تمتلك بيئة تشغيل وكيلنا للسنوات الخمس القادمة، وهل منظومتنا الحالية تدعم ذلك بسلاسة؟"

موجة الوكيل المُدمَج تتسارع. المناورة المنصّاتية لـ Microsoft ^[4]، ورهان Buzz على البروتوكول المفتوح، والقائمة المتنامية من موردي سير العمل الذين يُضيفون طبقات تنفيذ قائمة على الوكلاء ^[3] — كلها تشير إلى النقطة ذاتها: في غضون عامين، لن تكون بيئة تشغيل الوكيل شراءً منفصلاً. ستُدمَج في أي منصة يعيش فيها فريقك أصلاً.

الفرق التي لم ترسم منظومة سير عملها الحالية قبل حدوث هذا التوحيد ستدفع مرتين — مرة مقابل الأدوات المستقلة للذكاء الاصطناعي التي اشترتها في 2024 و2025، ومرة أخرى مقابل الهجرة حين تُجعلها الطبقة المُدمَجة متقادمة. كتبنا عن هذا الفخ بالتحديد في معظم الشركات لا تحتاج مزيداً من الذكاء الاصطناعي.

النسخة الصريحة من نصيحتنا: أجرِ تدقيق سير العمل قبل أي عملية شراء قادمة. ليس لأننا بحاجة إلى العمل — نفرض الأجر ذاته سواء كانت الإجابة "اشترِ المنصة الجديدة" أو "أصلح السبعة عشر جدول بيانات أولاً". نعطي الإجابة ذاتها في كلتا الحالتين. اضرب منظومة سير عمل غير محكومة في بيئة تشغيل وكيل ذكي، وستحصل على فوضى فصيحة على نطاق واسع.

Buzz إشارة. الاستجابة الصحيحة للإشارة ليست التصرف الفوري عليها. بل فهم موقعك الحالي قبل أن يتحرك السوق من حولك.