-
Notifications
You must be signed in to change notification settings - Fork 2
architecture multi agent framework
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.
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
Note
Currently, all agents simulate execution by sleeping for 2 seconds and returning hardcoded mock data.
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.
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:
...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: floatHere are the agents currently stubbed out in the framework:
| 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 |
| 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 |
| 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 |
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.
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. |
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.
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.
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! ❤️
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.
Not sure where to start? Pick the path that best describes you:
Just getting started? We highly recommend following these guides in order:
- Installation Guide — Get Siyarix running on your machine.
- Onboarding Wizard — Let our interactive wizard help you set up your API keys and environment.
- Setup & Configuration — A deeper dive into customizing your setup.
- Your First Run — A gentle walkthrough of your very first Siyarix command.
Ready to put Siyarix to work? Dive into our operational guides:
- Interactive Chat (REPL) — Learn how to use the powerful interactive terminal.
- Security Workflows — Best practices for recon, vulnerability assessment, and incident response.
- Cloud & IaC Scanning — How to secure your cloud environments and infrastructure code.
- Compliance Frameworks — Map your scans to SOC 2, HIPAA, ISO 27001, and more.
Looking under the hood or wanting to write some code? Start here:
- Contribution Guide — Our workflow, standards, and how you can help!
- Codebase Overview — A comprehensive map of our 82+ source modules.
- Testing Standards — How we ensure reliability with pytest and CI/CD.
- Module Architecture — Component design and responsibilities.
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
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!