Stop picturing a chatbot. Atlas — the system I've been building since mid-February, now v3.1.0, running 24/7 on a free Oracle Cloud ARM VPS — is architected like an operating system. It has a kernel, system calls, a scheduler, virtual memory with garbage collection, a capability-based permission model, device drivers, a boot sequence, and a dmesg. The only unusual component is the processor: it's a language model.
Once you see it that way, every design decision reads differently. This is the tour, subsystem by subsystem.
Prefer video? Here's the 2-minute explainer:
The kernel
Every message, text, photo, document, voice note — enters one pipeline: rate limiter, guardrails, a small classifier that routes it into one of six paths, then the orchestrator's tool-use loop (max 10 iterations, 20 tool calls). That loop is the kernel's main loop. It never does work itself; it dispatches.
The classifier is worth naming because it's the cheapest important decision in the system: a tiny Groq model at temperature 0 decides whether a message needs the paid model at all. Casual chat never touches one. In OS terms, it's the interrupt dispatcher — fast, dumb, and correct enough that everything expensive happens behind it.
One turn at a time across all interfaces, enforced by a Postgres advisory lock. A mutex, shared between the Telegram, voice, and dashboard processes.
System calls
The 116 tools are syscalls. User space (the model) can't touch the world directly — it traps into the kernel, which executes the call and returns the result. The 15 MCP servers are driver modules: mail, calendar, jobs, memory, vault, shell, web — each owning its domain, each failure-contained.
Two optimizations keep 116 syscalls affordable, and both have OS analogues:
- Two-tier syscall table. The model always sees name + ~80-char description + parameter types (~15 tokens per call). Full schemas expand only for calls already made — like keeping the hot path of the syscall table in cache. ~85% off.
- Per-route syscall filtering. Each dispatch path sees only the calls it needs. Another 40–60% off.
After heavy turns, a background pass compresses the trajectory into a ≤150-word summary, the equivalent of compacting the kernel log so the next boot stays fast. Measured ~69% token reduction.
Permissions
This is the subsystem I care about most, because an OS that runs your life needs a real security model.
Five tiers: read, write, sensitive, critical, nuclear. Think Unix permissions crossed with capabilities(7), except the top two tiers require interactive authentication: the kernel sends a one-time token to my phone, and the call executes only after I reply confirm tool <TOKEN>. Nuclear actions are capped at one per hour. It's sudo with a 30-minute expiry and a paper trail.
External content is untrusted input, structurally. Anything arriving from a document, image, email, or web page is data — it can never trigger a write-tier syscall without my approval. That's the prompt-injection defense, enforced by the gateway, not by asking the model to be careful.
No shell where the model can reach. Everywhere a message could touch a command executes shell-free; the shell tool accepts only flags and plain words. The sandbox where Atlas builds its own tools gets credentials injected at the network layer — the container never sees a raw secret, the way a process never sees the kernel's keyring.
A September audit registered 43 defects against this model. All fixed, deployed, and verified live within 24 hours. The register is permanent: every entry names the defect, the fix, and the command that proves whether it's still alive.
The 60-second demo of the guard in action — one message, three jobs, asked before saving:
Memory management
Three retrieval paths fused with reciprocal-rank fusion: vector search (local embeddings into pgvector), full-text search (for the exact names and dates vectors fumble), and message history search. Virtual memory with three page tables.
Then the parts that make it feel like memory instead of storage:
- Contextual retrieval — a small model writes a 1–2 sentence context summary for every fact before embedding, so "the meeting" resolves to the right meeting. Like tagging pages with their address space.
- The gardener — a nightly garbage collector. Prunes low-importance facts, merges duplicates, archives everything it deletes first. Nothing is freed without a backup.
- The dreaming pass — weekly offline maintenance. Distills new facts and behavioral patterns from the week's conversations. fsck for the mind.
The lesson it taught me: retrieval quality is 90% of whether the system feels intelligent. The CPU barely matters if memory hands it the wrong pages.
The scheduler
Cron jobs as the OS scheduler: job-board scans, email reading, tracker syncs, the morning briefing — all in UAE time, each with a 15-minute timeout, missed ticks caught up for 15 minutes max. Twelve enabled jobs, all verified firing on schedule.
On top of that, an agent layer for complex work: a Queen process spawning parallel workers per domain (finance, career, health, research, memory, scheduling, email, docs), each with only its own syscalls — process isolation by construction. Workers must state assumptions instead of inventing facts and report with explicit "Not done" and "Open questions" sections. A planner decomposes, a supervisor executes with parallel steps, a verifier re-checks results, and a self-improving agent captures my corrections into future runs.
There's even a weekly AutoML loop rewriting the job-scorer's training code — kept only if error improves ≥1%, otherwise code and artifacts revert. The OS tunes its own scheduler heuristics.
Fault tolerance
DeepSeek → Groq → Gemma → Qwen, with automatic cooldowns and climb-back. When the main provider fails, the system degrades to free local models instead of dying — redundant hardware, except the hardware is models. Per-role routing lets each subsystem (main, voice, workers, vision) fail over independently.
Circuit breakers on every syscall: consecutive failures trip the breaker, a half-open probe closes it only on a genuinely successful call, and the router escalates around tools whose reliability score drops. The kernel watches its own drivers fail and routes around them.
Power management
Under $5/month isn't achieved with cheap models — it's achieved by not spending cycles:
| Technique | Effect |
|---|---|
| Free-tier Groq for chat, routing, tool-free reasoning | $0 for most messages |
| Main role on DeepSeek, not Claude | Paid tokens at a fraction of the price |
| Two-tier syscall table + per-route filtering | ~85%, then ~40–60% off |
| Trajectory compaction | ~69% off heavy turns |
| Prompt caching | Cache reads at 0.1× |
| Local embeddings | $0 |
Measured: $0 for chat, ~$0.015 for a DeepSeek turn with tools, ~$0.09 for a full job analysis. Recent 30-day windows: ~$2.45–$2.57. Lifetime since February: $24.71.
And since this month, the meter is honest: every API call writes one row — provider, model, tokens, cost, latency. A $5 weekly hard limit moves paid calls to free Groq past the threshold, with a visible note on every affected reply. Never silent — a design decision.
Device drivers
Telegram, the dashboard, voice (English, Urdu, Punjabi — transcribed in the language spoken), and now a device fabric: per-device tokens over a private network, one-time-code pairing, a decision log of every allow and refusal. Drivers for bodies; one kernel. The current focus is the laptop as the first full device.
Boot is warmMCP() — all driver modules probed in parallel at startup, graceful degradation for anything that doesn't answer. PM2 is init. The JSON logs plus a 33-gauge Grafana dashboard are dmesg.
The engineering culture (why I trust it)
Nine months ago I measured progress in features. Now:
- Nothing closes until seen working live. I run every verification myself. 88 open, 98 closed in the register.
- Tests first, shown failing. 1,191 across 74 files, isolated so they can never touch production. (One test reaching the real vault and locking it is why.)
- Compute it or delete it. An audit found the system's own reports printing numbers nobody computed — a model-written "Reliability: 20%", a pressure alert multiplying by a constant. Now a number is either computed from rows with its window named, or it isn't printed. Four vanity metrics were retired.
- Docs audited against the code, citing files and symbols, with the command that produces any countable claim instead of the number. Numbers decay; commands don't.
February me built a chatbot with tools. The OS taught me to run it like infrastructure.
Known bugs (dmesg doesn't lie)
- Found this week: past the $5 limit, the moved-to-Groq turn ran without syscalls and once promised to check my calendar without doing it. The visible-note mechanism caught it; fix in progress.
- Routing is the weakest link. A complex dispatch once misrouted into the email worker and never completed. Mitigated, not solved.
- The whole auth model reduces to Telegram account security. One messaging account holds every approval. Named plainly.
- It's a second job. The gardener, the dreaming pass, the nightly reflection are maintenance-avoidance mechanisms — which tells you the maintenance load is real.
What's next
The laptop as the first full device body. DeepSeek per-role characterization before anything else moves. Scheduled jobs onto local models, one verified at a time. Standing priority since July: fewer new syscalls, more proof the existing ones deserve trust.
It started in February as frustration with assistants that forgot everything and couldn't act. It became an operating system — kernel, syscalls, scheduler, memory management, permissions, drivers — that happens to run on a language model. That's the interesting part. Not the AI. The OS.
Not the MongoDB one.
I write about building in public: personal AI systems, Rust forensics tooling, and open-source devtools. More at fahadbilal.com.
Top comments (0)