توقّفت Notion عن كونها أداةً وباتت تطمح إلى أن تكون بنيةً تحتية
ثمة لحظةٌ في حياة أي منصة إنتاجية تتوقف فيها عن أن يكفيها التفوق في أداء شيء واحد فحسب. وقد بلغت Notion تلك اللحظة. فالشركة — التي عُرفت طوال سنوات باعتبارها المكانَ الذي تحتفظ فيه الفرق بملاحظاتها وقواعد معارفها وقواعد بياناتها — أعلنت للتو عن إعادة هيكلةٍ عميقة لبنيتها المعمارية: مجموعةٌ من القدرات التي تحوّل، مجتمعةً، بيئة العمل إلى فضاء تستطيع فيه وكلاء الذكاء الاصطناعي أن تعمل وتتلقى التعليمات وتنفّذ الأكواد البرمجية وتزامن البيانات الخارجية في تدفقٍ مستمر لا ينقطع.
جاء الإعلان في الثالث عشر من مايو 2026، خلال حدثٍ بثّته الشركة على الهواء مباشرةً. وقد لخّصه إيفان زاو، المؤسس المشارك والرئيس التنفيذي للشركة، في عبارةٍ تستحق التأمل: "Any data, any tool, any agent". هذه ليست شعار تسويق عابر، بل هي تصريحٌ بالموقع التنافسي. تُعلن Notion من خلاله أن سقفها لم يعد سقفَ تطبيق إنتاجية، بل غدا طبقةَ تنسيق بين الأنظمة والبيانات والوكلاء.
ولكي يتضح لماذا يتجاوز هذا الأمر أهميةَ العنوان البارز، لا بد من تتبّع المشكلة المحددة التي كانوا يسعون إلى حلّها.
المليون وكيل الذي لم يستطع الخروج إلى العمل
في فبراير 2026، كانت Notion قد أطلقت وكلاءها المخصّصين: مساعدون قابلون للتهيئة، قادرون على الإجابة عن الأسئلة المتكررة وتجميع تحديثات الحالة وأتمتة مهام سير العمل المتكررة. وكان مستوى التبني لافتاً للنظر؛ إذ أنشأ العملاء في غضون أشهرٍ قليلة ما يزيد على مليون وكيل. هذا الرقم ذو دلالة، لأنه يشير إلى أن الطلب على الأتمتة داخل بيئة العمل لم يكن كامناً في انتظار الإيقاظ، بل كان نشطاً وفاعلاً. فقد كان المستخدمون يرغبون فعلاً في تفويض أعمالهم لهذه الأنظمة.
بيد أن هؤلاء الوكلاء كانوا يعانون من قيدٍ هيكلي يُضيّق نطاق فائدتهم العملية: عدم قدرتهم على الاتصال بمصادر البيانات الخارجية أو تنفيذ منطق برمجي مخصّص. فالوكيل في Notion لم يكن قادراً على قراءة حالة تذكرة في Zendesk، ولا على تحديث نفسه ببيانات Salesforce، ولا على إطلاق إجراءٍ عند تغيّر شيءٍ ما في نظامٍ آخر. وللتعامل مع هذا القصور، لجأت الفرق إلى منصات أتمتة تابعة لجهات خارجية، أو كتبت نصوصاً برمجية خاصة بها تُشغّلها على بنيتها التحتية الذاتية. بعبارة أخرى: كانت Notion نقطةَ وصول المعلومات، لا نقطة التحكم في العملية.
وتعالج منصة المطورين الجديدة هذه المشكلة على ثلاثة محاور.
المحور الأول هو Workers (العمّال البرمجيون): بيئةٌ سحابية تستطيع فيها الفرق نشر أكوادها الخاصة في بيئةٍ معزولة، دون الحاجة إلى بنية تحتية خارجية. يتيح Workers مزامنة البيانات من أي قاعدة بيانات تمتلك واجهة برمجية (كـ Salesforce وZendesk وPostgres وسواها)، وبناء أدوات تعمل بمنطق مخصّص، وتفعيل مهام سير العمل عبر webhooks. والأهمية هنا لا تكمن في كون Notion تسمح بتشغيل الكود — إذ كانت منصاتٌ أخرى تفعل ذلك — بل في كونها تفعله داخل بيئة العمل ذاتها، بنفس ضوابط الأذونات وبنفس نموذج الاعتمادات الذي يستخدمه الوكلاء. وبهذا ينخفض احتكاك دمج الأنظمة الخارجية بصورة جوهرية.
المحور الثاني هو مزامنة قواعد البيانات الخارجية. حتى وقتٍ قريب، كان استيراد البيانات من نظام CRM أو منصة دعم إلى Notion عمليةً يدوية، أو كانت تعتمد على موصّلات من جهات خارجية. مع البنية المعمارية الجديدة، يمكن أن تكون هذه المزامنة مستمرة وثنائية الاتجاه. ووصف زاو ذلك بأنه يتيح استخدام "قاعدة بيانات Notion كلوحةٍ لتعزيز مهام سير عمل وكلائك معاً". وما يصفه في الحقيقة هو تحوّلٌ في دور البيانات داخل Notion: من أرشيفٍ ساكن إلى مصدرٍ فاعل لقرارات آلية.
المحور الثالث هو واجهة برمجية لوكلاء خارجيين. الفرق التي تستخدم بالفعل وكلاء خاصة بها — سواء كانت مبنية داخلياً أو مصدرها جهات خارجية — تستطيع الآن ربطها بـ Notion. وعند الإطلاق، كان أربعة وكلاء خارجيين متوافقين: Claude Code وCursor وCodex وDecagon. والخطة تقضي بتوسيع هذه القائمة. وهذا مثيرٌ للاهتمام لأنه يعكس المنطق المعتاد: بدلاً من أن تبني Notion كل قدرة بنفسها، تفتح الباب لوكلاء متخصصين كي يعملوا داخل بيئة عملها.
الاحتكاك الذي كان يُكبّل المنصة
اعترف الرئيس التنفيذي لـ Notion بشيءٍ نادراً ما تقوله الشركات عن نفسها بصوتٍ عالٍ: "تاريخياً، لم تكن Notion المنصة الأكثر توجهاً نحو المطورين". هذا الاعتراف ليس بسيطاً. فطوال سنوات، كان أحد أبرز مواطن الاحتكاك الموثّقة بين المستخدمين التقنيين في Notion هو بالضبط ذلك: كانت المنصة قوية بوصفها واجهة، لكنها مقاوِمة بوصفها نظاماً قابلاً للبرمجة. وكانت فرق الهندسة، التي كان بإمكانها بناء مهام سير عمل معقدة فوق Notion، تُفضّل في أغلب الأحيان أدوات أكثر انفتاحاً وإن كانت أقل صقلاً بصرياً.
وكان لهذه الفجوة ثمنٌ حقيقي. العملاء الذين كانوا بحاجة إلى أتمتة متقدمة كانوا ينتهون بالدفع مقابل طبقات إضافية من البنية التحتية — كـ Zapier وMake وn8n ونصوص برمجية على AWS Lambda — لربط Notion بسائر مكدّسهم التقني. وكان ذلك يُشتّت بيئة العمل، ويُدخل نقاط فشلٍ إضافية، وفوق كل ذلك، يُبقي Notion خارج دورة القرار الآلية. فالبيانات كانت تعيش في Notion، لكن الفعل كان يقع في مكانٍ آخر.
تسعى المنصة الجديدة إلى ردم تلك الفجوة. فمع Workers التي تعمل داخل Notion، تنتقل بيئة التنفيذ إلى الداخل. لم يعد الكود يعيش في دالة Lambda منفصلة: إنه يعيش في السياق ذاته الذي تتواجد فيه البيانات والوكلاء والمستخدمون. ولهذا التجاور عواقب ملموسة: يُقلّص زمن استجابة الدمج، ويُبسّط نموذج الأذونات، ويُركّز من منظور العميل ما كان في السابق عقوداً متعددة مع موردين مختلفين في فاتورة واحدة.
أما كون Workers مجانيةً حتى أغسطس 2026، فهو قرارٌ تكتيكي مألوف في تبني المنصات: تخفيض تكلفة التجريب لتسريع توليد حالات الاستخدام الحقيقية قبل التحوّل إلى جني الأرباح. فإذا بنت الفرق مهام سير عمل ذات أهمية فوق Workers خلال تلك الفترة، ارتفعت تكلفة نقلها لاحقاً — إلى أي بيئة أخرى — بما يكفي لتثبيت الحسابات داخل Notion.
متى تتحوّل التطبيقات إلى طبقة تنسيق
التمييز بين تطبيق ومنصة بنية تحتية للتنسيق ليس تمييزاً دلالياً. فالتطبيق يحل مشكلةً لمن يفتحه في تلك اللحظة. أما منصة التنسيق فتحل المشكلات حتى حين لا ينظر إليها أحد: تُزامن وتُنفّذ وتُربط وتُحدّث بصورة مستقلة. والقيمة لم تعد في الواجهة، بل في العمليات التي تدور في الخلفية.
تحاول Notion إحداث ذلك القفزة. والسؤال الملموس الذي يستحق طرحه هو: كم من العمل الذي تنسّقه اليوم منصاتٌ كـ Zapier وMake أو حتى خدمات الدمج الأكثر تطوراً يمكن أن تستوعبه البنية المعمارية الجديدة لـ Notion، وبأي ثمن؟
ثمة مؤشراتٌ تدعم رسوخ هذا الرهان. فنموذج الوكلاء أظهر بالفعل زخماً قبل أن توجد هذه القدرات. إن المليون وكيل الذي أُنشئ في غضون أشهرٍ قليلة ليس مقياساً للمباهاة: بل يدل على أن الفرق كانت على استعداد لتهيئة أتمتة داخل Notion حتى لو كانت محدودة. وهذا يوحي بأن الاستعداد للعمل انطلاقاً من Notion قائمٌ أصلاً. وما كان ينقص هو البنية المعمارية لفعل ذلك بصورة كاملة.
غير أن تبني منصات التنسيق يسير وفق ديناميكية خاصة: قيمتها لا تتفعّل لحظة الإطلاق، بل حين يتجاوز حجم الدمجات النشطة عتبةً حرجة. قاعدةُ بيانات مُزامَنة مع Salesforce أمرٌ مفيد. أما قاعدة بياناتٍ مُزامَنة مع Salesforce وZendesk وPostgres وأربعة مصادر داخلية إضافية، مع وكلاء يقرؤون تلك البيانات ويتخذون القرارات، وعمّال برمجيون ينفّذون منطقاً مخصصاً على النتائج، فذلك هو البنية التحتية. والفرق بين هذين الحالين ليس تكنولوجياً: بل هو فرقٌ في التبني المتراكم.
إن توسيع فهرس الوكلاء الخارجيين سيكون على الأرجح المؤشر الأكثر كشفاً لنجاح هذه الاستراتيجية خلال الأشهر المقبلة. أربعة شركاء عند الإطلاق هو بدايةٌ متواضعة. وإن لم يرتفع هذا الرقم ارتفاعاً ملحوظاً خلال ستة أشهر، فستظل رواية "مركز الوكلاء" إعلانَ نية قبل أن تكون واقعاً تشغيلياً.
ما كان يشتريه المستخدمون وما باتوا يستطيعون شراءه الآن
ثمة فارقٌ واضح بين ما كان يشتريه مستخدمو Notion حتى الآن وما تقترحه عليهم المنصة الجديدة. في السابق، كانوا يشترون فضاءً مشتركاً يُركّزون فيه الوثائق وقواعد البيانات ومهام الفريق. وكانت قيمته تنبع من قدرته على الحد من تشتّت المعلومات: بدلاً من البحث في عشر أدوات، كان كل شيء في مكانٍ واحد.
أما ما تقترحه المنصة الجديدة فهو مختلف. المستخدمون لا يُركّزون المعلومات فحسب، بل يستطيعون "التعاقد" على أن تُحدَّث تلك المعلومات بنفسها تلقائياً، وأن يتصرف الوكلاء بناءً عليها دون تدخّل بشري، وأن يعمل الكود الأعمالي الذي يمنح تلك التصرفات منطقها في البيئة ذاتها التي تعيش فيها البيانات. والانتقال من مجرد تركيز المعلومات إلى تنسيق العمليات هو، من حيث القيمة المُدركة، قفزةٌ إلى فئةٍ مختلفة كلياً.
وإن نجحت Notion في جعل تلك القفزة سلسةً بما يكفي لكي تتبناها الفرق غير التقنية — وإشارة زاو الصريحة إلى أنك "لست مضطراً إلى كتابة الكود، إذ يستطيع وكيلك البرمجي أن يفعل ذلك نيابةً عنك" تدل على أن هذه هي الرهان — فستكون قد حققت ما تعجز عنه منصات إنتاجية قليلة: ألا يكتفي المستخدم بالاستخدام الأكثر للأداة، بل أن يُصبح التخلي عنها أكثر تكلفةً بالنسبة له. وهذا ليس ولاءً مبنياً على جمال التصميم، بل هو ولاءٌ مبنيٌّ على الاعتماد الوظيفي. وفي سوق البرمجيات المؤسسية، هذا هو الشكل الأكثر ديمومةً للاحتفاظ بالعملاء.
