macro-agent 0.2.5 → 0.2.6

package/mvp_docs/dynamic-meta-orchestration.md

@@ -1,116 +0,0 @@
-Response to paper: *Towards a Science of Scaling Agent Systems* (Kim et al., 2025) and its implications for your Dynamic Meta-Orchestration architecture.
-[arxiv](https://arxiv.org/pdf/2512.08296)
------
-
-# Design Implications for Dynamic Meta-Orchestration Systems
-
-**Based on:** *Towards a Science of Scaling Agent Systems* (Kim et al., Dec 2025)
-**Context:** Architectural validation for adaptive multi-agent routing systems.
-
-## 1\. Executive Summary
-
-The prevailing assumption that multi-agent systems (MAS) universally outperform single-agent baselines is empirically false. Performance is strictly governed by the alignment between **task topology** and **agent architecture**.
-
-A "Dynamic Meta-Orchestrator" is viable only if it functions as a **predictive router** (assigning distinct topologies per task) rather than a **static manager** (forcing a hybrid topology on all tasks). Misalignment, particularly in sequential reasoning tasks, leads to significant performance degradation due to coordination overhead and error propagation.
-
------
-
-## 2\. Core Architectural Archetypes
-
-The study evaluates five topologies. Your system should treat these not as fixed choices, but as transient states instantiated by the Orchestrator.
-
-| Architecture | Topology | Primary Characteristic | Error Amplification |
-| :--- | :--- | :--- | :--- |
-| **Single Agent (SAS)** | Monolithic | Zero overhead; constant-time context access. | **1.0x** (Baseline) |
-| **Independent** | Parallel / Ensemble | Maximal parallelism; no shared context. | **17.2x** (Unchecked) |
-| **Centralized** | Star / Hierarchical | "Manager-Worker" flow; high control; error filtering. | **4.4x** (Dampened) |
-| **Decentralized** | Mesh / Swarm | Peer-to-peer context sharing; high adaptability. | **High** (Variable) |
-| **Hybrid** | Mixed | Combination of Star and Mesh; highest overhead. | **High** |
-
------
-
-## 3\. The Three Scaling Laws
-
-Your orchestration logic must account for these three governing constraints:
-
-### I. The Tool-Coordination Trade-off
-
-Agents operate under fixed "inference budgets." Resources allocated to coordination (communication tokens, context window management) compete directly with resources for execution (tool use, reasoning).
-
-  * **Implication:** Tasks requiring heavy tool usage (e.g., complex API interaction) suffer disproportionately in MAS setups. The Orchestrator should default to **SAS** or **Centralized** (low chatter) for tool-heavy tasks.
-
-### II. Capability Saturation (The 45% Threshold)
-
-MAS architectures yield diminishing returns as the base model’s competence increases.
-
-  * **Finding:** When a single agent achieves $>45\%$ success rate, adding agents yields $\beta = -0.408$ (negative returns).
-  * **Implication:** Your system is most effective when "raising the floor" of weaker models or difficult sub-tasks. It should not over-engineer solutions for tasks the base model can already solve.
-
-### III. Topology-Dependent Error Propagation
-
-  * **Independent Agents:** Errors cascade without checks.
-  * **Centralized Agents:** The "Manager" node effectively dampens errors by verifying sub-task outputs before integration.
-  * **Sequential Tasks:** Any hand-off between agents introduces information loss ("broken telephone"), causing error rates to spike in sequential logic chains.
-
------
-
-## 4\. Routing Logic: The Decision Matrix
-
-The "Hybrid" architecture often fails because it incurs overhead on every step. A "Meta-Orchestrator" succeeds by routing tasks to specialized sub-architectures only when the quantitative gain outweighs the coordination tax.
-
-### A. The "Sequential Trap" (Critical)
-
-  * **Condition:** Task B depends strictly on the output of Task A (e.g., debugging, planning, iterative refinement).
-  * **Paper Data:** Multi-agent variants degraded performance by **39–70%**.
-  * **Orchestration Rule:** **DO NOT DELEGATE.** The Orchestrator must execute these tasks internally (Single Agent mode) to maintain a unified chain of thought.
-
-### B. Parallelizable Reasoning
-
-  * **Condition:** Distinct sub-tasks can be solved in isolation (e.g., analyzing 5 different financial reports).
-  * **Paper Data:** **Centralized** architecture yielded **+80.9%** gain.
-  * **Orchestration Rule:** Spawn a **Centralized Squad**. The Orchestrator acts as the map-reducer, assigning sub-tasks and synthesizing results.
-
-### C. Dynamic / Adaptive Environments
-
-  * **Condition:** Information is non-static or distributed; requires rapid local updates (e.g., web navigation, competitive search).
-  * **Paper Data:** **Decentralized** architecture yielded **+9.2%** gain (vs +0.2% for Centralized).
-  * **Orchestration Rule:** Spawn a **Decentralized Swarm**. Allow peer-to-peer communication for rapid context sharing, bypassing the bottleneck of a central manager.
-
------
-
-## 5\. Implementation Strategy: "Lean Router" vs. "Fat Manager"
-
-To avoid the pitfalls of the standard Hybrid model, your system requires a **Lean Router** design.
-
-  * **Fat Manager (Avoid):** Maintains active connections to all sub-agents; interjects in every turn; attempts to merge all context histories.
-      * *Result:* Context window bloat ($O(n^2)$), high latency, confusion.
-  * **Lean Router (Recommended):**
-    1.  **Analyze:** Classify the prompt (Sequential vs. Parallel vs. Dynamic).
-    2.  **Instantiate:** Spin up the specific topology (e.g., a temporary Centralized Squad).
-    3.  **Handoff:** Pass the payload to that sub-system.
-    4.  **Suspend:** The Router waits (consumes 0 inference during execution).
-    5.  **Reintegrate:** Receive the final artifact and terminate the sub-system.
-
-### Proposed Pseudo-Logic for Router Agent
-
-```python
-def route_task(task_input):
-    features = analyze_task_features(task_input)
-
-    # CRITICAL: Check sequential dependency first
-    if features.is_sequential_chain_of_thought:
-        return execute_sas(task_input) # Single Agent System
-
-    # Check for high parallelism opportunity
-    if features.subtask_independence > 0.8:
-        return spawn_centralized_squad(task_input)
-
-    # Check for dynamic environment needs
-    if features.requires_environment_adaptability:
-        return spawn_decentralized_swarm(task_input)
-
-    # Default to baseline to conserve budget
-    return execute_sas(task_input)
-```
-
------