Why I Built Argus: A 29-Protocol Local AI Assistant That Doesn’t Touch the Cloud

Most AI assistants sold to us today are glorified web hooks. You talk to a speaker, your voice data bounces off three data centers, an API bills your card per token, and if your home internet flickers, your smart setup turns into a brick.

A few months ago, I got tired of that design loop. I wanted an assistant that lives on the machine sitting on my desk, runs locally under an 8GB memory envelope, and treats my private files like private files.

That project turned into Argus. It isn’t a single bloated Python script trying to do everything at once; it’s an ecosystem of microservices talking across local sockets, file-based message queues, and SQLite.

Here is what went into building it, what broke along the way, and what it actually takes to run a multi-agent system on consumer hardware without burning down your machine.

Escaping the Cloud API Tax

The initial architectural decision was simple: no proprietary API endpoints as defaults. Argus talks to a local Ollama runtime.

Running everything locally forces you to be brutally honest about model selection. You can’t just throw a 70B parameter model at a casual chat turn on everyday laptop hardware. To keep latency low without sacrificing complex logic, Argus routes tasks dynamically between models:

• Llama 3.2 (1B) handles casual back-and-forth conversation, quick classifications, and intent detection with zero perceived lag.
• Llama 3.1 takes over when RAG queries, code analysis, or workflow planning demand deeper reasoning.
• Moondream & YOLOv8 handle vision pipelines, from continuous room awareness via webcam down to object checks.

If a task is so complex that local weights genuinely hit a wall, there’s an opt-in frontier bridge to Anthropic. But the hard rule is structural: it defaults to off, requires an explicit verbal confirmation before sending a single byte, and logs every dollar spent. Your everyday conversation never leaves your local network.

The Reality of Multi-Agent Systems on a Laptop Budget

A lot of multi-agent demos you see online cheat by spinning up five separate 8B models concurrently. Try doing that on an 8GB or 16GB laptop and your OS will choke on memory swapping before the agents finish their opening remarks.

Get Saravananm’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

In Argus, the Round Table engine approaches multi-agent orchestration differently:

1. Personas over separate weights: Each specialist (Architect, Debugger, Security Analyst, Data Engineer, Pragmatist) runs as an isolated prompt persona against the loaded local model, not a distinct in-memory instance.
2. Attention-based routing: When an ambiguous or complex goal comes in, Argus doesn’t summon all eight agents at once. It embeds the task description alongside agent profiles using local sentence transformers, calculates relevance, and only spins up the two to four specialists whose skills match the problem.
3. Autonomous workflows with checkpoints: If an automated workflow runs into a missing variable, it doesn’t hallucinate a guess. It writes a structured state checkpoint to disk, prompts me through voice or terminal for clarification, and resumes right where it halted once I answer.

When Code Hits the Real World: 29 Working Protocols

Building an assistant that can execute actions requires serious guardrails. It’s fun to write an agent that executes shell scripts — until you realize a hallucinated bash command could wipe a directory.

To make Argus genuinely usable in daily work, I organized its capabilities into independent modules:

• Shadow Sandbox: Any generated script or dynamic task executes inside an ephemeral Docker container or an isolated sub-process with hard CPU/RAM limits, scratch file paths, and strict timeouts.
• Voice ID & Proximity Locks: Using SpeechBrain’s ECAPA embeddings, destructive shell actions and git pushes verify my vocal footprint before executing. Meanwhile, a Bluetooth proximity daemon monitors signal strength to the phone — walking away display-locks the workstation automatically.
• Control from the Couch: Instead of tethering myself to the terminal, a FastAPI service serves a mobile control center, an interactive macro deck, and a full-screen touchpad mirror with normalized coordinate mapping so I can direct the desktop cursor from my phone over local Wi-Fi.
• MCP Tool Integration: Rather than reinventing custom plugins for every third-party system, Argus acts as an MCP client using local stdio pipes, keeping credentials inside shell environment variables instead of flat configuration files.

What I Learned the Hard Way

The hardest part of building a multi-module local assistant isn’t prompt engineering; it’s system stability.

When you have six background daemons monitoring CPU thermals, clipboard state, network latency, and inbox file sorting, services will crash. A microphone drops off USB power, a port conflicts, or an audio buffer underruns.

I had to build a dedicated supervisor layer — Protocol Lazarus — to manage the subprocess lifecycle. It distinguishes between transient errors (a socket blip or microphone disconnect) and permanent code bugs (traceback crashes). Transient issues get instantaneous, quiet retries without exhausting system budgets, while genuine syntax or runtime crashes step back with exponential backoff and alert the dashboard.

Local AI doesn’t have to be a toy that just prints markdown in a browser window. When you pair small, sharp models with proper operating-system glue, you get something that feels less like a remote chatbot and more like a dedicated machine co-pilot that actually respects your ownership.

Argus is open-source, local-first, and completely self-hosted. Feel free to check out the project code, setup guide, and microservice definitions on GitHub.