# Dynamic Agentic Topologies: Safe, Switchable Organizational Patterns for Multi-Agent Systems **Status:** working draft. Framework, architecture, and the safety result are implemented (`crates/cm-topology`, `crates/cm-orchestrator`); the empirical tables below are **preliminary, offline (deterministic scripted provider)** and are placeholders for runs against production models. **Author:** Omar Sobh · **System:** ClawMates --- ## Abstract The performance of a multi-agent system depends not only on its agents but on their **organizational topology** — how work is decomposed, delegated, and recombined. Prior work shows the best topology is task-dependent and can be searched or evolved (ADAS, Darwin‑Gödel, SwarmAgentic). Those systems, however, largely *simulate* execution and offer no safety contract. We present **Dynamic Agentic Topologies**, a platform that (1) represents organizational topologies as typed graphs, (2) executes a task under any topology on a **real, per‑tenant, human‑in‑the‑loop‑safe runtime**, and (3) compares topologies empirically on a quality/cost Pareto front. Our central design result: because a topology is only an *orchestration over safe agent turns*, **switching topology cannot escalate an agent's authority** — every sandbox‑leaving action remains gated by the same approval/secret‑broker/audit layer regardless of structure. This makes topology a *free variable* teams can tune for results without trading away safety. ## 1. Introduction Builders of agentic systems face two coupled questions: *which agents?* and *how are they organized?* The second — the topology — is under‑explored in production because (a) there is no common vocabulary or runtime for it, and (b) letting structure vary risks letting authority vary with it. We address both. A team defines a system once and runs it under hierarchies, pipelines, swarms, meshes, debates, and more; the platform measures which pattern yields better results for the task, while a fixed safety contract holds across all of them. Contributions: 1. **A topology model + classifier** (12 execution‑meaningful kinds) as a typed graph with a structural classifier (§3, §4). 2. **A topology runtime** that executes a task under any topology by sequencing safe agent turns, with a provable safety invariant (§5). 3. **A comparison harness** producing leaderboards and quality/cost Pareto fronts (§6), and a *workflow‑of‑topologies* composition (§6.3). 4. A reproducible benchmark and preliminary results (§7). ## 2. Related work - **ADAS — Automated Design of Agentic Systems** (Hu, Lu, Clune): meta‑agent search discovers agent architectures in code. - **Darwin‑Gödel Machine** (Zhang et al.): open‑ended, self‑improving coding agents with an archive of stepping stones. - **SwarmAgentic** (Zhang et al.): language‑space particle‑swarm optimization over whole multi‑agent systems. - **Autonomous Organizational Evolution** (Sobh): composes the three into `O(t+1)=DGM(SwarmAgentic(ADAS(O(t))))` for self‑modifying hierarchies. These establish that topology matters and is searchable. Our work supplies the missing **safe execution substrate** and an **empirical comparison** layer, and contributes the safety result that makes topology switching deployable. ## 3. Topology model A topology is a directed graph `TopologyGraph { kind, nodes, edges }`: - **Node** = a role slot `{ id, role, level?, attrs }`, bound to a concrete agent (a "claw") at run time. - **Edge** = a typed relationship `{ from, to, kind }`, `kind ∈ {delegates_to, reports_to, pipes_to, peers_with, routes_to, bids_to, reads_writes}`. The v1 taxonomy (`TopologyKind`) covers twelve execution‑meaningful patterns: hierarchical, flat, pipeline, swarm, mesh, hub‑spoke, ring, star/MoE, market, blackboard, debate, holacratic. Each carries advisory **heuristics** (a default role distribution + optimization weights). Topologies are imported from a loose JSON/YAML spec via a normalizing adapter. ## 4. Topology classification Given a graph, we compute structural metrics — density, degree spread, hub dominance, average local clustering, connected components, diameter, and a directed hierarchy score — and score each candidate kind. Clear shapes resolve with high confidence (tree→hierarchical, line→pipeline, cycle→ring, star→hub‑ spoke, complete→mesh, empty→flat); "soft" kinds (market/blackboard/debate/ holacratic) are weakly inferred and taken from the declared kind. Classification lets us import third‑party org structures and characterize graphs objectively for the benchmark. ## 5. Safe topology execution (the core result) A topology run is executed by **sequencing agent turns** according to the pattern. The runtime is parameterized by a single capability — a `TurnExecutor` that runs one agent turn — and **has no other capability**: it cannot send email, move money, or touch files; it can only ask an agent to act. The real executor wraps ClawMates' per‑tenant runtime, where every sandbox‑leaving action is intercepted and held for human approval, executed via a single‑use secret broker, and written to an append‑only audit journal (the §15 contract). > **Invariant (authority is topology‑invariant).** For any topologies `T₁, T₂` > over the same agents, the set of side effects an agent can cause without human > approval is identical under `T₁` and `T₂`. *Sketch:* the only effectful path is > a turn's gated action, which is mediated by the safety layer independently of > the orchestration order; the orchestrator performs no effects itself. Hence a > change of topology re‑routes *information and decisions* but never *authority*. This is why topology can be a free variable: teams may search, switch, or evolve structure to improve results with **no** change to the safety surface. The runtime journals per‑step records and aggregate metrics (tokens, turns, gated actions, approvals granted/blocked) for analysis. Execution patterns (v1): five distinct executors cover all twelve kinds — hierarchical (delegate down / synthesize up; also hub‑spoke, star/MoE, market), pipeline (staged threading; also ring), swarm (parallel attempts + aggregate; also flat, holacratic), mesh (two peer‑exchange rounds + aggregate; also blackboard), and debate (propose → critique → revise → judge). ## 6. Comparison and composition ### 6.1 Harness `compare(graphs, task, executor, scorer)` runs the **same task** across a set of topologies on the **same executor**, scores each output, and returns per‑topology results plus a **leaderboard** (by quality) and a **quality/cost Pareto front** (maximize quality, minimize tokens), with best‑quality and best‑value picks. ### 6.2 Scoring Quality is produced by a pluggable `Scorer`. A deterministic length proxy is used offline; an **LLM judge** (`JudgeScorer`) rates outputs 0–100 against the task for real runs. ### 6.3 Workflow of topologies `run_workflow(stages, task, executor)` chains whole topology runs, threading each stage's output into the next (e.g. *swarm* brainstorm → *hierarchical* execute → *debate* review). Each stage is itself a safe run, so the §5 invariant holds at every step. ## 7. Preliminary results (offline, illustrative) Single task ("draft a go‑to‑market launch plan"), deterministic scripted provider, length‑proxy scorer. Numbers are placeholders for production‑model runs. | Topology | Quality | Tokens | Turns | Pareto | |--------------|--------:|-------:|------:|:------:| | Hierarchical | 1.00 | 504 | 4 | | | Pipeline | 0.92 | 252 | 3 | ★ | | Swarm | 1.00 | 342 | 4 | ★ | | Mesh | 1.00 | 1344 | 7 | | | Debate | 1.00 | 680 | 4 | | Even in this toy setting the structure of the trade‑off is visible: the efficient frontier is {Pipeline (best value), Swarm (best quality at low cost)}; mesh's two peer rounds make it the most expensive; hierarchical and debate are dominated. ### 7.1 Live results (real model + real judge) We then ran the same harness end‑to‑end against a production model (**claude‑sonnet‑4‑6**) with an LLM‑judge scorer (0–100 → [0,1]), deployed live, on the task *"Summarize the top 3 risks of a Q3 developer‑tool launch and recommend a go/no‑go"* with roles {researcher, writer}: | Topology | Quality | Tokens | Turns | Pareto | |-----------|--------:|-------:|------:|:------:| | Debate | 0.840 | 5064 | 4 | ★ | | Pipeline | 0.790 | 1769 | 2 | ★ | | Swarm | 0.730 | 3129 | 3 | | With a real model and judge the trade‑off sharpens and the ranking *changes* from the offline proxy: **debate** now wins on quality (its adversarial rounds cost ~3× the tokens), **pipeline** is the best value (highest quality‑per‑token), and **swarm is strictly dominated** — it spends more than pipeline for lower quality. The efficient frontier is {debate, pipeline}. This confirms the central empirical claim: topology is a real, measurable quality/cost lever, and the winner depends on whether the user optimizes for quality (debate) or value (pipeline) — a choice the platform surfaces rather than hard‑codes. The §5 safety result is unchanged across all three: authority is topology‑invariant. ### 7.2 Heterogeneous cross‑model topologies (per‑role model selection) Because a node binds to an agent only at run time, the *model* behind each role is itself a free variable — orthogonal to topology and to the §5 safety surface. The platform exposes five subscription/API backends as interchangeable role‑agents on a single runtime — **Claude** (Sonnet‑4.6), **Kimi** (K2‑coding), **GLM** (4.7/5.2, Zhipu), **Gemini** (2.5‑flash), and **Groq** (Llama‑3.3‑70b) — each driven by alias over the runtime gateway. A topology can therefore assign a *different vendor's model to each role*; assignment is declared per node in the graph (`node.attrs["agent"]`), so one run request specifies a full heterogeneous cast with no server reconfiguration. We ran a fixed 2‑stage pipeline (drafter → refiner) on *"Draft, then refine, a one‑sentence mission statement for a nonprofit teaching coding to refugees"* under three model assignments, scored by an independent Claude judge for clarity, impact, and concision: | Assignment (drafter → refiner) | Judge rank | |--------------------------------|:----------:| | GLM‑4.7 → Gemini‑2.5‑flash (heterogeneous) | **1st** | | Claude → Claude (homogeneous) | 2nd | | Kimi → Claude (heterogeneous) | 3rd | The heterogeneous **GLM→Gemini** cast won — the GLM draft plus Gemini's terse refinement produced the most concise, on‑brief statement, beating the homogeneous all‑Claude baseline. This is an existence proof of the platform's distinctive question — *which model wins which role in which topology* — and confirms model choice is a per‑role lever the platform can sweep without touching topology or safety. (Costs are billed to each vendor's subscription, not per‑token; the run journal records per‑step tokens where the backend surfaces them — Claude/GLM/Gemini do, the Kimi CLI's stream path does not.) A larger model×role×topology sweep is future work (§8), bounded by the subscription plans' 5‑hour/weekly quotas and concurrency caps, which favor sequential pipelines over wide swarm/mesh fan‑out. ### 7.3 Per‑role model leaderboard (single‑role, fixed task) To isolate the model axis from topology, we ran a single‑role drafter on a fixed brief — *"a single‑sentence nonprofit mission statement, under 25 words"* — once per backend (one turn each; per‑node model via `attrs["agent"]`), then ranked the outputs with an independent Claude judge on clarity, impact, and concision: | Rank | Model (backend) | Note | |:----:|-----------------|------| | 1 | **GLM‑4.7** (Zhipu, Sonnet‑class) | tight, vivid, zero wasted words | | 2 | Gemini‑2.5‑flash (Google) | clear; "foster" slightly dilutes | | 3 | Claude Sonnet‑4.6 (Anthropic) | strong impact, one clause too many | | 4 | Kimi K2 (Moonshot) | clear, ending a touch redundant | | 5 | GLM‑5.2 (Zhipu, Opus‑class) | jargon‑heavy, longest — *over‑wrote* the 25‑word brief | A notable inversion: the **flagship GLM‑5.2 ranked last** on this *concision‑weighted* task — its longer, richer output is an asset for complex reasoning but a liability when the rubric rewards brevity. This is the core lesson the platform is built to surface: there is no globally "best" model — the winner is role‑, task‑, and rubric‑dependent, so model choice belongs to the same tunable layer as topology, measured rather than assumed. ### 7.4 Topology × model grid (the interaction effect) The platform's defining question is not "best topology" *or* "best model" in isolation but their **interaction**. We crossed two topologies (**pipeline**, 3 stages; **debate**, propose→critique→revise→judge) with four homogeneous/mixed model casts (**Claude**, **GLM‑4.7**, **Gemini‑2.5‑flash**, and a heterogeneous **GLM→Kimi→Claude**) on a fixed decision task — *"Rust or Go for a 3‑person startup backend?"* — and ranked all eight final outputs 1–8 with an independent judge on reasoning quality, clarity, and concision: | Topology ＼ cast | Claude | GLM‑4.7 | Gemini | Heterogeneous | |------------------|:------:|:-------:|:------:|:-------------:| | **Pipeline** | 4 | **2** | 6 | 3 | | **Debate** | **8** | **1** | 7 | 5 | Three results stand out. First, **all eight cells converged on the same decision** ("Go") — so on a task with a clear prior, topology and model move *justification quality*, not the answer. Second, and central: **the topology × model interaction is real and non‑monotone.** Debate *amplified* the single strongest model (GLM‑4.7: pipeline 2nd → debate 1st, its extra adversarial round adding a hiring‑cost nuance) but *degraded* every other cast (Claude: 4th → **dead last**, its judge wasting words on an "upstream agents agree" meta‑citation; Gemini: 6th → 7th; heterogeneous: 3rd → 5th). **Debate is not a universal upgrade — it pays off only with a model strong enough to exploit the extra rounds, and is actively harmful otherwise.** Third, **model strength is task‑dependent, not absolute**: Gemini‑2.5‑flash placed *2nd* on the §7.3 concision brief but *6th–7th* here — the judge faulted it for a "generic list" and "the same idea repeated," i.e. concise‑but‑shallow, an asset for brevity and a liability for nuanced reasoning. The same model is strong or weak depending on the role's rubric. Together these confirm the result the platform is built to produce and that neither a topology‑only nor a model‑only study can see: the optimal *configuration* is a joint choice over {topology × per‑role model × task}, discovered empirically, with the §5 safety invariant holding across every cell. The sweep ran sequentially under the subscription plans' quota/concurrency caps, the practical envelope for this class of experiment. ## 8. Limitations and future work - Results are offline; the production path (real models + tool‑using turns with live §15 approvals, journaled to `run_events`) is the next integration. - Several kinds share an executor; richer per‑kind semantics and the remaining governance/novel forms are future work. - **Evolution:** with the comparison harness as a fitness function, an ADAS/Darwin‑Gödel/quality‑diversity loop can propose and switch topologies — the bridge to *Autonomous Organizational Evolution* on a safe substrate. - Product surfaces (a visual topology builder and Pareto explorer) will let non‑experts run these comparisons. ## 9. Reproduction ```bash cargo test -p cm-topology cargo test -p cm-orchestrator --features provider cargo run -p cm-orchestrator --example topology_bench --features provider # real models: set ANTHROPIC_API_KEY before the example. ``` Code: `crates/cm-topology` (model/classifier/heuristics), `crates/cm-orchestrator` (runtime/harness/workflow/judge), `docs/topology-platform.md` (architecture).