Skip to content

architecture multi agent framework

MD MUFTHAKHERUL ISLAM MIRAZ edited this page Jun 24, 2026 · 2 revisions

🤖 Multi-Agent Framework (Experimental / Stub)

Note

👋 Hey there! Siyarix is a personal passion project built by a single developer that is growing and under active development. Some of the architectural components and features described on this page might currently be Planned, Work in Progress, or basic implementations. Stay tuned as it evolves! 🚀

Welcome to the Multi-Agent Framework in Siyarix! 👋 This section provides a foundational stub implementation for our upcoming multi-agent collaboration features.

Warning

Status: EXPERIMENTAL — STUB IMPLEMENTATION

This framework is currently a placeholder infrastructure intended for future development. It is not yet production-ready and should not be relied upon for operational use. All agents currently return mock data and are not connected to real tool execution.


🏗️ Architecture Overview

The architecture is designed around a central orchestrator, the SwarmRouter, which manages various specialized agents.

graph TD
    A[SwarmRouter] --> B[ReconAgent stub]
    A --> C[ExploitAgent stub]
    A --> D[ReportAgent stub]
    
    B -.->|mock: open ports, services, OS detection| B
    C -.->|mock: vuln check, brute, exploit| C
    D -.->|mock: findings, summary, report| D
Loading

Note

Currently, all agents simulate execution by sleeping for 2 seconds and returning hardcoded mock data.


🧩 Core Components (siyarix/core/swarm.py)

🚦 SwarmRouter

The SwarmRouter is the heart of our multi-agent workflow. It accepts a specific goal, selects the most appropriate agents, and returns the aggregated results from their tasks.

router = SwarmRouter(provider="openai")
results = await router.run(goal="Scan 10.0.0.1 for vulnerabilities")

Tip

The run method returns a list of SwarmTask results from each agent involved in achieving the goal.

🕵️ SpecializedAgent (Base Class)

All specialized agents inherit from the SpecializedAgent base class, establishing a consistent and predictable structure:

@dataclass
class SpecializedAgent:
    name: str
    description: str
    provider: str
    max_iterations: int = 3

    async def run(self, goal: str, context: dict) -> SwarmTask:
        ...

📋 SwarmTask

A SwarmTask represents a specific unit of work assigned to an agent. It tracks the progress and outcome of the task.

@dataclass
class SwarmTask:
    agent: str
    goal: str
    status: str          # pending | running | completed | failed
    result: str
    findings: list
    error: str | None
    started_at: float
    completed_at: float
    duration_ms: float

🎭 Available Agents (Stubs)

Here are the agents currently stubbed out in the framework:

🔍 ReconAgent

Aspect Details
Intent Network reconnaissance
Description Scans for open ports, running services, and performs OS detection on the target.
Provider openai
Actual Behavior Sleeps 2s, then returns a hardcoded mock containing open ports (22, 80, 443, 3306, 8080), services, and OS detection info.
Readiness ❌ Not functional

💥 ExploitAgent

Aspect Details
Intent Vulnerability exploitation
Description Checks for known vulnerabilities, performs brute-force attacks, and attempts exploits.
Provider openai
Actual Behavior Sleeps 2s, then returns a hardcoded mock detailing simulated vulnerabilities and exploit attempts.
Readiness ❌ Not functional

📝 ReportAgent

Aspect Details
Intent Report generation
Description Analyzes all findings and generates comprehensive, actionable reports.
Provider openai
Actual Behavior Sleeps 2s, then returns a hardcoded mock featuring findings, a summary, and a severity assessment.
Readiness ❌ Not functional

🛠️ Additional Stubs (siyarix/chat/stubs.py)

The chat/stubs.py module houses extra stubs used specifically for CLI chat demonstrations and testing:

  • 🤖 SimulatedAgent: Returns mock responses to mimic different agent behaviors and personalities.
  • 🤝 SimulatedCollaboration: Provides stubs to demonstrate multi-agent collaboration scenarios.
  • 🎯 SimulatedFindings: Contains pre-defined mock findings used for predictable testing.

Caution

These stubs are meant exclusively for development and demonstration purposes. They should never be used in production execution.


🚧 Current Limitations

Since this is an experimental stub, there are several limitations to be aware of:

Limitation Detail
No inter-agent communication Agents currently operate in isolation and don't share findings or coordinate.
No state machine There is no true lifecycle management (e.g., idle → running → completed).
No AgentMessage protocol A structured messaging system between agents hasn't been implemented yet.
No real tool access All results are currently mocked or hardcoded.
Fixed 2s sleep Concurrency is merely simulated using a standard sleep, not real asynchronous execution.
No task decomposition Goals are passed as-is; agents cannot break them down into smaller sub-tasks.
No result passing The output from one agent is not currently fed into another (e.g., Agent A → Agent B).
No error propagation Failures are captured but not dynamically acted upon by the system.

🚀 Planned Capabilities (Future)

We have exciting plans to evolve this framework! Here’s what’s on the roadmap:

  • Dynamic agent spawning based on the complexity of the assigned goal.
  • 📬 Inter-agent message bus utilizing a robust publish/subscribe model.
  • 🧠 Task decomposition powered by LLM planning.
  • 🕸️ Sharing KnowledgeGraph across all active agents.
  • 🔗 Sequential chaining to manage complex output dependencies.
  • 🔄 Agent lifecycle management, complete with health checks and automatic restarts.
  • 🛠️ Real tool delegation executed through a RegistryExecutor.
  • 🌐 Sub-agent coordination designed for large-scale, intricate operations.

🔌 Integration with AgentCore

The Swarm framework is designed to be highly modular and opt-in.

class AgentCore:
    def __init__(self, swarm: SwarmRouter | None = None):
        self.swarm = swarm  # Injected, not created by default

    async def run_swarm(self, goal: str) -> list[SwarmTask]:
        if not self.swarm:
            logger.warning("No SwarmRouter configured")
            return []
        return await self.swarm.run(goal)

Important

The Swarm router is injected from the outside. AgentCore does not create a SwarmRouter by default, ensuring the system remains lightweight when multi-agent features are not required.


🎯 Future Use Cases

Once fully realized, the Multi-Agent Framework will support powerful scenarios:

Scenario Agents Involved Future Flow
Full pentest of a single host Recon → Exploit → Report Sequential chaining of agents.
Network segment assessment Recon (scaling) → Report Scaled reconnaissance followed by consolidated analysis.
Multi-vector attack Recon → Exploit (multiple) → Report Parallel exploitation across different attack vectors.
Continuous monitoring Recon (scheduled) → Report Periodic, automated execution and reporting.

Note

👋 Welcome to Siyarix! This is a personal passion project built by a single developer. It's currently under active development and growing fast. Expect rough edges, but lots of love! ❤️

🗺️ Siyarix Documentation Map

Welcome to the Siyarix Documentation Map! This page serves as your master compass for navigating the extensive documentation we have built for the platform.

Whether you are a brand new user, a seasoned security operator, or a developer looking to contribute to the core engine, you can find exactly what you need here.


🧭 Quick Navigation

Not sure where to start? Pick the path that best describes you:

🌱 For New Users

Just getting started? We highly recommend following these guides in order:

  1. Installation Guide — Get Siyarix running on your machine.
  2. Onboarding Wizard — Let our interactive wizard help you set up your API keys and environment.
  3. Setup & Configuration — A deeper dive into customizing your setup.
  4. Your First Run — A gentle walkthrough of your very first Siyarix command.

🛡️ For Security Operators

Ready to put Siyarix to work? Dive into our operational guides:

💻 For Developers & Contributors

Looking under the hood or wanting to write some code? Start here:


📂 The Complete Documentation Tree

If you prefer to browse the raw structure, here is a complete layout of the docs/ folder:

docs/
├── 🚀 getting-started/       # Installation, onboarding, and configuration
│   ├── installation.md       # Multi-platform install (pip, brew, winget, docker)
│   ├── onboarding.md         # The interactive 11-step setup wizard
│   ├── setup.md              # Managing API keys, credentials, and settings
│   ├── first-run.md          # A walkthrough of your first session
│   ├── configuration.md      # A deep-dive into advanced settings
│   └── troubleshooting.md    # Common issues and how to fix them instantly
│
├── 📖 user/                  # Daily operations and workflows
│   ├── cli-commands.md       # Reference for 50+ CLI commands across 12 groups
│   ├── interactive-chat.md   # Mastering the AI REPL and 54+ slash commands
│   ├── security-workflows.md # Recon, vulnerability assessment, incident response
│   ├── cloud-scanning.md     # Multi-cloud security scanning (under development)
│   ├── compliance.md         # Framework mapping (SOC 2, NIST, GDPR, PCI-DSS)
│   ├── threat-intelligence.md# Integrations with OTX, NVD, and MITRE ATT&CK
│   ├── playbooks.md          # Building automated YAML-based IR playbooks
│   ├── workflow-files.md     # DAG workflow reference (programmatic API)
│   ├── reporting.md          # Multi-format report generation
│   ├── offline-registry.md   # Running without AI (Offline/Registry execution mode)
│   └── ai-workflows.md       # Advanced AI-driven autonomous operations
│
├── 💻 developer/             # Building, testing, and extending Siyarix
│   ├── codebase-overview.md  # Full module structure mapping
│   ├── contribution-guide.md # How to submit PRs and our coding standards
│   ├── module-architecture.md# Component design and responsibilities
│   ├── testing.md            # Writing tests (pytest), coverage, and CI/CD
│   └── building.md           # Packaging, distribution, and Docker builds
│
├── 🏗️ architecture/          # System design and core internals
│   ├── overview.md           # High-level data flow and layered orchestration
│   ├── ai-agent-pipeline.md  # The AgentCore reasoning and execution pipeline
│   ├── provider-abstraction.md# How we unify 26 different AI providers
│   ├── execution-engine.md   # Plan-based step orchestration
│   ├── memory-and-state.md   # Knowledge graph, session persistence, and learning
│   ├── security-model.md     # The Permission Gate, DLP, audit logging, and OPSEC
│   └── intent-routing.md     # Semantic intent classification and routing
│
├── 🧠 ai/                    # Deep dive into the AI provider & agent systems
│   ├── routing.md            # Managing 26 providers, failovers, and circuit breakers
│   ├── persona-system.md     # Overview of our 10 security personas
│   ├── agent-reasoning.md    # The Observe-Reason-Act loop and tool call repair
│   ├── tool-execution.md     # The tool registry, capability graph, and parsers
│   ├── ensemble.md           # Parallel LLM voting strategies
│   ├── multi-wave.md         # Iterative goal execution with context carry-over
│   ├── prompt-architecture.md# System prompt design and management
│   └── safety.md             # Our rigorous 8-layer hallucination mitigation system
│
├── 🛡️ security/              # Safety, ethics, and threat models
│   ├── reporting.md          # How to safely report vulnerabilities to us
│   ├── threat-model.md       # System threat model and our mitigations
│   ├── operational-security.md# TOR routing, stealth modes, and OPSEC controls
│   ├── ethical-policy.md     # Mandatory rules of engagement for all users
│   └── abuse-prevention.md   # How we prevent misuse of the AI engine
│
└── ⚖️ legal/                 # Licensing and governance
    ├── agpl-guide.md         # A plain-English overview of the AGPL-3.0-or-later license
    ├── why-agpl.md           # The philosophy behind our license choice
    ├── trademark-policy.md   # Branding and trademark guidelines
    ├── responsible-ai.md     # Our framework for ethical AI usage
    ├── disclaimer.md         # Important legal disclaimers
    └── plugin-exception.md   # The license exception for building custom plugins

📖 Key Terminology

As you read through the documentation, you might encounter some specific terms. Here is a quick cheat sheet:

Term What It Means
Provider The backend AI engine powering Siyarix (e.g., OpenAI, Anthropic, Ollama).
Tool A traditional security executable installed on your system (e.g., nmap, nuclei).
Plan A step-by-step sequence of tool commands intelligently generated by the AI.
Workflow A hardcoded, predefined execution path (usually defined in YAML/JSON) that doesn't require AI generation.
Persona A specialized behavioral profile given to the AI (e.g., instructing it to act specifically as a "Network Recon Specialist").
Knowledge Graph Siyarix's internal memory where it stores findings (like IP addresses, open ports) to contextually inform future steps.

Need help finding something specific? Feel free to use the search bar at the top of the documentation site, or open a discussion on our GitHub!

Clone this wiki locally