وكيل ذكاء اصطناعي أم Chatbot؟ أيهما تحتاج شركتك فعلًا؟

عميل بعت رسالة على موقعك أو WhatsApp وعايز يعرف هل يقدر يغيّر طلبه.

نظام يرد عليه بسياسة التعديل الخاصة بالشركة.

ونظام تاني يحدد العميل، يجيب الطلب، يتأكد إن التعديل مسموح، يحدّث النظام، يسجل اللي حصل، ولو الحالة خارج صلاحياته يطلب موافقة موظف.

الاتنين ممكن يظهروا للعميل في نفس شكل الـchat تقريبًا، لكن من ناحية الهندسة والتشغيل هما نظامان مختلفان جدًا.

وده فرق مهم لأن شركات كثيرة تطلب اليوم AI Agent بينما احتياجها الحقيقي Chatbot جيد، وشركات أخرى تشتري chatbot بينما الـworkflow نفسه يحتاج نظامًا يستطيع تنفيذ إجراءات فعلية.

السؤال الصحيح ليس: أي مصطلح أحدث؟

السؤال هو:

ماذا يجب أن يفعل النظام بعد أن يفهم طلب المستخدم؟

الـChatbot وظيفته الأساسية التواصل

في أبسط صورة، الـchatbot يستقبل رسالة ويرجع ردًا.

البوت التقليدي قد يعمل بقواعد ثابتة. أما AI Chatbot فيستطيع فهم اللغة الطبيعية وإنتاج ردود أكثر مرونة. ولو أضفت retrieval، يمكنه الإجابة من معرفة الشركة المعتمدة بدل الاعتماد فقط على المعرفة العامة للنموذج.

Chatbot مفيد للشركات يمكنه مثلًا:

• الإجابة عن الأسئلة المتكررة.
• شرح المنتجات والخدمات.
• البحث داخل قاعدة المعرفة.
• تلخيص المعلومات.
• جمع بيانات أولية من العميل.
• مساعدة الموظفين في الوصول للمستندات الداخلية.
• توجيه المحادثة للفريق المناسب.

وبالنسبة لشركات كثيرة، ده كفاية جدًا.

لو المشكلة هي مساعدة الناس في الوصول للمعلومة وفهمها، فلا تضيف تعقيد الـAgents لمجرد أن المصطلح منتشر.

الـAI Agent يستطيع استخدام أدوات وتنفيذ خطوات

الـAgent يتجاوز مجرد كتابة الإجابة.

يمكنه — حسب الصلاحيات التي تعطيها له — تحديد الإجراء المطلوب، اختيار أداة، جلب معلومات، تنفيذ خطوة، فحص النتيجة، ثم الاستمرار حتى يصل إلى حالة محددة.

تخيل أن العميل يقول:

"ممكن أنقل الحجز من الثلاثاء للخميس بعد الظهر؟"

Chatbot قد يشرح سياسة تعديل الحجز.

أما agentic system فقد يستطيع:

1. تحديد العميل.
2. جلب الحجز الحالي.
3. فحص المواعيد المتاحة يوم الخميس.
4. تطبيق قواعد الشركة.
5. عرض الاختيارات الصحيحة على العميل.
6. تعديل الحجز من خلال API.
7. تسجيل التغيير.
8. إرسال التأكيد.

الفرق المهم هنا ليس أن الـAgent يكتب ردًا أذكى.

الفرق أنه يستطيع الدخول في الـbusiness workflow نفسه.

الـChat مجرد Interface وليس Architecture

جزء كبير من الخلط سببه أن النظامين قد يبدوان متشابهين جدًا للمستخدم.

نافذة chat واحدة يمكن أن يكون خلفها:

• Scripted bot.
• LLM.
• LLM + RAG.
• Workflow automation.
• AI Agent يستخدم tools.
• Multi-agent system.

لذلك لا تختار الـarchitecture بناءً على شكل الواجهة.

ابدأ بما يجب أن يحدث خلفها.

أين يأتي RAG؟

لنفترض أن العميل سأل:

"ما سياسة استرجاع المنتج ده؟"

لا يفترض أن يعرف model عام سياسة شركتك الحالية.

RAG يسمح للنظام بالبحث داخل مصادر معتمدة مثل المستندات، بيانات المنتجات، السياسات أو المعرفة الداخلية، ثم تمرير المعلومات المناسبة للنموذج.

وده مفيد للـChatbots والـAgents معًا.

Chatbot قد يستخدم RAG حتى يعطي إجابة دقيقة.

Agent قد يستخدم retrieval كخطوة قبل أن يقرر الإجراء المسموح به.

إذًا RAG لا يحول chatbot إلى agent. هو يحل مشكلة مختلفة: إحضار المعرفة المناسبة للمهمة الحالية.

والذاكرة مشكلة مختلفة أيضًا

تخيل أن العميل قال:

"أنا كلمتكم في الموضوع ده الأسبوع اللي فات."

البحث عن سياسة الاسترجاع لن يحل المشكلة.

النظام قد يحتاج تاريخ المحادثات، القرارات السابقة، سياق العميل أو long-term memory.

الفرق بين retrieval والذاكرة أصبح مهمًا جدًا بالنسبة لي أثناء العمل على CaBrain، حيث أبني طبقة long-term memory للـAI agents بدل اعتبار vector similarity وحدها هي الذاكرة.

Agent متقدم قد يحتاج أن يعرف:

• ما الحقائق الحالية عن الشركة؟
• ماذا حدث سابقًا؟
• ماذا تغير مؤخرًا؟
• ما العلاقات بين الأشخاص والشركات والبيانات؟
• أي مصدر هو المصدر الموثوق؟

المشكلات مرتبطة ببعضها، لكنها ليست نفس المشكلة.

القفزة الحقيقية في التعقيد تبدأ مع الصلاحيات

إعطاء النظام معلومات شيء.

وإعطاؤه القدرة على التنفيذ شيء آخر تمامًا.

Chatbot يعطي إجابة سيئة قد يسبب تجربة سيئة للعميل.

لكن Agent يستطيع تنفيذ refund أو تغيير حجز أو إرسال رسالة أو تعديل record أو تشغيل إجراء على infrastructure يمكن أن يسبب مشكلة أكبر بكثير لو لم تكن الـcontrols مصممة جيدًا.

بمجرد أن يستطيع AI تنفيذ Actions، أبدأ في التفكير في:

• Authentication.
• Authorization.
• Tool permissions.
• Validation.
• Audit logs.
• Rate limits.
• Idempotency.
• Human approval.
• Reversibility.
• Failure recovery.
• Monitoring.

وده أحد الأسباب التي تجعل production AI Agent أكثر بكثير من مجرد LLM مع function calls.

وجود الإنسان في الحلقة ليس نقصًا

الـAutonomy ليست اختيارًا بين صفر و100%.

Architecture ممتازة في حالات كثيرة تكون:

Understand → Prepare → Human Approval → Execute → Record

مثلًا Agent يجهز قرار refund مع المعلومات والأدلة، لكن موظف يعتمد العملية المالية.

أو يجهز sales follow-up، لكن لا يرسله إلا بعد الموافقة.

ومع الاختبار وتحسن الثقة والقواعد، يمكن أتمتة الإجراءات منخفضة المخاطر تدريجيًا.

بهذا تحصل الشركة على قيمة من AI بدون إعطاء نظام احتمالي صلاحيات غير محدودة من أول يوم.

ماذا عن WhatsApp AI؟

الفرق ده مهم جدًا عند التفكير في أتمتة WhatsApp.

WhatsApp AI Chatbot يمكن أن يجيب:

"مواعيد العمل إيه؟"

أو:

"أي باقة فيها الخاصية دي؟"

أما AI Agent متصل بـWhatsApp فقد ينفذ workflow أكبر:

يفهم الطلب → يجد العميل → يجلب الطلب → يحدد الإجراءات المتاحة → ينفذ الإجراء المسموح → يحدث CRM → يرد.

WhatsApp يظل مجرد channel.

الذكاء والـworkflow الحقيقي موجودان خلفه.

متى تختار Chatbot؟

Chatbot غالبًا نقطة بداية ممتازة عندما تكون الوظيفة الأساسية:

• الإجابة عن الأسئلة.
• البحث داخل المعرفة.
• شرح المنتجات.
• البحث الداخلي للموظفين.
• جمع معلومات.
• qualification بسيط.
• توجيه المستخدم.

وهو جذاب خصوصًا عندما تريد نظامًا محدود النطاق ومخاطره التشغيلية أقل.

ومتى تفكر في AI Agent؟

Agent يصبح أكثر منطقية عندما يحتاج النظام إلى:

• استخدام أكثر من tool.
• تنفيذ مهام متعددة الخطوات.
• البحث ومقارنة المعلومات.
• التعامل مع أنظمة الشركة.
• اتخاذ قرارات محدودة حول الخطوة التالية.
• الاحتفاظ بحالة المهمة.
• تنفيذ actions.
• العمل بشكل asynchronous.

لكن كونك تستطيع استخدام Agent لا يعني أنك يجب أن تستخدمه.

لو deterministic workflow يستطيع حل المشكلة بثبات، غالبًا أفضّل الـarchitecture الأبسط.

أحيانًا أفضل حل هو الاثنين معًا

يمكن أن يكون Chatbot هو الواجهة أمام العميل، بينما تعمل workflows أو agents محدودة الصلاحيات خلفه.

مثلًا:

Customer → Chatbot → Intent → Workflow/Agent → Business Systems → Result → Chatbot

العميل يحصل على محادثة بسيطة.

والشركة تحصل على نظام منظم خلفها.

وده غالبًا أفضل من محاولة تحويل التطبيق كله إلى Agent واحد autonomous.

Framework عملي للاختيار

قبل الاختيار بين Chatbot وAgent، جاوب على الأسئلة التالية:

1. هل النظام يحتاج فقط أن يجيب أم يجب أن ينفذ؟

لو الإجابة فقط، ابدأ بـChatbot.

2. هل يحتاج معرفة الشركة؟

فكر في retrieval / RAG.

3. هل يحتاج تذكر تعاملات سابقة؟

صمم state أو memory صريحة بدل افتراض أن النموذج سيتذكر.

4. هل يحتاج أنظمة خارجية؟

حدد APIs والـtools المطلوبة فعلًا.

5. هل يمكن جعل الـworkflow deterministic؟

لو نعم، automation تقليدية قد تكون core architecture أفضل.

6. ماذا يحدث لو أخطأ؟

الإجابة تحدد الصلاحيات والـvalidation والـhuman approval.

7. هل تستطيع قياس النجاح؟

حدد metrics مثل زمن الحل، نسبة الأتمتة، escalation rate، accuracy، تكلفة المهمة أو الساعات التي تم توفيرها.

لا تشترِ المصطلح. صمم الـworkflow.

السوق سيستمر في إنتاج أسماء جديدة لأنظمة AI.

مشكلة شركتك لا يهمها اسم الـarchitecture.

لو Chatbot يحلها، ابنِ Chatbot.

لو workflow ثابت يحلها، ابنِ automation.

لو النظام يحتاج فعلًا التفكير عبر عدة tools وتنفيذ عمل متعدد الخطوات، فكر في Agent.

ولو العملية تحتاج الثلاثة، اجمعهم بشكل مقصود.

الهدف ليس أكبر قدر ممكن من الـautonomy.

الهدف هو قيمة حقيقية للشركة بأقل تعقيد ضروري.

مش عارف شركتك تحتاج Chatbot ولا AI Agent؟

اكتب الـworkflow الحالي من لحظة وصول طلب العميل أو الموظف حتى اكتمال المهمة.

من العملية نفسها يصبح من الأسهل تحديد ما يجب أن يكون deterministic، وأين AI يضيف قيمة، وأين يجب أن تبقى موافقة الإنسان.

ناقش مشروع الذكاء الاصطناعي مع فادى مندي.

ابدأ بالـworkflow — وليس باسم التقنية.

---

مقالات وخدمات مرتبطة: أتمتة الأعمال بالذكاء الاصطناعي، AI Agents للشركات، AI Chatbots، دمج الذكاء الاصطناعي، والذكاء الاصطناعي للشركات.