لن نُشارك كل التفاصيل هنا — بعضها ملكية فكرية وبعضها استراتيجي. لكن ما نُشاركه حقيقي ويعكس قراراتنا المعمارية الفعلية.

بناء نظام يُجيب على الأسئلة = سهل.
بناء نظام يُنفّذ مهام بشكل موثوق في بيئة عشوائية = صعب جداً.

تحديات حقيقية واجهناها:

• الرسالة تصل مرتين (idempotency)
• واتساب ينقطع وسط معالجة طلب
• سلة تتأخر في الرد
• LLM يُرجع خرجاً غير متوقع
• موافقة المالك تأتي بعد ساعات (long-running workflows)

1. نهج ReAct للـ Agents

اخترنا ReAct (Reason + Act) بدلاً من chains أو pipelines ثابتة.

لماذا: ReAct أقل هشاشة. عندما تتغير البيانات أو يكون الموقف غير متوقع، الـ Agent يُعيد التفكير بدلاً من المتابعة العمياء على مسار محدد.

التحدي: ReAct بطيء إذا أُسيء استخدامه. حللنا هذا بـ caching ذكي وسقوف واضحة للتفكير.

2. طبقات متعددة للـ LLM

وصول لا يستخدم نموذجاً واحداً لكل شيء.

• للردود الفورية (< 500ms): نموذج سريع مُحسَّن للسرعة
• للتحليل والتقارير: نموذج أكثر عمقاً وقدرة
• للمهام الحرجة: نموذج مع higher temperature validation

المحرك: LiteLLM Router يُوجّه كل طلب للنموذج المناسب. إذا فشل النموذج الأساسي، يتحول تلقائياً للـ fallback.

3. نظام الذاكرة المتعدد الطبقات

أربع طبقات ذاكرة بمتاجر مختلفة:

• Session: في الذاكرة (Redis) — سريع ومؤقت
• Tasks: مُثبَّت (MongoDB) مع TTL
• Decisions: مُفهرَس وقابل للاستعلام
• Store Knowledge: vector + structured مع real-time sync

التحدي: الحفاظ على consistency بين الطبقات. القرار: eventual consistency مقبول في معظم الحالات، strict consistency فقط في المهام الحرجة.

4. Policy Engine لتصنيف المخاطر

كل إجراء يمر بمحرك تصنيف قبل التنفيذ:

class RiskLevel:
    LOW    = "auto_execute"    # ينفّذ تلقائياً
    MEDIUM = "execute_notify"  # ينفّذ ويُخبر
    HIGH   = "approval_needed" # ينتظر موافقة
    CRITICAL = "blocked"       # ممنوع تماماً

التصنيف يعتمد على: نوع الإجراء + المبلغ المالي + التأثير على البيانات + حجم التأثير.

5. نظام Workflow للمهام طويلة الأمد

بعض المهام تستغرق ساعات أو أياماً (انتظار موافقة، متابعة شحن). هذه لا تُعالَج في طلب HTTP واحد.

نستخدم نظام workflow orchestration يضمن:

• تنفيذ كل خطوة مرة واحدة بالضبط (exactly-once semantics)
• استمرار العمل بعد أي فشل أو انقطاع
• تتبع حالة كل workflow في أي وقت
• إمكانية الإلغاء والتعديل

6. معالجة تعدد المستأجرين (Multi-tenancy)

كل متجر في بيئة معزولة:

• قاعدة بيانات منفصلة (logical isolation)
• Redis namespace منفصل
• rate limiting محدد لكل متجر
• لا تسرب بيانات بين المستأجرين

Frontend:     Next.js 14 (App Router)
Backend:      Node.js/Express
Orchestrator: Python
Database:     MongoDB (primary) + Redis (cache) + PostgreSQL (auth)
WhatsApp:     Evolution API (WhatsApp Business API bridge)
AI Routing:   LiteLLM
Vector Store: ChromaDB
Files:        MinIO (S3-compatible)
Auth:         Keycloak
Deployment:   Docker on Hetzner (Germany)
CI/CD:        GitHub Actions → Docker Hub

بعض المكوّنات الاستراتيجية ستبقى خاصة. نُشارك الـ "ماذا" — الـ "كيف" التفصيلي في بعض الأجزاء هو ما يُشكّل الميزة التنافسية.

نبحث عن مهندسين يفهمون:

• Distributed systems وتحديات الموثوقية
• LLM integration وأنماط الـ Agentic AI
• Arabic NLP وتحديات اللغة
• Real-time systems وبيئات الإنتاج

نحن فريق صغير يبني شيئاً كبيراً. إذا كنت من هؤلاء، تحدث معنا.