الشات بوت هو terminal متطور للإدخال. كيستقبل النص، كيستعمل model، وكيرجع النص. هادي هي المعمارية كاملة. للحالات البسيطة — FAQ، إعادة الصياغة، التصنيف الأولي ديال الـ tickets — كافي. ولكن باش تأتمت بروسيس حقيقي ديال البزنس، ماشي كافي معمارياً.
الـ Agentic Workflows مختلفين بزاف: كيقسمو الهدف ل tasks، كيختارو ويستعملو الـ tools، كيحتافظو بالـ state بين المراحل، وكيدورو حتى يكمل الخدمة — بلا ما يدخل الإنسان فكل خطوة. هاد المقال كيشرح النموذج التقني والتأثير ديالو على التكاليف.
الفرق المعماري : مقارنة عملية
خوذو workflow ديال الشراء فشركة توزيع مغربية : طلب شراء كيوصل، خاصو verification ديال الفورنيسور، مقارنة ديال الأثمنة على 3 قواعد بيانات، تحقق من القواعد ديال الميزانية، توليد PDF، وإرسال email للمسؤول.
التطبيق ديال الشات بوت
الشات بوت كيستقبل الطلب وكيرد : "سجلنا الطلب ديالك. واحد من الفريق غادي يعالجو." هادي ماشي أتمتة. هادي formulaire وحطو فيه model ديال اللغة.
التطبيق ديال Agentic Workflow
الـ agent كيستقبل نفس الطلب وكيدير :
- الخطوة 1 : استخراج البيانات بأداة entity recognition (item، الكمية، الاستعجال، cost center)
- الخطوة 2 : استدعاءات بالتوازي ل 3 APIs ديال الفورنيسور — بزوج، ماشي بالتتابع
- الخطوة 3 : دالة مقارنة الأسعار مع فحص الـ margin
- الخطوة 4 : تحقق من قواعد الميزانية فقاعدة بيانات ERP
- الخطوة 5 : توليد PDF ب template engine
- الخطوة 6 : إرسال email ب SMTP مع PDF
الوقت الكلي : من 4 ل 8 ثواني. صفر خطوة بشرية. Audit trail كامل.
graph موجه (acyclic ولا cyclic للمهام التكرارية) من خطوات تفكير LLM واستدعاءات tools، فين الـ LLM كيلعب دور planner و router — كيقرر شنو tool يستعمل، بأي بارامترات، وواش الخروج كيوافق شرط الإكمال. الحالة كتبقى محفوظة بين الخطوات ب checkpointer (Redis، PostgreSQL، ولا S3).
Multi-Agent Systems : فاش agent واحد ماكافيش
المعمارية ب agent واحد كتخدم مزيان للـ workflows الخطية اللي فيها أقل من ~10 خطوات. فوق هاد العدد، كتلقى جوج مشاكل : saturation ديال context window (الـ agent كينسى الخطوات الأولى) و single-point-of-failure (خطأ واحد كيوقف كلش).
الـ Multi-Agent Systems (MAS) كيحلو الجوج، بتقسيم الـ workflow على agents متخصصين كيتواصلو ب message bus مشترك ولا function calls مباشرة :
الطوبولوجيات ديال MAS
- Supervisor/Subagent : agent منسق كيوجه المهام ل subagents متخصصين (extraction، validation، dispatch). كل subagent عندو scope محدود ومضبوط. هاد الـ pattern هو اللي كنستعملو لمعظم الأتمتة ديال الشركات.
- Pipeline (تسلسلي) : الخروج ديال Agent A كيولي دخول ل Agent B. ساهل تديبوغو، parallelism محدود. مزيان لسلاسل معالجة الوثائق.
- Parallel (fan-out/fan-in) : منسق كيطلق N agents فنفس الوقت، كيجمع النتائج، كيركب. استعملو للبحث من مصادر متعددة، validation بالتوازي، ولا مهام التجميع.
LangGraph : الأحسن للـ workflows stateful المعقدة مع branching شرطي. الـ graph كيتطابق مع schema ديال البزنس. Stable فالإنتاج. استعملو ملي يكون عندك أكثر من 3 branches شرطية.
CrewAI : ergonomie أحسن للمطورين فالـ MAS المبنية على الأدوار. ميتافور ديال "crew" كتخدم مزيان مع agents بpersonas مختلفة (باحث، محلل، كاتب). أقل ملاءمة للـ workflows ديترمينيستية ديال الشركات.
Custom DAG : ملي تحتاج ضمانات execution ديترمينيستية، latency ضعيف، و observability كاملة. كيخذي وقت أكثر باش تبنيه ولكن كيعطيك التحكم الكامل. كنستعملوه للـ workflows المالية الحساسة.
مشكل الـ Guardrails : علاش معظم الـ agents كيفشلو فالإنتاج
السبب الأكثر شيوعاً ديال فشل الـ agentic systems فالإنتاج ماشي جودة الـ model — هو غياب guardrails ديترمينيستية حوالين الخروج probabilistic.
الـ LLM يقدر يقرر يستعمل tool غلط، يولد JSON payload خاسر، ولا يطلع خروج كيبان معقول ولكن كيفشل فالـ validation. بلا guardrails، هاد الشي كيمشي حتى لتحت.
الـ stack ديال 4 طبقات guardrails اللي كنحطو على كل agent فالإنتاج
- Schema validation : كل payload ديال tool call كيتم validation ديالو بـ JSON Schema قبل التنفيذ. Pydantic models فـ Python. إلا الـ LLM ولد payload غلط، الـ agent كيعاود مع رسالة الخطأ (3 محاولات بالكثر، ومن بعد escalation للإنسان).
- طبقة Business logic : rule engine كلاسيكي كيخدم بالتوازي مع LLM planner. كيمسك violations ديال القيود (الميزانية تجاوزت، فورنيسور غير مرخص، item ممنوع) قبل ما توصل للتنفيذ.
- Output classifier : classifier ONNX خفيف (50ms inference) كيعطي score لكل خروج ديال الـ agent على احتمال hallucination. إلا confidence < 0.85، كيتوجه لصف review بشري.
- Circuit breaker : إلا agent فشل 3 خطوات متتالية، وقف وعمل escalation. عمرك ما تخلي agent فاشل يدور بلا حدود.
أرقام ROI حقيقية من Deployments مغربية
3 deployments من 2025، بأسماء مخفية :
الحالة A — SaaS B2B، لوجستيك (الدار البيضاء)
- Workflow : معالجة devis ديال الفورنيسور و routing ديال الموافقة
- قبل : 3 FTEs، دورة متوسط 72 ساعة، نسبة الأخطاء 12%
- من بعد : 1 FTE للإشراف، دورة 6 دقائق، نسبة الأخطاء 0.3%
- التوفير الشهري : 18,000 درهم. تكلفة infrastructure : 3,200 درهم/الشهر.
الحالة B — منصة SaaS، تأمين (الرباط)
- Workflow : معالجة وثائق المطالبات و pre-screening ديال الغش
- قبل : 8 ساعات review بشري لكل مطالبة، السعة 340 مطالبة/الشهر
- من بعد : pre-screen مؤتمت ف 12 دقيقة، السعة 2,400 مطالبة/الشهر (7× throughput)
- نسبة false positives ف كشف الغش أقل بكثير من المراجعة اليدوية
الحالة C — أداة داخلية، صناعة (طنجة)
- Workflow : توليد تقارير quality control من البيانات ديال sensors
- قبل : 2 ساعة/shift باش يديرو تقرير يدوي
- من بعد : مؤتمت كلياً ف 40 ثانية. المهندسين كيراجعو التقرير، ماشي كيديروه.
- الإنتاجية السنوية اللي تسترجعت : 2,920 ساعة هندسة.
منين تبدا : audit ديال الـ workflows
قبل ما تختار framework ولا تحدد الـ infrastructure، دير audit ديال الـ workflows. دوز على المنتج ديالك وعلّم كل خطوة اللي كيخصها الإنسان : يقرا حاجة، يقارن خيارات، يطبق قاعدة، ويطلع خروج. هادي هي اللائحة ديال الـ agents المرشحين.
من بعد، حدد الأولويات على محورين : التكرار (شحال من مرة فالنهار) × التكلفة لكل execution (الوقت × الأجر بالساعة). الـ workflows اللي فالربع لفوق ليمين — تكرار عالي، تكلفة عالية — هما أول الأهداف ديال النشر.
الـ agent ماكيعوضش الحكم. كيعوض الـ 80% ديال الخدمة اللي ماخاصهاش حكم — البحث، formatting، routing، المقارنة — باش الإنسان يركز على الـ 20% اللي خاصها.