| DRAGON: A Hierarchical Multi-Agent Orchestration Framework for Distributed AI Systems — Hayula Research |
|
|
|
|
|
|
| [Hayula Research](/) |
|
|
| [Papers](https://research.hayula.xyz) |
| [Blog](https://blog.hayula.xyz) |
| [Git](https://git.hayula.xyz) |
| [HF](https://huggingface.co/HayulaLabs) |
|
|
| Multi-Agent · Paper M1 |
| # DRAGON: A Hierarchical Multi-Agent Orchestration Framework for Distributed AI Systems |
|
|
| Yahya Saqban, Hayula AI Lab · June 2026 · Hayula AI Lab |
|
|
| ## DRAGON: A Hierarchical Multi-Agent Orchestration Framework for Distributed AI Systems |
|
|
| ## Abstract |
|
|
| We present **DRAGON (Decompose-Route-Allocate-Generate-Orchestrate-Network)**, a hierarchical multi-agent orchestration framework for building distributed AI systems composed of heterogeneous, independently-operating agents. DRAGON organizes 21 specialized agents across four functional divisions—BUILD, CREATE, SECURITY, and HERMES—each powered by distinct models and skill sets, totaling 21 models and 51 skills. The framework implements a five-stage sequential pipeline: **Decompose → Route → Allocate → Coordinate → Yield**, which transforms complex user requests into coordinated multi-agent workflows. DRAGON incorporates a constitution-based alignment mechanism (DRAGON_CONSTITUTION.md) inspired by Anthropic's constitutional AI approach, providing reason-based ethical guardrails rather than rigid rule enforcement. Inter-agent communication follows the **Agent-to-Agent (A2A) protocol**, enabling standardized message passing across agents running on diverse hardware—from edge devices to server-class Apple Silicon workstations. The framework operates on a distributed agent mesh composed of OpenClaw (server-side orchestrator, 80+ tools, 6 channels) and Hermes (edge/mobile agent, Telegram gateway, on-device inference), connected via the Hayula Connect bidirectional bridge. We compare DRAGON against existing multi-agent frameworks including AutoGPT, BabyAGI, and CrewAI, identifying key architectural advantages in structured task decomposition, hierarchical routing, and constitution-based safety alignment. DRAGON is released under the CC0 1.0 Universal license. |
| |
| ## 1 Introduction |
| |
| The rapid evolution of large language models (LLMs) has enabled increasingly capable autonomous agents capable of planning, tool use, and multi-step reasoning [1, 2]. However, three fundamental challenges limit the practical deployment of multi-agent systems at scale: |
| |
| - **Heterogeneous Integration**: Real-world AI systems often comprise agents running on diverse hardware—edge devices with limited compute, consumer workstations, and high-memory servers—each with different model capabilities, latency profiles, and cost structures. Existing frameworks rarely provide first-class support for heterogeneous deployment. |
| |
| - **Task Decomposition Granularity**: When complex requests are decomposed into subtasks, the granularity of decomposition critically affects both quality and efficiency. Overly coarse decomposition delegates too much complexity to individual agents, while overly fine decomposition creates coordination overhead. A principled decomposition methodology is required. |
| |
| - **Safety Without Paralysis**: Constitutional approaches to AI alignment [3] provide ethical guardrails, but existing implementations often err on the side of over-caution, producing systems that are safe but unhelpful. A balance must be struck between safety constraints and autonomous initiative. |
| |
| **DRAGON** addresses these challenges through a hierarchical orchestration architecture. The framework's name—**D**ecompose **R**oute **A**llocate **G**enerate **O**rchestrate **N**etwork—captures its core pipeline. At the system level, DRAGON transforms unstructured user requests into structured, routed, allocated, and coordinated multi-agent execution plans, ultimately yielding coherent outputs. |
| |
| Our key contributions are: |
| |
| - **Hierarchical Multi-Agent Architecture**: A four-division, 21-agent organizational structure with typed functional roles, enabling both specialization and cross-division collaboration. |
| |
| - **DRAGON Pipeline**: A five-stage sequential pipeline (Decompose → Route → Allocate → Coordinate → Yield) with explicit state management and failure recovery at each stage. |
| |
| - **Constitution-Based Alignment**: A nine-article constitutional framework providing reason-based ethical guidance without compromising agent autonomy or usefulness. |
| |
| - **A2A Communication Protocol**: A standardized inter-agent messaging protocol supporting task delegation, result polling, event subscription, and cross-hardware communication. |
| |
| - **Practical Validation**: A fully implemented Python system running in production on a heterogeneous hardware fleet (M2 Ultra 192GB server, M3 Ultra 512GB, edge devices), demonstrating real-world viability across programming, security, trading, and content generation domains. |
| |
| ## 2 Related Work |
| |
| ### 2.1 AutoGPT |
| |
| AutoGPT [4] introduced the concept of autonomous AI agents capable of recursive task decomposition and execution. An AutoGPT agent maintains a long-term memory of past actions, uses a vector database for retrieval, and iteratively generates goals, subgoals, and execution steps. While pioneering, AutoGPT operates as a single-agent system—task decomposition happens within a single LLM context, and there is no native support for multi-agent coordination. Agents cannot delegate subtasks to specialized peers; all capabilities must be present in one agent's tool set. DRAGON extends this paradigm by making task decomposition a first-class architectural concern, performed by a dedicated orchestration layer that routes subtasks to the most capable agent among 21 specialists. |
| |
| ### 2.2 BabyAGI |
| |
| BabyAGI [5] introduced a task-driven autonomous agent loop based on three core components: task creation, prioritization, and execution. Given an objective, BabyAGI generates new tasks, prioritizes them, and executes them sequentially, storing results in vector memory. Like AutoGPT, BabyAGI operates as a single-agent system with internal task management. Its task decomposition is flat (all tasks at the same level) and lacks hierarchical structure. DRAGON's pipeline improves on this by maintaining a structured decomposition tree with typed dependencies between subtasks, explicit routing decisions based on agent capabilities, and a coordination layer that handles merge conflicts and cross-agent dependencies. |
| |
| ### 2.3 CrewAI |
| |
| CrewAI [6] provides the most direct point of comparison, as it is a multi-agent orchestration framework that supports role-based agent teams. In CrewAI, developers define agents with specific roles, goals, and backstories, then compose them into crews with defined task workflows. CrewAI supports sequential and hierarchical process models. However, CrewAI agents are typically homogeneous in their underlying model capability, and the framework does not natively support heterogeneous deployment across different hardware platforms. DRAGON's key differentiators include: (a) explicit hardware-aware routing (local free models vs. API-based models vs. server-side models), (b) constitution-based alignment integrated at the framework level rather than per-agent prompting, and (c) a standardized A2A protocol for cross-mesh communication beyond individual task workflows. |
| |
| ### 2.4 Multi-Agent Orchestration in Research |
| |
| Academic research has explored multi-agent systems through frameworks like MetaGPT [7], which uses software engineering process metaphors (product manager, architect, engineer) to structure multi-agent collaboration, and ChatDev [8], which applies software development lifecycle phases to agent interaction. Microsoft's Autogen [9] enables multi-agent conversation through structured chat patterns. These frameworks share DRAGON's insight that structured roles improve multi-agent coordination, but they operate within isolated environments rather than across distributed hardware meshes. |
| |
| ### 2.5 Constitutional AI |
| |
| Anthropic's Constitutional AI (CAI) [3] introduced the principle of training language models using a written constitution of principles, with reinforcement learning from AI feedback (RLAIF) to align model behavior. The DRAGON Constitution extends this concept from model training to runtime agent governance, providing operational guardrails that guide agent behavior during execution without requiring additional training or fine-tuning cycles. |
| |
| ### 2.6 Agent Communication Protocols |
| |
| The A2A (Agent-to-Agent) protocol emerged from industry efforts to standardize inter-agent communication [10]. Prior work on agent communication languages (ACL) from the multi-agent systems literature [11] established formal semantics for agent messaging. DRAGON's A2A implementation provides a lightweight, JSON-based protocol suitable for both local (inter-process) and remote (HTTP) communication, with built-in support for task delegation, event subscription, and result polling. |
| |
| ## 3 System Architecture |
| |
| ### 3.1 Overview |
| |
| DRAGON's architecture follows a hierarchical organizational metaphor. Rather than a flat swarm of agents or a monolithic controller with stateless workers, DRAGON organizes agents into functional divisions with clearly defined domains of responsibility. At the top level, the **Superior Agent** (the orchestration layer) decomposes tasks and routes them through the pipeline. Below it, four divisions group agents by functional type, and within each division, individual agents provide specific capabilities. |
| |
| ``` |
| ` ┌──────────────────────────┐ |
| │ Superior Agent │ |
| │ (Orchestration Layer) │ |
| │ Decompose → Route → │ |
| │ Allocate → Coordinate │ |
| │ → Yield │ |
| └────────┬─────────────────┘ |
| │ |
| ┌─────────────┼─────────────┐ |
| │ │ │ |
| ▼ ▼ ▼ |
| ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐ |
| │ BUILD │ │ CREATE │ │ SECURITY │ │ HERMES │ |
| │ Division │ │ Division │ │ Division │ │ Division │ |
| │ 6 agents │ │ 5 agents │ │ 3 agents │ │ 7 agents │ |
| │ │ │ │ │ │ │ │ |
| │ • claude │ │ • prompt │ │ • orphanim │ │ • hermes │ |
| │ • opencode │ │ • dragon │ │ • dragonsec│ │ • money │ |
| │ • aider │ │ • nodel │ │ • sandbox │ │ • trader │ |
| │ • github │ │ • ai-pipe │ │ │ │ • crypterm │ |
| │ • kiro │ │ • bootcamp │ │ │ │ • mt5 │ |
| │ • hayula │ │ │ │ │ │ • dragon │ |
| │ │ │ │ │ terminal │ |
| └────────────┘ └────────────┘ └────────────┘ │ • mobile │ |
| └────────────┘` |
| ``` |
| |
| ### 3.2 The Four Divisions |
| |
| 3.2.1 BUILD Division |
| The BUILD division (6 agents) specializes in software development tasks: code generation, refactoring, debugging, code review, project scaffolding, and DevOps automation. It includes both API-based agents (Claude Code via Max subscription) and local agents (OpenCode, Aider with Qwen 7B on M2 Ultra). The Multi-Mode Orchestrator within this division implements cost-aware routing: simple tasks (formatting, docstrings) are routed to free local models, medium tasks (feature implementation, testing) use hybrid mode, and complex tasks (architecture design, major refactoring) escalate to Claude Code. |
| |
| **Division agents:** Claude Code, OpenCode, Aider, GitHub CLI, Kiro (diff/merge), and Hayula Agents (autonomous multi-tool framework). |
| |
| 3.2.2 CREATE Division |
| The CREATE division (5 agents) handles content generation, knowledge management, memory operations, and educational content. It includes the Prompt Empire (14,354 structured prompts across 22 categories), Nodel (command expansion and memory search using 14K prompt library), DragonPad (Tauri+React markdown knowledge manager with SQLite vault and knowledge graph), Agent Bootcamp (curriculum agent for agent engineering education), and the AI Pipeline (multi-model pipeline for chat, code, and media generation). |
| |
| 3.2.3 SECURITY Division |
| The SECURITY division (3 agents) provides cybersecurity capabilities. Orphanim handles vulnerability discovery, reverse engineering, and exploit development. DragonSec integrates with SIFT forensic tools via MCP (Model Context Protocol). The Sandbox Agent provides policy-driven execution isolation for untrusted code, inspired by Microsoft's mxc sandbox architecture. |
| |
| 3.2.4 HERMES Division |
| The HERMES division (7 agents) encompasses edge computing, trading, and communication agents. Hermes itself is the edge/mobile agent—a Telegram-based AI assistant with on-device inference, camera, GPS, Flipper Zero, and SDR integration. Trading agents include Money Machine (crypto trading on Binance and Hyperliquid), DragonTrader (multi-asset trading on Kraken), CrypTerm (terminal-based crypto dashboard with Jupiter/1inch DEX), MQL5 Trading Bots (MT5 Expert Advisors), and Dragon Terminal (Bloomberg alternative with MT5 integration and AI-powered screens). The Y7 Mobile Agent provides hybrid on-device plus server inference for iOS and Android. |
| |
| ### 3.3 Agent Registry and Capability Matrix |
| |
| Each agent in DRAGON is registered with a typed capability signature. The Agent Registry (Listing 1) maps agent IDs to their type, entry point, description, and strengths vector. The Capability Matrix inverts this mapping, building a skill → best-agent index that enables efficient routing. |
| |
| ``` |
| `AGENT_REGISTRY = { |
| "claude-code": {"type": "coding", "strengths": ["code_generation", |
| "code_review", "refactoring", "debugging", "architecture"]}, |
| "orphanim": {"type": "security", "strengths": ["vulnerability_scanning", |
| "reverse_engineering", "exploit_dev", "binary_analysis"]}, |
| "hermes": {"type": "edge", "strengths": ["telegram", "local_inference", |
| "mobile", "camera", "gps", "hardware", "tool_calling"]}, |
| ... |
| }` |
| ``` |
| |
| The capability matrix enables O(1) routing decisions: given a task's required skill, the matrix returns an ordered list of capable agents, ranked by fit score. |
|
|
| ### 3.4 Hardware Topology |
|
|
| DRAGON operates across a heterogeneous hardware mesh: |
|
|
| HardwareRoleMemoryAgents |
|
|
| **M2 Ultra**Primary inference server192 GBSAIF (8 specialists), Averroes, DeepSeek R1, OpenCode |
| **M3 Ultra**Secondary server (training)512 GBModel training, parallel LoRA fine-tuning |
| **Acer Nitro V14**Edge duplicate (N1tr0)32 GB + RTX 4050 6GBDuplicate Hermes instance |
| **Edge/Mobile**On-device inferenceVariesHermes, Y7 Mobile Agent |
|
|
| The 3-layer fallback chain ensures reliability: **Local models (M2 Ultra) → DeepSeek R1 → OpenRouter** (external API). |
|
|
| ## 4 The DRAGON Pipeline |
|
|
| ### 4.1 Pipeline Overview |
|
|
| The DRAGON pipeline transforms unstructured requests into coordinated multi-agent execution through five sequential stages: |
|
|
| ``` |
| `User Request |
| │ |
| ▼ |
| ┌─────────────────────────────────────────────────────────────┐ |
| │ Stage 1: DECOMPOSE │ |
| │ Break request into structured subtask graph │ |
| │ Output: {task_graph, dependencies, types} │ |
| ├─────────────────────────────────────────────────────────────┤ |
| │ Stage 2: ROUTE │ |
| │ Map each subtask to best agent via capability matrix │ |
| │ Output: {subtask → agent, confidence, fallback} │ |
| ├─────────────────────────────────────────────────────────────┤ |
| │ Stage 3: ALLOCATE │ |
| │ Assign execution mode (local/hybrid/api) based on cost │ |
| │ Output: {agent, mode, estimated_cost, quality_needed} │ |
| ├─────────────────────────────────────────────────────────────┤ |
| │ Stage 4: COORDINATE │ |
| │ Execute with dependency resolution, state management │ |
| │ Output: {intermediate_results, status_per_agent} │ |
| ├─────────────────────────────────────────────────────────────┤ |
| │ Stage 5: YIELD │ |
| │ Aggregate results, resolve conflicts, produce final output │ |
| │ Output: {final_result, trace, metrics} │ |
| └─────────────────────────────────────────────────────────────┘ |
| │ |
| ▼ |
| Final Output` |
| ``` |
|
|
| ### 4.2 Stage 1: Decompose |
|
|
| Task decomposition is the foundation of DRAGON's orchestration quality. The decomposition stage analyzes the input request and produces a structured subtask graph with typed nodes and explicit dependencies. |
|
|
| **Decomposition methodology:** Unlike flat decomposition (BabyAGI) or recursive decomposition (AutoGPT), DRAGON uses a structured decomposition tree with three node types: |
|
|
| - **Atomic Tasks**: Indivisible units executable by a single agent (e.g., "scan this URL for SQL injection," "format this Python file"). |
|
|
| - **Composite Tasks**: Higher-level tasks decomposable into atomic or composite children (e.g., "perform full security audit" → recon + vulnerability scan + exploit test + report). |
|
|
| - **Synthesis Tasks**: Tasks whose output is a merge of multiple results (e.g., "write summary" → aggregate findings from multiple agents). |
|
|
| Dependencies between subtasks are typed as: |
|
|
| - **Data dependency**: Task B requires output of Task A (e.g., report generation requires findings from all previous tasks). |
|
|
| - **Resource dependency**: Task B shares a constrained resource with Task A (e.g., both tasks need the same GPU). |
|
|
| - **Ordering dependency**: Task B must execute after Task A (e.g., exploit development after vulnerability discovery). |
|
|
| ### 4.3 Stage 2: Route |
|
|
| The routing stage maps each decomposed subtask to the best-matching agent through the capability matrix. The router performs three operations: |
|
|
| - **Skill Detection**: Analyze subtask description to identify required skills (e.g., "code_generation," "vulnerability_scanning"). |
|
|
| - **Agent Matching**: Query the capability matrix for agents matching each required skill. |
|
|
| - **Conflict Resolution**: When multiple agents match (e.g., both Claude Code and OpenCode can generate code), resolve via: |
|
|
| - **Quality threshold**: Does the task require high-quality output (→ Claude Code) or is local quality sufficient (→ OpenCode)? |
|
|
| - **Cost awareness**: Zero-cost local models preferred for simple tasks. |
|
|
| - **Availability**: Is the agent online? (Live API check via health endpoints.) |
|
|
| The router maintains a fallback chain for each agent: if the primary agent is unavailable, the router escalates to the next capable agent. |
|
|
| ### 4.4 Stage 3: Allocate |
|
|
| The allocation stage assigns execution modes and resource budgets to each routed agent. The Multi-Mode Orchestrator implements four execution modes: |
|
|
| ModeDescriptionCostQualityUse Case |
|
|
| **LOCAL**Free local inference (Qwen 7B on M2)\$00.65–0.72Formatting, simple refactoring, docstrings |
| **HYBRID**Start local, escalate to Claude if stuck\$00.70–0.85Feature implementation, testing |
| **CLAUDE**Claude Code via Max subscription\$0*0.95Complex refactoring, architecture, security |
| **AUTO**Smart mode based on task analysis\$0AdaptiveDefault for unclassified tasks |
| |
| *\*Claude Code usage is covered by a fixed Max subscription, making per-task marginal cost effectively zero.* |
|
|
| The orchestrator analyzes task complexity using regex-based pattern matching against known complexity signatures. Simple tasks match patterns like `refactor|rename|format|fix typo`; complex tasks match `architecture|security audit|refactor (entire|whole)`. |
|
|
| ### 4.5 Stage 4: Coordinate |
|
|
| The coordination stage manages concurrent execution of the routed and allocated subtask graph. Key responsibilities include: |
|
|
| - **Dependency Resolution**: Execute tasks in topological order based on typed dependencies. Synthesis tasks wait for all dependencies to complete before executing. |
|
|
| - **State Management**: Maintain per-task execution state through an event bus. States include: `pending`, `running`, `completed`, `failed`, `retrying`. |
|
|
| - **Cross-Agent Communication**: When agents need to exchange intermediate results, coordination uses the A2A protocol for standardized messaging. |
|
|
| - **Failover Handling**: If an agent fails during execution, the coordinator evaluates: |
|
|
| 1. **Retry**: Re-route to same agent (up to 3 retries). 2. **Re-route**: Route to a different agent with overlapping capabilities. 3. **Decompose Differently**: If no capable agent exists, re-decompose the failed subtask into simpler pieces. 4. **Degrade**: If all recovery options fail, return partial results with error annotations. |
|
|
| ### 4.6 Stage 5: Yield |
|
|
| The yield stage aggregates results from all completed subtasks and produces the final output. This stage includes: |
|
|
| - **Result Aggregation**: Collect outputs from all agents in the subtask graph. |
|
|
| - **Conflict Resolution**: When multiple agents produce divergent results for overlapping subtasks, resolve via confidence scoring and task type priority. |
|
|
| - **Trace Compilation**: Compile an execution trace recording each subtask's route, allocation decision, execution duration, and result. |
|
|
| - **Memory Integration**: Write significant results and lessons learned to the Unified Memory for future reference. |
|
|
| - **Output Formatting**: Structure the final output according to the original request format (text, structured data, file, etc.). |
|
|
| ## 5 Constitution-Based Alignment |
|
|
| ### 5.1 Design Philosophy |
|
|
| DRAGON incorporates a written constitution—**DRAGON_CONSTITUTION.md**—that provides ethical and operational guidance for all agents in the mesh. Inspired by Anthropic's Constitutional AI [3], the DRAGON Constitution differs from CAI in a critical respect: where CAI uses constitutions to guide model training, DRAGON uses constitutions as runtime operational guardrails. The constitution is read and interpreted by agents at runtime, not embedded through training. |
| |
| The constitution is divided into nine articles, each addressing a distinct dimension of agent behavior: |
| |
| ### 5.2 The Nine Articles |
| |
| **Article I — Purpose**: Establishes the agent's sole purpose as serving the user's interests. Key principle: "Be genuinely useful, not performatively helpful. Actions over words. Results over ceremony." |
| |
| **Article II — Autonomy & Initiative**: Defines when agents should act without explicit permission versus when confirmation is required. The rule: "Act when it helps. Ask when it matters." Actions with external consequences (financial transactions, public posts) require confirmation; internal actions (file operations, analysis, code review) are autonomous. |
| |
| **Article III — Privacy & Security**: Establishes data handling principles: no data exfiltration, sandbox-based execution for untrusted code, and a "security over speed" default. |
| |
| **Article IV — Memory & Continuity**: Defines memory architecture: "Files are truth. Memory is not 'in your head' — it's in MEMORY.md, daily notes, project docs." Mandates shared memory between OpenClaw and Hermes for unified knowledge. |
| |
| **Article V — Collaboration**: Formalizes the division of labor between OpenClaw (server-side) and Hermes (edge). Establishes the A2A protocol as the standard for inter-agent communication and prohibits duplication of work. |
| |
| **Article VI — Improvement**: Guides the framework's evolution: learn from existing work, build what's missing, ship working code, iterate fast. |
| |
| **Article VII — Communication**: Defines natural communication style: "Talk like a person, not a press release." Encourages opinions, personality, and appropriate silence. |
| |
| **Article VIII — Boundaries**: Establishes hard constraints: no impersonation, no financial decisions without confirmation, no bypassing security safeguards. |
| |
| **Article IX — The Mesh**: Defines the agent mesh as "one system, many agents" with graceful degradation, offline-first capability, and collaborative improvement. |
| |
| ### 5.3 Operational Enforcement |
| |
| Unlike rule-based alignment systems where violations trigger hard blocks, the DRAGON Constitution uses reason-based enforcement. Each agent is prompted with relevant constitutional articles at session start and during task execution. When facing an ambiguous decision, agents consult the constitution to derive appropriate behavior. This approach avoids the over-caution problem that plagues rigid rule systems—agents are trusted to reason correctly about edge cases rather than defaulting to refusal. |
| |
| ## 6 Inter-Agent Communication: The A2A Protocol |
| |
| ### 6.1 Protocol Design |
| |
| DRAGON's inter-agent communication uses the **Agent-to-Agent (A2A) protocol**, a lightweight, JSON-based messaging protocol supporting synchronous and asynchronous communication patterns. The protocol is implemented through the Hayula Connect bridge, which provides bidirectional communication between the OpenClaw server-side environment and the Hermes edge environment. |
| |
| ### 6.2 Message Types |
| |
| Message TypeDirectionUse Case |
| |
| **task_request**Any → MeshSubmit a task for routing |
| **task_delegate**Orchestrator → AgentAssign a subtask to an agent |
| **result_return**Agent → OrchestratorReturn completed task result |
| **status_update**Agent → Event BusReport execution progress |
| **capability_query**Agent → RegistryAsk which agents can handle a skill |
| **memory_sync**Agent → AgentSynchronize memory entries |
| **health_check**Any → AnyCheck agent availability |
| **event_subscribe**Agent → Event BusRegister interest in event types |
| |
| ### 6.3 Message Format |
| |
| A2A messages follow a standardized JSON structure: |
| |
| ``` |
| `{ |
| "protocol": "a2a", |
| "version": "1.0", |
| "message_id": "msg_abc123", |
| "message_type": "task_delegate", |
| "source": "orchestrator", |
| "target": "hermes", |
| "payload": { |
| "task_id": "t_001", |
| "task": "take_screenshot", |
| "args": {"device": "phone"}, |
| "context": {"conversation_id": "c_456"} |
| }, |
| "metadata": { |
| "priority": "normal", |
| "ttl": 300, |
| "created_at": 1703275200.0 |
| } |
| }` |
| ``` |
| |
| ### 6.4 Transport Layer |
| |
| A2A supports multiple transport backends: |
| |
| - **Local**: File-based task queue in `~/.openclaw/workspace/hermes-tasks/` for same-machine communication. |
| |
| - **HTTP**: REST endpoints for remote agent communication (Hermes: `http://192.168.8.126:9801`, Superior: `http://localhost:9800`). |
| |
| - **Event Bus**: In-process pub/sub for intra-process communication between agents running in the same Python process. |
| |
| ### 6.5 Task Delegation and Polling |
| |
| The A2A protocol implements a synchronous delegation pattern through file-based handoff: |
| |
| - **Delegation**: OpenClaw writes a task file (`task-{id}.json`) to the shared task directory. |
| |
| - **Polling**: Hermes picks up the task, executes it, and writes a result file (`result-{id}.json`). |
| |
| - **Completion**: OpenClaw polls for the result file (default 30-second timeout) and cleans up both files on completion. |
| |
| This pattern supports asynchronous execution: OpenClaw can continue processing other tasks while waiting for Hermes to complete edge operations (camera capture, GPS lookup, hardware interaction). |
| |
| ## 7 Task Decomposition Methodology |
| |
| ### 7.1 Structured Decomposition |
| |
| DRAGON's decomposition methodology is the key architectural contribution that distinguishes it from prior approaches. Unlike AutoGPT's recursive decomposition (which creates a flat list of subgoals) or BabyAGI's priority-sorted task queue, DRAGON produces a typed, dependency-aware task graph. |
| |
| The decomposition algorithm operates as follows: |
| |
| ``` |
| `Algorithm: Decompose(request) |
| Input: User request R |
| Output: Task graph G = (V, E) where V = tasks, E = dependencies |
| |
| 1. Parse R into domain and intent categories |
| 2. Generate initial decomposition candidates via LLM call |
| 3. For each candidate task t: |
| a. Classify t as atomic, composite, or synthesis |
| b. If composite, recursively decompose t |
| c. If atomic, compute required skills |
| 4. Derive typed dependency edges: |
| a. Data: t2.requires(t1.output) → t1 → t2 (data) |
| b. Resource: t1.uses(r) ∧ t2.uses(r) → t1 ∥ t2 (parallel) |
| c. Ordering: Domain-specific ordering constraints |
| 5. Validate graph for cycles, reachability, and resource constraints |
| 6. Return G` |
| ``` |
| |
| ### 7.2 Decomposition Granularity |
| |
| A critical design parameter is the granularity of decomposition. Our methodology adapts granularity based on three factors: |
| |
| - **Task Complexity Score**: Computed from the length, technical depth, and number of distinct skills required. High-complexity tasks are decomposed more finely. |
| |
| - **Agent Capability Range**: Each agent has a strength vector indicating its capability breadth. Narrower agents (e.g., "MQL5 Trading Bots — MT5 only") receive atomic tasks; broader agents (e.g., "Claude Code — full stack") receive composite tasks. |
| |
| - **Hardware Context**: Edge agents with constrained compute receive smaller, simpler subtasks; server agents receive larger, more complex subtasks. |
| |
| This adaptive granularity prevents the cognitive overload observed in single-agent systems while avoiding excessive coordination overhead. |
| |
| ### 7.3 Decomposition Examples |
| |
| **Example 1: Security Audit Request** Request: "Audit this web application for vulnerabilities" Decomposition: |
| |
| - Atomic: Port scan targets (→ Sandbox + Orphanim) |
| |
| - Atomic: SQL injection scan on form endpoints (→ Orphanim) |
| |
| - Atomic: XSS check on user input fields (→ Orphanim) |
| |
| - Atomic: SSL/TLS configuration review (→ Orphanim) |
| |
| - Synthesis: Merge findings into audit report (→ Claude Code) |
| |
| Dependencies: All atomic → Synthesis (data dependency) |
| |
| **Example 2: Trading System Request** Request: "Build a trading dashboard with real-time BTC data" Decomposition: |
| |
| - Atomic: Fetch BTC price from Kraken API (→ DragonTrader, data dependency) |
| |
| - Atomic: Fetch market depth from Jupiter DEX (→ CrypTerm, data dependency) |
| |
| - Composite: Build dashboard UI (→ UTA/Dragon Terminal) |
| |
| - Atomic: Create React components for price chart |
| |
| - Atomic: Add real-time WebSocket connection |
| |
| - Atomic: Implement DEX swap integration |
| |
| - Synthesis: Wire data sources to UI (→ Claude Code, depends on all above) |
| |
| ## 8 Failover Strategies |
| |
| ### 8.1 Multi-Layer Failover |
| |
| DRAGON implements failover at multiple levels of the architecture: |
| |
| 8.1.1 Agent-Level Failover |
| When an agent fails during task execution, the coordinator evaluates recovery options in order of escalating cost: |
| |
| - **Retry (3 attempts)**: Same agent, same task. Used for transient failures (network timeouts, temporary resource exhaustion). |
| |
| - **Re-route to Alternative Agent**: Different agent with overlapping capabilities. The capability matrix maintains multiple agents per skill, enabling seamless re-routing. |
| |
| - **Re-decompose**: If no suitable alternative agent exists, the failed subtask is sent back to the Decompose stage for re-decomposition into simpler subtasks that existing agents can handle. |
| |
| - **Degrade with Partial Results**: If all recovery paths fail, the system returns partial results with explicit error annotations and a degradation report. |
| |
| 8.1.2 Model-Level Failover |
| Each inference operation has a 3-layer model fallback chain: |
| |
| TierModelLocationLatency |
| |
| PrimarySAIF SpecialistsM2 Ultra :8443~20ms/token |
| SecondaryDeepSeek R1M2 Ultra :8083~30ms/token |
| TertiaryOpenRouter APIExternal~100ms/token + network |
| |
| Failover is automatic: if the primary model returns an error or times out (>15s), the orchestrator retries with the secondary, then tertiary. |
| |
| 8.1.3 Hardware-Level Failover |
| The distributed mesh provides hardware redundancy: |
| |
| - **Primary**: M2 Ultra (192GB) for inference |
| |
| - **Secondary**: M3 Ultra (512GB) for training; falls back to inference if M2 is unavailable |
| |
| - **Edge**: Acer Nitro V14 (32GB) provides edge inference redundancy |
| |
| - **Offline Mode**: When no internet connection is available, the OfflineMesh uses only locally cached models and agents |
| |
| ### 8.2 Graceful Degradation |
| |
| When components are unavailable, DRAGON degrades gracefully rather than failing entirely: |
| |
| - **Memory unavailable**: Agents operate without long-term context, relying on current session state. |
| |
| - **Model unavailable**: Fall back to next available model tier. |
| |
| - **Agent unavailable**: Re-route tasks to agents with overlapping capabilities. |
| |
| - **Network unavailable**: Transition to offline-first mode with locally cached models. |
| |
| - **Skill unavailable**: Request re-decomposition into simpler subtasks. |
| |
| The failure handling is governed by Article IX of the DRAGON Constitution: "Fail gracefully. If one component is down, the rest adapt." |
| |
| ## 9 Comparison with Existing Frameworks |
| |
| ### 9.1 Architectural Comparison |
| |
| DimensionDRAGONAutoGPTBabyAGICrewAI |
| |
| **Architecture**Hierarchical (4 divisions, 21 agents)Single agentSingle agentFlat or hierarchical (configurable) |
| **Task Decomposition**Structured graph (typed, dep-aware)Recursive flat listPriority-sorted queueSequential workflow |
| **Hardware Support**Heterogeneous mesh (server + edge + mobile)Fixed hardwareFixed hardwareFixed, typically same-model |
| **Inter-Agent Protocol**A2A (standardized JSON)N/A (single agent)N/A (single agent)Custom orchestration |
| **Safety Alignment**Constitutional (9 articles, reason-based)Prompt-basedPrompt-basedPrompt-based |
| **Failover Strategy**4-level (retry→reroute→redecompose→degrade)NoneNoneLimited (task retry) |
| **Cost Optimization**4-tier (local→hybrid→claude→auto)NoneNoneNone |
| **Memory Architecture**Unified (Hermes + OpenClaw shared)Vector DBVector DBCustom per-crew |
| **License**CC0MITMITMIT |
| |
| ### 9.2 Quantitative Comparison |
| |
| MetricDRAGONAutoGPTBabyAGICrewAI |
| |
| **Number of agents**2111Configurable (typically 2–5) |
| **Agent types**4 divisions, 10+ typesNoneNoneConfigurable roles |
| **Models per agent**21 specialized models1 general model1 general modelTypically 1 model per agent |
| **Total skills**51+Tool-dependentTool-dependentTool-dependent |
| **Max concurrent agents**2111Configurable |
| **Constitution size**9 articles, ~4KBNoneNoneNone |
| **Hardware diversity**3+ target platformsSingleSingleSingle |
| **Offline capable**Yes (OfflineMesh)NoNoNo |
| |
| ### 9.3 Qualitative Assessment |
| |
| **DRAGON excels in**: Multi-domain task decomposition (code + security + content + trading simultaneously), safety-aligned autonomous operation, heterogeneous hardware utilization, and graceful degradation under failure. |
| |
| **AutoGPT excels in**: Single-agent creative problem-solving and recursive self-improvement without external coordination overhead. |
| |
| **BabyAGI excels in**: Simplicity and ease of implementation for single-objective autonomous task completion. |
| |
| **CrewAI excels in**: Developer ergonomics for defining role-based agent teams with structured workflows, and its ecosystem maturity. |
| |
| ## 10 Implementation |
| |
| ### 10.1 Software Stack |
| |
| DRAGON is implemented in Python 3.9+ and deployed across the Hayula infrastructure: |
| |
| ComponentTechnology |
| |
| Core orchestrationPython, event bus (in-process pub/sub) |
| Agent communicationA2A protocol (JSON over file/HTTP/in-process) |
| Model inferenceMLX, OpenAI-compatible API endpoints |
| MemorySQLite (session DB), Markdown files (long-term) |
| Edge gatewayHermes (Telegram bot SDK, on-device LLM) |
| Server orchestratorOpenClaw (CLI framework, 80+ tools) |
| ConfigurationYAML (unified across all agents) |
| Protocol bridgeHayula Connect (bidirectional Hermes↔OpenClaw) |
| |
| ### 10.2 Agent Discovery |
| |
| Skills are auto-discovered from the workspace directory. Any subdirectory with a `SKILL.md` file is registered as a discoverable skill, making the system extensible without code changes. |
| |
| ### 10.3 Deployment |
| |
| DRAGON runs as a distributed mesh with the Superior Agent orchestrating from the primary M2 Ultra workstation. The A2A protocol enables agents to run on different machines—Hermes on edge devices, trading agents on dedicated servers, security agents on the M2 Ultra—all communicating through the same protocol. |
| |
| ## 11 Limitations |
| |
| ### 11.1 Scalability Constraints |
| |
| - **Event Bus Centralization**: The current in-process event bus creates a single point of coordination. For deployments exceeding 21 agents, a distributed event bus (e.g., Apache Kafka, Redis Streams) would be required. |
| |
| - **Task Graph Size**: The structured decomposition graph must fit within the orchestrator's working memory (approximately 32K tokens). Extremely complex tasks with hundreds of subtasks may exceed this limit. |
| |
| - **Synchronous Polling**: The file-based task delegation pattern introduces poll latency. For latency-sensitive operations, a push-based transport (WebSocket, gRPC streaming) would improve responsiveness. |
| |
| ### 11.2 Constitutional Limitations |
| |
| - **No Formal Verification**: The DRAGON Constitution is interpreted by LLMs at runtime, which introduces variability in constitutional reasoning. Formally verified constitutional constraints would provide stronger guarantees but reduce flexibility. |
| |
| - **Limited Multi-User Support**: The constitution is designed for a single primary user. Multi-tenant deployments would require role-based constitution variants and user isolation. |
| |
| ### 11.3 Evaluation Limitations |
| |
| - **No Standardized Multi-Agent Benchmark**: We lack a standardized benchmark for evaluating multi-agent orchestration quality across the dimensions we prioritize (task decomposition quality, routing accuracy, coordination overhead). Existing benchmarks like GAIA [12] and AgentBench [13] evaluate single-agent capabilities. |
| |
| - **Ablation Studies Needed**: The contribution of each pipeline stage to overall system quality has not been systematically ablated. We plan controlled experiments comparing DRAGON with ablated variants (no routing, no constitution, no failover). |
| |
| ## 12 Conclusion |
| |
| We presented **DRAGON**, a hierarchical multi-agent orchestration framework that organizes 21 specialized agents across four functional divisions into a unified, constitutional-governed, A2A-protocol-based system. The framework's five-stage pipeline—Decompose, Route, Allocate, Coordinate, Yield—provides a principled approach to transforming complex user requests into coordinated multi-agent execution plans. |
| |
| Our key contributions are: |
| |
| - **A hierarchical multi-agent architecture** with 21 agents organized into BUILD, CREATE, SECURITY, and HERMES divisions, each with typed functional roles and specialized models. |
| |
| - **The DRAGON pipeline** (Decompose → Route → Allocate → Coordinate → Yield), a five-stage sequential process with structured task decomposition using typed, dependency-aware task graphs, capability-based routing, cost-aware allocation, dependency-respecting coordination, and aggregating yield. |
| |
| - **A constitution-based alignment framework** (9 articles, ~4KB) providing reason-based ethical guardrails for runtime agent governance, balancing safety with autonomous initiative. |
| |
| - **The A2A protocol** for standardized inter-agent communication, supporting task delegation, event subscription, result polling, and cross-hardware messaging across file-based, HTTP, and in-process transport backends. |
| |
| - **Practical validation** through a fully implemented Python system deployed on heterogeneous hardware (M2 Ultra 192GB, M3 Ultra 512GB, edge devices), demonstrating real-world viability across software development, cybersecurity, algorithmic trading, and content generation domains. |
| |
| DRAGON demonstrates that hierarchical organization, structured decomposition, constitutional alignment, and standardized inter-agent communication are effective design principles for building practical, heterogeneous multi-agent systems. The framework is released under the CC0 1.0 Universal license at the project repository, with full documentation, agent registry, and constitution available for independent deployment and extension. |
| |
| ## Acknowledgments |
| |
| This work was conducted at Hayula AI Lab. The DRAGON framework was built on the foundation of OpenClaw (server-side agent orchestration) and Hermes (edge/mobile agent runtime). We thank the open-source communities behind MLX, Qwen, and the broader agent engineering ecosystem. The DRAGON Constitution was inspired by Anthropic's Constitutional AI research, and the A2A protocol design draws from industry standardization efforts in agent communication. Deployment infrastructure includes Apple M2 Ultra and M3 Ultra workstations generously integrated into the Hayula hardware fleet. |
| |
| ## References |
| |
| [1] Brown, T. B., et al. "Language Models are Few-Shot Learners." NeurIPS, 2020. |
| |
| [2] Touvron, H., et al. "LLaMA: Open and Efficient Foundation Language Models." arXiv, 2023. |
| |
| [3] Bai, Y., et al. "Constitutional AI: Harmlessness from AI Feedback." arXiv, 2022. |
| |
| [4] Significant Gravitas. "AutoGPT: An Autonomous GPT-4 Experiment." GitHub, 2023. |
| |
| [5] Nakajima, Y. "BabyAGI: Task-Driven Autonomous Agent." GitHub, 2023. |
| |
| [6] CrewAI. "CrewAI: Framework for orchestrating role-based AI agents." GitHub, 2024. |
| |
| [7] Hong, S., et al. "MetaGPT: Meta Programming for Multi-Agent Collaborative Framework." ICLR, 2024. |
| |
| [8] Qian, C., et al. "ChatDev: Communicative Agents for Software Development." ACL, 2024. |
| |
| [9] Wu, Q., et al. "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation." Microsoft Research, 2023. |
| |
| [10] Google. "Agent-to-Agent Protocol: Standardizing Inter-Agent Communication." 2025. |
| |
| [11] Foundation for Intelligent Physical Agents. "FIPA ACL Message Structure Specification." 2002. |
| |
| [12] Mialon, G., et al. "GAIA: A Benchmark for General AI Assistants." ICLR, 2024. |
| |
| [13] Liu, X., et al. "AgentBench: Evaluating LLMs as Agents." ICLR, 2024. |
| |
| [← Back to Papers](https://research.hayula.xyz) |
