Multi-Agent Architecture

AuroraSOC runs one orchestrator plus 13 specialist agents organised in a hub-and-spoke topology. Each specialist handles a specific security domain.

Why multiple specialised agents

A single general-purpose agent struggles with the breadth of security operations:

• A malware analyst needs deep knowledge of reverse engineering, YARA rules, and sandbox behaviour.
• A compliance analyst needs knowledge of NIST, ISO 27001, HIPAA, and PCI-DSS frameworks.
• A CPS security specialist needs understanding of industrial protocols like Modbus, DNP3, and OPC UA.

No single LLM prompt can effectively cover all these domains. Specialisation allows:

1. Focused system prompts: Each agent has a tailored persona with domain expertise.
2. Relevant tool sets: Each agent only sees tools relevant to its domain.
3. Optimised memory: Memory presets tuned per agent type.
4. Independent scaling: Scale hot agents without scaling cold ones.

The hub-and-spoke topology

The diagram above is the full designed topology. The fleet deployed today is the orchestrator plus ten specialists (Threat Hunter, Threat Intel, Incident Responder, Malware Analyst, Forensic Analyst, Network Security, Endpoint Security, Web Security, CPS Security, Report Generator). The Agent Monitor shows them all reachable, with their MCP tool domains healthy:

The Orchestrator

The Orchestrator is the only agent that directly communicates with all other agents. It receives tasks from users or the event pipeline, analyses what specialists are needed, dispatches work using HandoffTools, aggregates results, and synthesises a final response. The Orchestrator does not do the actual security analysis. It is a coordinator.

HandoffTools

Each specialist agent is exposed to the Orchestrator as a HandoffTool. This means the Orchestrator's LLM sees tools like handoff_security_analyst to delegate to the Security Analyst, handoff_threat_hunter to delegate to the Threat Hunter, and so on for all 13 specialists.

Agent communication: A2A protocol

Agents communicate over HTTP using the Agent-to-Agent (A2A) protocol:

A2A was chosen over direct function calls because each agent runs as an independent HTTP service in a separate container. Agents can be deployed on different machines for scaling. The protocol is standardised so any A2A-compatible agent can join. Health checks and circuit breakers work naturally with HTTP.

Parallel dispatch

For complex investigations the Orchestrator dispatches to multiple agents simultaneously using asyncio.gather(), dramatically reducing investigation time.

Agent factory pattern

All agents are created by a central factory. Every agent receives a specialised system prompt, ThinkTool as the first tool (forced at step 1 for reasoning), domain-specific MCP tools, and tiered memory with a preset matching its memory needs. A single factory keeps construction consistent, makes configuration centralised, simplifies testing through mocking, and provides a single source of truth for all agent types.

Fleet runtime control

AuroraSOC uses Docker Compose as the default runtime orchestrator for agent lifecycle management. This enables the Agent Fleet dashboard to:

• Scale agents up or down by adjusting deploy.replicas in the Compose file
• Restart individual agent replicas without touching other services
• View real-time replica status including CPU, memory, and task throughput
• Enable or disable agents by controlling which Compose services are started

Set FLEET_RUNTIME_ORCHESTRATOR=compose in .env (the default). The orchestrator auto-detects your container runtime (podman or docker). If no container runtime is available, it falls back to noop mode and the dashboard shows a read-only view of the live A2A mesh.