cd /news/ai-agents/i-built-my-own-j-a-r-v-i-s-a-local-p… · home › topics › ai-agents › article
[ARTICLE · art-169600] src=dev.to ↗ pub= topic=ai-agents verified=true sentiment=↑ positive

I Built My Own J.A.R.V.I.S. — A Local, Privacy-First Multi-Agent AI Assistant

A developer has published the architecture for a local, privacy-first multi-agent AI assistant that uses Ollama with small models (qwen2.5:3b, llama3.2:3b, phi3:mini, and Moondream2 for vision) as an orchestrator that dispatches structured function calls over REST to isolated FastAPI agents running in Docker containers for system control, screen vision, and Home Assistant smart-home integration. The design relies on a JSON Schema allowlist of functions rather than raw shell access, keeping all voice, screen, and command data on the local network via Whisper STT and Piper TTS.

by read5 min views2 publishedNov 14, 2026

I wanted a personal AI assistant. Not a chatbot. Not a copilot. Something that actually does things — controls my desktop, reads my screen, talks to my smart home, answers questions in Finnish or English, and never, ever sends my data to a server I don't control.

The cloud options are good. They're not mine.

So I started building one.

This post is the architecture document for that project. It's a work in progress — the docker-compose is ready, the Ollama instance is running, and the first agent is next. I'm writing this because the design decisions are interesting, and because someone else might want to build the same thing.

This isn't a Jarvis like Tony Stark's. It's closer to a privacy-respecting home automation brain — or what you'd get if you crossed a really good CLI assistant with a smart home hub and gave it eyes.

The core idea: a lightweight orchestrator (Ollama) decides what to do. Specialized agents handle how to do it. Each agent runs in its own Docker container. Everything stays on my local network.

What it does:

What it doesn't do: send my commands, my screen contents, or my voice to OpenAI, Google, or anyone else.

                      ┌─────────────────────────────────┐
                      │     Input / Output Layer         │
                      │  (Whisper STT · Piper TTS)     │
                      └──────────────┬──────────────────┘
                                     │
                                     v
                      ┌─────────────────────────────────┐
                      │        OLLAMA (The Brain)       │
                      │   qwen2.5:3b · Function Calling  │
                      │   Response time: < 200ms         │
                      └──────────────┬──────────────────┘
                                     │
         ┌────────────────────────────┼────────────────────────────┐
         │ HTTP/REST                  │ HTTP/REST                  │ HTTP/REST
         v                            v                            v
┌─────────────────────┐  ┌─────────────────────┐  ┌─────────────────────────┐
│   System Agent      │  │   Vision Agent     │  │   Home Assistant Agent  │
│  (Linux / DBus)    │  │  (Screen capture)  │  │  (Smart home control)   │
│ · Volume / Brightness│  │ · maim / grim      │  │ · Lights, sensors       │
│ · Window management │  │ · Moondream2 VLM   │  │ · WebSocket API         │
│ · Process control   │  │ · Screen analysis  │  │ · Automations           │
└─────────────────────┘  └─────────────────────┘  └─────────────────────────┘

Each agent is a FastAPI service inside a Docker container. They don't know about each other. They just expose a clean REST interface and wait for instructions from Ollama.

Ollama runs small, capable LLMs locally. The key feature here is function calling (tool calling) — Ollama doesn't execute commands directly. It returns a structured JSON decision: "call the set_volume function with parameter level: 75".

This is cleaner than giving the LLM raw bash access. The function list is a strict allowlist — defined in JSON Schema. The model can only call what's explicitly permitted. No rm -rf /, no matter how creatively phrased.

The models I'm using are intentionally small:

Model Size Why
qwen2.5:3b ~2GB Main orchestrator. Fast, good Finnish support
llama3.2:3b ~2GB Fallback / general reasoning
phi3:mini ~2GB Lightweight tasks
Moondream2 ~1GB Vision agent — screen capture analysis

All fit comfortably on a mid-range GPU or run on CPU. My Intel i5 desktop handles it fine.

Controls the running Linux session via wmctrl, xdotool, playerctl, and DBus. Things it can do:

pamixer) xbacklight or brightnessctl) gtk-launch or xdg-open) playerctl) No raw bash. Every function is explicitly defined.

Takes a screenshot (maim or grim) or reads a camera stream, then runs the image through a lightweight VLM (Moondream2). Can answer: "What window is in the foreground?", "Did that build succeed?", "What's on my second monitor right now?"

Talks to my Home Assistant instance over its WebSocket API. Lights, switches, climate, sensors — all accessible. I can say: "Turn off the office lights, but only if nobody's in there" and it checks the occupancy sensor before acting.

Pulls in external data when needed: weather forecasts, electricity prices (relevant in Finland), InfluxDB logs, or web searches via a headless browser.

Giving an AI system control over your desktop is a significant trust boundary. I'm implementing human-in-the-loop for sensitive operations:

For destructive or significant actions, the system doesn't just execute. It:

This isn't paranoid — it's sensible. The function allowlist prevents most problems at the model level. The confirmation prompt handles the remaining edge cases.

This is where it lives:

version: '3.8'

services:
  ollama:
    image: ollama/ollama:latest
    container_name: jarvis-ollama
    restart: unless-stopped
    ports:
      - "11434:11434"
    volumes:
      - ollama_data:/root/.ollama

  jarvis-core:
    build: ./core
    container_name: jarvis-core
    restart: unless-stopped
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - DEFAULT_MODEL=qwen2.5:3b
    ports:
      - "8000:8000"
    depends_on:
      - ollama

  agent-system:
    build: ./agents/system
    container_name: jarvis-agent-system
    restart: unless-stopped
    network_mode: host   # Needs access to host D-Bus / display

volumes:
  ollama_data:

For voice input, I'm using Faster-Whisper (or whisper.cpp for CPU-only) — push-to-talk on a hotkey. For output, Piper TTS — fast, local, and surprisingly natural Finnish voices available.

The pipeline: hotkey → Whisper → Ollama → function call or text → Piper TTS → speaker. Total latency target: under 1 second end-to-end.

Home Assistant has an Assist feature withwyoming-satellite and OpenAI-compatible endpoints. That's actually the longer-term plan — integrate as an Assist pipeline so it works with HA's voice push button.

But building the agents standalone first means they work independently of HA, and can be composed in other ways later. Modular by design.

qwen2.5:3b, test function calling with a Python script I'll post updates as the build progresses. The code will be on GitHub when it's worth sharing.

Building your own tools is the whole point of this site. If you're interested in self-hosted AI, the Ollama docs are a good starting point: ollama.com. And if you want something more polished out of the box, Home Assistant's Assist feature is worth exploring.

── more in #ai-agents 4 stories · sorted by recency
── more on @ollama 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/i-built-my-own-j-a-r…] indexed:0 read:5min 2026-11-14 · —