Multi-Agent Architecture بدون فوضى: متى تكفي Agent واحدة ومتى تحتاج أكثر؟

Multi-agent Systems سهلة جدًا تخليها مبهرة في Diagram.

Planner تكلم Researcher. Researcher تفوض Browser Agent. Critic تراجع. Writer تكتب. Supervisor تقرر هل كلهم يجربوا مرة ثانية.

الDiagram شكلها Intelligent.

Production System ممكن ببساطة يكون عندها خمس أماكن للفشل بدل مكان واحد.

الشغل على Agentic Systems وMCP Tooling خلاني أميل لقاعدة أبسط:

ابدأ بـAgent واحدة. أضف Agent ثانية فقط لما تقدر تسمي الـBoundary اللي هي مسؤولة عنها.

الهدف مش أكبر عدد Agents. الهدف Workflow موثوقة ومفهومة وقابلة للتشغيل.

Agent واحدة مع Tools جيدة قوية أكثر مما نتخيل

Single Agent غالبًا تقدر تفهم Request، تعمل Retrieval، تبحث في Approved Sources، تستدعي Business APIs، تقرأ أوتكتب Structured Data، تسأل عن Missing Information وتنتج Result.

لو Actions دي تشترك في نفس Permissions وContext وSuccess Criteria، توزيعها على Agents متعددة قد يضيف Coordination بدون Capability جديدة.

Baseline مفيدة:

User/Task → Agent → Approved Tools → Validation → Result

ابنِ دي الأول.

لو اشتغلت، وفرت Distributed System بدون داعٍ.

Multi-Agent هي Distributed Systems Problem

أول ما Agents متعددة تتعاون، تظهر أسئلة Engineering معروفة: مين يملك State؟ مين يقدر يستخدم أنهي Tool؟ Delegation تحصل إزاي؟ لو Worker فشلت يحصل إيه؟ تمنع Duplicate Actions إزاي؟ مين Output بتاعته Authoritative؟ Trace كاملة للمهمة فين؟ وإمتى System تقف؟

دي مش مشاكل تتحل بـRole Prompts أفضل.

تحتاج Orchestration وContracts وState Management وObservability وFailure Handling.

علشان كده Multi-agent Architecture بالنسبة لي Systems-design Decision، مش Prompting Technique.

إمتى Agent واحدة تكفي؟

خليك في Agent واحدة لما Workflow لها Objective واضحة، نفس Trust Boundary، Tool Set معقولة، وContext منطقية تعيش مع بعض.

مثلًا Research Agent ممكن تبحث، تفتح Pages، تستخرج Evidence، تخزن Findings وتحضر Report بدون Agents منفصلة اسمها Searcher وReader وWriter.

دي ممكن تكون Steps، مش Agents.

Workflow Engine تقدر تعمل Orchestration بدون ما كل Function تتحول Autonomous Colleague.

Role مش تلقائيًا Agent

Research وValidation وSummarization وPublishing ممكن يكونوا Roles داخل Process.

يبقوا Agents منفصلة فقط لما Independent Reasoning Boundaries تضيف Value.

قبل New Agent اسأل:

هل دي ممكن تكون Tool أوFunction أوWorkflow Step أوDeterministic Service؟

لو آه، ابدأ هناك.

JSON Schema Validator مش محتاجة Identity وMemory وLLM.

Database Lookup Tool.

Scheduled Trigger Infrastructure.

Permission Check Application Logic.

ما تحولش Ordinary Software إلى Agents.

إمتى Agent ثانية تستحق مكانها؟

Permissions مختلفة

Research Agent عندها Read-only Web Access بينما Execution Agent تقدر تعدل CRM. الفصل يقلل Blast Radius للخطأ.

Context مختلفة

Coding Agent تحتاج Repository Context، وCommercial Agent تحتاج Customer/CRM Context. جمع كل حاجة في Context واحدة يضيف Noise وExposure.

Models أوCost Profiles مختلفة

Role تستخدم Small Local Model للExtraction، وأخرى Stronger Model للComplex Reasoning.

Evaluation مختلفة

Retrieval Agent تتقيم على Evidence Quality، وExecution Agent على صحة وAuthorization للAction.

Parallel Work

Independent Research Paths ممكن تشتغل في نفس الوقت. لكن Parallelism مش لازم يعني Personalities مختلفة؛ ممكن Workers بنفس Contract.

عرف Agents بالContracts مش بالشخصيات

“Senior Researcher” و“Brilliant Strategist” و“Skeptical Critic” Prompt Descriptions.

Production Architecture تحتاج تعريف أقوى.

لكل Agent حدد:

Input — Structured Information اللي تستقبلها.

Output — Schema اللي لازم ترجعها.

Tools — Capabilities المسموحة.

Permissions — Data/Actions المسموحة.

Budget — Steps/Calls/Resources.

Success Condition — Completed معناها إيه.

Failure Path — Retry أوFallback أوEscalation أوStop.

كده Agent تتحول من Character إلى Operational Component.

MCP مفيدة لأن Tools تحتاج Boundaries

سبب من أسباب شغلي مع MCP وبناء Tooling حولها إن Agent Capability ما ينفعش تتدفن داخل Giant Prompt أوIntegration واحدة.

MCP تعطي Standard Boundary للAgents لاكتشاف واستدعاء Tools.

Architecture:

Agent → MCP Client → MCP Servers/Plugins → Business Capabilities

Agent تختار Approved Capability، والIntegration نفسها تظل خارج Model.

الفصل ده أهم كل ما Tool Set تكبر.

Orchestra MCP والPlugin Model

في Ecosystem اللي ببنيها، Orchestra MCP تمثل الفكرة دي في Tool/Orchestration Layer: Capabilities تتعرض كPlugins بدل إعادة بناء Integrations لكل Agent.

القيمة هنا Reuse.

Browser Capability أوContent Operation أوResearch Operation أوBusiness Integration تقدر تتوفر عبر Controlled Interface وتستخدمها Agent Workflows مختلفة.

وده لا يعني إن كل Plugin تحتاج Agent خاصة بها.

بالعكس، Reusable Tools تقلل الحاجة لتقسيم Agents فقط لفصل Integrations.

خلي Orchestration خارج Free-form Conversation

Pattern هشة:

Agent A تكتب Prose لـAgent B → B تفسرها → C تفسر B → Action

كل Handoff تضيف Ambiguity.

استخدم Structured Contracts لما ممكن:

objective
inputs
evidence[]
constraints[]
status
next_action

Agents ما تحتاجش تعمل Reverse-engineering لنوايا بعض من Paragraphs لو Application تقدر تمرر Typed State.

Natural Language ممتازة لـUncertain Human Input، مش دائمًا أفضل Internal Protocol.

افصل Orchestration State عن Model Memory

Task عندها Operational State: Pending، Running، Waiting for Tool، Waiting for Approval، Failed، Completed.

دي مكانها Application/Workflow Layer.

Long-term Memory مشكلة ثانية: Retained Knowledge عبر Tasks وSessions.

ما تستخدمش Vector Store علشان تعرف Payment Workflow اتنفذت ولا لأ.

وما تستخدمش Chat History كJob Queue.

Operational State لازم تكون Deterministic وTransactional.

Shared Memory ممكن تعمل Accidental Coupling

كل Agent عندها Access لنفس Giant Memory Corpus تبدو سهلة، لكنها ممكن تعمل Cross-contamination.

الأفضل Namespaces وTenant Boundaries وRole-based Memory Access.

Agent تعمل Recall فقط لما Task وPermissions تسمح.

لو Agents محتاجة Shared Facts، اعرضها Intentional عبر Common Memory/Data Service بدل Hidden Prompt State.

وده سبب إني بخلي Long-term Memory زي CaBrain Service منفصلة بدل دفنها داخل Agent Persona.

فخ الـSupervisor Agent

لما Multi-agent Workflow تبقى Unreliable، رد فعل شائع إضافة Supervisor Agent.

وبعدين Supervisor تحتاج Critic، وبعدها حد يقيم Critic.

ممكن تتحول Recursion متنكرة في Architecture.

قبل Supervisor Model اسأل هل Decision ممكن تكون Deterministic.

مثل:

• Required Evidence ناقصة → ارجع Research.
• Schema Validation فشلت → Retry واحدة مع Error Details.
• Action تحتاج Approval → انتظر Human.
• Maximum Steps وصلت → Stop وEscalate.

Workflow Engine تفرض Rules دي بثبات أكثر من LLM ثانية.

استخدم Model-based Supervision فقط لما Supervisory Decision نفسها تحتاج Interpretation.

Human Approval Participant أساسي

بعض Multi-agent Diagrams تنسى أهم Actor: الإنسان.

في Consequential Actions ممكن Workflow تكون:

Research Agent → Evidence → Recommendation → Human Approval → Execution Tool

بدل:

Research Agent → Supervisor Agent → Execution Agent

Human Approval مش فشل Autonomy؛ هي Architecture Boundary لما Risk تحتاج Accountable Authorization.

Observability لازم تعدي Agent Boundaries

مع Agents متعددة تحتاج End-to-end Trace.

لكل Task عايز تعرف: أنهي Agent اشتغلت، أنهي Model/Version، Input/State، Tools، Evidence، Steps، Output، ليه Workflow انتقلت، هل Human تدخل، وإيه Final Outcome.

بدون Shared Trace أوCorrelation ID، Debugging تتحول Archaeology.

Log Decisions مش Hidden Reasoning

Observability مش محتاجة تخزين Private Chain-of-thought.

المطلوب Operational Information: Selected Action، Tool Arguments لما تكون آمنة، Validation Result، Evidence References، Error Category، Workflow Transition وOutcome.

ده كفاية لفهم Behavior بدون Hidden Internal Reasoning Text.

قيّم Components والWorkflow كاملة

Multi-agent System ممكن Agents كل واحدة قوية والنظام End-to-end يفشل.

اعمل مستويين Evaluation:

Component: Research جابت Evidence صح؟ Extraction رجعت Schema؟ Execution استخدمت Tools صح؟

Workflow: Task وصلت Outcome الصحيحة؟ Authorized؟ كام Retry؟ Evidence اتنقلت صح؟ System وقفت في الوقت الصح؟

المستوى الثاني هو اللي Business تشوفه.

Cost تكبر بسبب Coordination

Planner + Workers + Reviewer + Writer ممكن يحول User Request واحدة لعدة Inference Calls وTool Executions.

ده ممكن يكون مبرر لو Quality Improvement وTask Value يستحقوا.

لكن Multiplication لازم تكون Visible.

Track Cost per Successful Workflow، مش Agent Call.

لو Agent ثانية تزود Cost بدون Measurable Improvement، ما كسبتش مكانها.

Parallelism تحتاج Idempotency

لما Workers تعمل Concurrent Actions، Duplicate Execution Risk حقيقية.

لو Agents اكتشفت نفس Company أوعملت نفس CRM Record أوNotification، System تحتاج Unique Keys وIdempotency Tokens وTransactional Writes وExplicit Ownership للSide Effects.

Model مش مسؤولة تفتكر إن Agent ثانية غالبًا عملت الحاجة.

Tool Permissions تتبع Least Privilege

ما تديش كل Agent كل Tools.

Researcher Read Access. Content Agent ممكن تعمل Draft بدون Publish. Execution Agent API محددة. Human Authorization للActions المالية أوDestructive.

ده يقلل Security Risk وDecision Complexity، وTool Set أصغر ممكن تحسن Tool Selection.

صمم Failure Handling قبل Autonomy

لكل Agent/Handoff حدد Failure Classes.

Tool unavailable → Retry محدود أوFallback.

Missing information → اطلب Input.

Invalid structured output → Validation Feedback + Bounded Retry.

Permission denied → Stop، ما تلفش حول Security.

Low evidence quality → Escalate أوReturn incomplete.

Budget exhausted → Stop.

“سيب Agent تتصرف” مش Failure Policy.

Architecture عملية

في Business Systems كثيرة أفضل:

Task → Deterministic Orchestrator → Agent/Worker → MCP Tools → Validation → State Store → Next Deterministic Transition

Long-term Memory لو مطلوبة خلف Controlled Interface مستقلة.

Human Approval تدخل عند Explicit Risk Boundaries.

Agents إضافية فقط لما Separation تحسن Permissions أوContext أوParallelism أوEvaluation.

Architecture دي أقل مسرحية من Agents تتكلم مع بعض بلا نهاية.

وده بالضبط سبب إني أفضلها.

مثال: Opportunity Research

Naive Design ممكن تعمل Planner وWeb-search وCompany-analysis وBuyer-discovery وScoring وCritic وOutreach Agents.

Simpler Design تبدأ:

Discovery → Evidence Collection → Structured Extraction → Scoring → Human Review

بعض Stages تستخدم Models وبعضها Deterministic Services.

لو Research كبرت وتستفيد من Parallel Workers، أضفهم خلف نفس Evidence Contract.

لو Buyer Discovery تحتاج Data Permissions أوTools مختلفة، دي Boundary محتملة لـWorker منفصلة.

Architecture تتطور من Observed Constraints، مش Agent Org-chart Template.

مثال: Software Engineering

Coding Workflow ممكن تبدأ Coding Agent واحدة قوية مع Repository وTest وDocumentation Tools.

Reviewer منفصلة تصبح مفيدة لو عايز Independent Context أوEvaluation Step مختلفة.

Deployment Capability مش لازم تتحول Free-form Agent لمجرد إن Deployment Job منفصلة في الشركات.

ممكن تكون Deterministic Pipeline محكومة بالTests وApproval.

ارسم Software Boundaries، مش Human Org Charts.

5 أسئلة قبل إضافة Agent ثانية

1. إيه Capability اللي Current Agent مش قادرة توفرها بأمان أوكفاءة؟
2. هل New Role تحتاج Permissions أوContext مختلفة؟
3. هل Requirement ممكن تكون Tool أوDeterministic Step بدل Agent؟
4. Components هتبادل Typed State إزاي؟
5. هنقيس إزاي إن Extra Agent حسنت End-to-end Outcome؟

لو مفيش إجابات قوية، خليك في Agent واحدة.

إيه اللي أعمل Optimize له؟

Production Agent Architecture لازم تسهل إجابة:

مين يقدر يعمل إيه؟

إحنا في أنهي State؟

أنهي Evidence سببت Transition دي؟

لو Component فشلت يحصل إيه؟

Successful Task كلفت كام؟

أقدر أغير Model أوAgent بدون Rebuild للWorkflow كلها؟

الأسئلة دي أهم من Sophistication شكل Agent Hierarchy.

Multi-Agent لازم تكون Earned Complexity

Multi-agent Systems ممكن تكون قوية: تفصل Trust Boundaries، تعمل Parallel Research، تعزل Context وتسمح Specialized Workers تتطور بشكل مستقل.

لكن كل Agent تضيف Coordination وState وCost وEvaluation وFailure Modes.

ابدأ بأصغر Architecture تكمل Task.

استخدم Deterministic Orchestration لما Rules معروفة.

اعرض Capabilities عبر Tool Boundaries واضحة زي MCP.

وأضف Agents فقط لما تظهر Systems Boundary حقيقية.

Agent واحدة قوية مع Tools متصممة كويس غالبًا أفضل من لجنة Agents بOwnership غير واضحة.

بتصمم AI-agent Workflow ومحتار تحتاج Agent واحدة ولا عدة Agents؟

أبني Agentic Systems حول Explicit Roles وMCP Tools وPermissions وMemory وObservability وControlled Production Workflows، وأضيف Complexity فقط لما تعمل Measurable Value.

---

مرتبط: AI Agents، Agent Memory with CaBrain، AI Automation vs Traditional Automation، RAG vs Fine-Tuning vs AI Agents وMCP-based Agent Architecture.