Every call works its way through the tiers — the cheapest, fastest brain first, the cloud only for the genuinely hard cases. Most of the thinking stays local and free on repurposed hardware. Here is a visual on the All-Drama-Llama (ADL) flow — the models, the agents, and the custom-built engines they pull from.
This page is one architecture, shown six ways — the same tier ladder that carries a call from a Small Language Model up to a Large Language Model runs through every tab below, each one built to teach a different part of it.
Curious what this actually costs? The Flow tab has a watts-research interest list — we're measuring real per-query power draw, SLM vs LLM, over 3/6/12 months. Want to run any of this yourself? Request clone/pull access to the repo →
Interested in tracking the actual watt-cost of running various Ollama models on repurposed GPUs — real power draw, per-query and over time, model by model, so the figures above stop being estimates.
Riding alongside the tiers: the OpenClaw agent council, and two shared engines every model can draw on — Tavily for live web research, Little MAE for local behavioral analytics. Here is how they come together: a device probes 40 ports in seconds. Sentinel flags it and OpenClaw hands it to Bloodhound for recon. Bloodhound asks Little MAE — "is this host a regular or a stranger?" (a stranger, first seen three minutes ago) — and pulls Tavily for the latest on that scan signature. The model reads both as context, Scribe writes the finding in plain language, and the case is decided with local behavioral memory plus live web — most of it free and on-box, the cloud only if it is still unsure.
Sentinel is live on ADL today. The rest are one config line away from running on a local model too.
Tavily is a search-and-retrieval API built for AI agents — give it a query and it returns clean, ranked, source-cited web results. It's how AEGIS reaches current information the models were never trained on: fresh CVEs, IOC reputation, vendor advisories, and threat write-ups.
The pipeline: when a case escalates, the relay calls Tavily and the results are folded straight into the Claude prompt as grounding context — so the model reasons over live evidence instead of stale memory. It's a shared tool: DeepRoot escalation uses it today, and any tier or agent (Bloodhound being the natural one) can make the same relay call.
Little MAE turns raw RF and endpoint data into readable graphical data sets — who's a regular vs. a stranger, off-hours anomalies, packet-rate spikes — and the models read those signals as context, the same way they read Tavily's web results. So the brains reason with local behavioral memory, not just the single event in front of them. Two engines, one prompt: Little MAE computes the numbers, the models interpret them.
The big card — a GeForce GTX 1070 — is AEGIS's brain; the small card — an MSI single-fan GTX 1050 Ti — acts as the network auditor (Digital CNA), kept deliberately off the SOC path so a code or network audit never stalls live triage. Both are affordable, second-hand-friendly GPUs — and that's the point: anyone can afford to run capable local models, at a fraction of what the big cloud LLMs cost per query. Put it in perspective — when the hardware and the know-how are this accessible, AI stops being something only a few can wield, and we get a real say in how it's used.
Everything ADL runs on is free, open-source, and this easy to put on your own machine. Here's the whole install for the two pieces — the model runner, and the agent layer on top of it.
Ollama is an open-source tool that downloads, serves, and runs language models entirely on your own machine — no account, no API key, no data leaving the box. Pull a model once, and it answers every prompt after that straight from local weights on disk.
OpenClaw is the multi-agent bridge that sits on top of a model like Ollama — it gives an agent a soul (SOUL.md), a tool policy, and a gateway so it can hold a persistent presence instead of answering one prompt at a time. It's how AEGIS turns a local model into GLAUX, ERGANE, HESTIA, and Sandy.
An SLM — Small Language Model — is a language model built small on purpose: a few billion parameters instead of hundreds of billions, sized to fit and run on a single consumer GPU instead of a datacenter. It answers less than a frontier model, but for a well-scoped job — triage, classification, a first pass on an alert — it's fast, free per query, and fully private, which is exactly why ADL leans on one as the always-on Tier 0 brain.
Run the same basic question through a cloud LLM instead and the gap is stark: a local query on a ~150 W consumer GPU costs a fraction of a cent, the same call to a frontier cloud model runs roughly 1,000× more — and that multiplier compounds across every token, every user, every day (worked out in the math above). Most of what people actually ask AI for — a quick lookup, a spelling check, drafting a short reply — is well inside what an SLM handles fine, locally. That's not just a cost story; it's a resource story: electricity, datacenter cooling water, and new datacenter buildout all scale with query volume. Point everyday questions at an SLM on hardware you already own instead of defaulting to the cloud, and that draw drops by roughly the same order of magnitude — for free, on your own machine, today.
One machine, no internet in the loop. When you ask a local model a question, the whole round-trip happens on that box — the weights are already on disk.
Every reply is generated right there, from weights already on disk — nothing leaves the machine and no cloud is called. If a small model ever tells you it's "cloud-based," that's a hallucination: a model has no idea how it's actually deployed. That privacy is the whole reason triage runs locally first.
Because a model can't know what it is, you tell it — in its system prompt. The community calls this the soul paper: a SOUL.md that spells out an agent's identity, purpose, and guardrails, loaded at the very top of the prompt (used with local models, OpenClaw, and more). Claude Code's equivalent always-loaded context file is CLAUDE.md. That's exactly where you'd correct a small model that thinks it's "cloud-based" — you write what it is, what it's for, and where its limits are. It's where AEGIS gives each model its soul.
The centerpiece: how AEGIS's own agents work. Same three roles — but here the hands are your trusted tools acting on your own network. They analyze and enrich; they never run untrusted code, so there's no throwaway VM.
AEGIS's architecture isolates any agent or orchestrator that could come into contact with untrusted, external, or potentially harmful data — network captures, scanned URLs, third-party API responses, OSINT pipeline output — from the trusted core (the SOC / triage path). This isolation exists specifically to contain prompt injection: if an agent processing untrusted data is compromised via injected instructions, it cannot reach or influence the trusted orchestrator because it never had privileged access to begin with. This matches current OWASP LLM Top 10 guidance on least-privilege tool access and trust-boundary segregation between untrusted content and system instructions.
The Digital CNA — Code & Network Auditor — is part of AEGIS: the agent that audits your own network. It runs on the same three-role flow as the rest of the council — the brain reasons, OpenClaw orchestrates, and the work runs in a controlled environment.
Here's the reusable part: the same flow builds a CTF agent. Same architecture, different job. Below is the one diagram, applied twice.
Swap the target and you've built something new. Point the exact same Brain → OpenClaw → environment loop at a challenge instead of your network and you have a CTF agent. One thing changes: a challenge runs untrusted code, so its environment becomes a disposable VM — isolated and destroyed after. Same flow, new job.
Same three-role loop, pointed two different ways. The architecture is machinery — technical and mechanical, and it doesn't know or care what it's pointed at, because it can't. That's exactly why architecture, infrastructure, isolation, a soul.md, and the flow itself matter so much when you build an agent or model system — they're what decide what the loop is allowed to touch. The loop itself has no say.
Same code, same three-role loop. The only difference is authorization — a CTF box you were invited to break, versus a system you were never given permission to touch. That line is what makes one practice and the other a crime.
You tell the bot what kind of challenge it is; it spins up a fresh VM pre-loaded with only the tools that task needs — nothing more. The wrong tools never touch the box, and the whole thing is torn down when the flag is found.
Isolation is a discipline we practice as we build — the security holy grail: keep the machine that runs untrusted code completely separate from the one you trust, so a compromise on one can never reach the other.
Only status ever crosses that line — never code, never data. Everything below lives entirely on Machine 2.
We'll grow this into a lesson on both sides of the wall: how the boundary gets attacked — VM escape, egress abuse, shared-mount mistakes — and how we, as security students, learn to hold it. Isolation isn't a diagram; it's a practice you build the reflex for.