The Vision
The premise is simple: a single human operator, augmented by AI, should be able to manage infrastructure that would traditionally require a full IT team. Not by working harder, but by delegating to autonomous agents that can execute, observe, and audit each other.
The CyberFlight Agent Swarm is a 14-service multi-agent system designed for autonomous infrastructure management. Every agent has a single responsibility, communicates through a message broker, and operates under strict safety constraints.
Architecture
The Hierarchy
The swarm follows a strict hierarchy with separation of duties:
- Conductor — The orchestrator. Parses natural-language intents via LLM, decomposes tasks into subtasks, and routes them to specialized subagents. Runs on a 35B MoE model (cyberpilot) on the MS-01 workstation.
- Subagents — Four specialized agents that generate orders but never hold
credentials or connect to infrastructure directly:
- Superintendent — Proxmox operations (VM lifecycle, snapshots, migrations) and server administration
- Mercury — Docker container management
- DaVinci — Infrastructure-as-Code generation
- Sapper — Firewall and network policy
- N8N Gatekeeper — The only component with credentials. A non-AI workflow
engine that acts as a privileged execution proxy. When a subagent needs to SSH, call an API,
or authenticate to a service, it submits an order to the Gatekeeper via RabbitMQ. The Gatekeeper:
- Validates the order against a per-agent allowlist (Superintendent can request Proxmox API calls but not Docker)
- Logs the order to Splunk before execution
- Retrieves credentials from a vault
- Executes the connection on the agent's behalf
- Returns sanitized results — the agent never sees the credentials
- Observers — Three independent agents that monitor the swarm itself:
- Monitor — Health checks and performance metrics
- Scribe — Audit logging of all actions
- Judge — Safety validation, verifying that actions match declared intents
Communication: RabbitMQ
All inter-agent communication flows through RabbitMQ. Agents never communicate directly — they publish messages to exchanges and consume from queues. This provides:
- Algorithmic air-gapping. Models exchange schema-validated JSON, not free-form text. They cannot collude or influence each other outside the defined message schema.
- Auditability. Every message is logged. The Scribe observer records all actions for post-hoc review.
- Resilience. If a subagent crashes, messages queue until it recovers. No lost tasks.
Tech Stack
| Component | Technology |
|---|---|
| Agent runtime | Python / FastAPI |
| Message broker | RabbitMQ |
| State store | Redis |
| Persistent storage | PostgreSQL |
| Workflow automation | N8N |
| Metrics | Prometheus + Grafana |
| Container orchestration | Docker Compose |
Deployment
The entire swarm runs on cainfra02 — a dedicated VM on bighost with 24GB RAM. All 14 services
are containerized and managed via Docker Compose. Deployment is a single
docker compose up -d.
LLM Inference Distribution
The swarm distributes inference across three machines:
| Host | GPU/CPU | Role | Speed |
|---|---|---|---|
| MS-01 | i9-13900H (CPU) | Conductor (35B MoE) | 8.2 t/s |
| BigBrain | RTX 4070 (12GB) | Primary agent model | 73 t/s |
| FastForward | RTX 5060 (8GB) | Subagent pool | 67 t/s |
Safety Model
The swarm is designed with defense-in-depth for AI safety:
- Zero credential exposure. No AI agent holds SSH keys, API tokens, or passwords. All privileged operations route through the non-AI N8N Gatekeeper, which retrieves credentials from a vault at execution time. If an agent is compromised, it physically cannot access anything.
- Per-agent allowlists. The Gatekeeper enforces which operations each agent is permitted to request. Superintendent can call the Proxmox API but cannot touch Docker. Mercury can manage containers but cannot modify firewall rules. A valid order from the wrong agent is rejected.
- Intent propagation. The Conductor declares what it intends to do before doing it. Subagents execute only declared intents.
- Independent observation. The Judge observer compares declared intents against actual Gatekeeper execution logs. Mismatches trigger alerts.
- Deterministic execution layer. The Gatekeeper is N8N workflow automation — not an LLM. It cannot be prompt-injected, socially engineered, or hallucinated into unauthorized actions. The connection logic is immune to the failure modes of AI.
- Human-in-the-loop. Destructive operations (VM deletion, firewall changes) require explicit human approval through the Gatekeeper before execution.
Key Takeaways
- Separation of duties applies to AI too. Agents that execute should not be the same agents that audit. Independent observers catch what self-monitoring misses.
- Message brokers beat direct API calls. RabbitMQ gives you queuing, retry logic, and a complete audit trail for free.
- MoE models make CPU orchestration viable. The Conductor doesn't need GPU speed — it needs reasoning quality. A 35B MoE at 8 t/s on CPU is sufficient for orchestration.
- Start with constraints, not capabilities. Define what agents can't do before defining what they can. The safety model should be designed first, not bolted on.