Post by Mohamed Shawky

كتبت امبارح عن مشروع بيخلي جلسات Claude Code تتواصل مع بعض. حد في الكومنتات اقترح حل مختلف تماماً: git worktree. بدأ نقاش في الكومنتات عن مين الأفضل. والحقيقة إن السؤال نفسه غلط من الأساس. فيه معادلة بسيطة بتلخص كل مشكلة الـ multi-agent systems: Orchestration = Parallelism + Isolation + Communication + Coordination + Observability. لو ناقص عنصر واحد بس من الخمسة دول، اللي عندك مش نظام منسّق، عندك مجرد agents شغالين جنب بعض بالصدفة وخلاص. أداة زي git worktree بتوفرلك عنصرين بس من المعادلة دي: الـ Parallelism والـ Isolation. كل جلسة شغالة بالتوازي في نسخة معزولة تماماً من الكود، فمفيش تصادم مباشر على نفس الملف. ده أساسي، لكنه مش كفاية لوحده. مكتبة claude peers بتضيف عنصر بقي تالت جوهري: الـ Communication. الجلسات بقت تعرف بعض بتعمل إيه، حتى وهي معزولة، وده ضروري ومهم جداً. بس لسه ناقصين عنصرين عشان نوصل للـ Orchestration الحقيقي: الـ Coordination (مين بياخد القرار لو الجلستين عايزين يعدلوا نفس المنطق بطريقتين مختلفتين ويحصل Conflict في الـ Logic؟)، والـ Observability (حد شايف ومراقب كل الجلسات دي بتعمل إيه في نفس اللحظة، مش بعد ما تخلص ونفاجأ بالنتيجة؟). النمط اللي بيتكرر في كل الأبحاث الحديثة عن multi-agent architecture، بيمر عبر خمسة أنماط أساسية بس: Orchestrator-Worker، Swarm، Mesh، Hierarchical، و Pipeline. كل نمط بيوازن بشكل مختلف بين التحكم، المرونة، وتعقيد التشغيل. مفيش نمط "الأفضل" بشكل مطلق، فيه نمط أنسب لحجم ونوع البروجكت اللي قدامك. النقطة اللي بشوفها متكررة في كل مشروع agentic حقيقي: الفريق بيبدأ بالتركيز على عنصر واحد بس (عادة الـ Isolation، لأنه أسهل تقنياً)، وبيفتكر إنه حل المشكلة كلها. بعدين بيكتشف إن العزل لوحده بيمنع تصادم الملفات بس، مش تصادم القرارات المعمارية (Architectural Decisions). أنا شايف إن الدرس هنا أعمق من الأدوات المحددة لان الشغل بقى مختلف عن زمان ومبقاش عصر الـ agent الواحد خلاص اللي بيعمل كل حاجة لوحده. دلوقتي عصر الفرق من الـ agents بتشتغل مع بعض بمنطق واضح، زي أي فريق بشري شغال بنظام. اللي مش هيتعلم يبني بالمنطق ده، هيفضل شغال بعقلية قديمة في عصر جديد تماماً. في الأنظمة اللي بتبنيها، عندك الخمس عناصر دول مع بعض، ولا بتعتمد على عنصر واحد وبتفتكره كفاية؟