Nexo: an agentic operating system

The problem

“Agentic OS” is a trendy label, but it usually describes an app with a chatbot. I wanted to build the genuinely hard part: a layer that coordinates, manages and governs several agents so they work autonomously, collaboratively and continuously, without losing control. And I wanted to use it for something real: my own computer, which piles up downloads, caches, half-finished projects and pending updates.

What I built

• A kernel with operating-system parts. Every agent run is a process with a lifecycle; a scheduler wakes agents on their schedule and at login; a supervisor retries what fails and stops what runs too long; and everything lands in an append-only log.
• Six agents that check disk space and downloads, caches, git projects, Ubuntu and Windows updates, security (antivirus, firewall, exposed ports and secrets in repositories) and hardware health (battery, GPU and memory).
• An approval queue. Agents only propose concrete changes; nothing runs without my approval, approved changes go to a quarantine that can be undone for 30 days, and rejected ones are not proposed again for a month.
• A desktop app (Tauri and React) that starts with Windows, boots the kernel in WSL if it is not running, sends a notification and lives in the system tray.
• A local assistant (Ollama with Qwen 3.5 on the GPU) with conversations that remember what we talked about, which I can ask in Spanish what is going on with the PC. Nothing leaves the computer.
• Live transparency: running an agent shows its steps, what it found and what changed since the previous check; the Nexo logo animates according to what it is doing. The interface went through a full design review: urgent things first, the file name before the action, and color only where it matters.

Key decisions

• Capabilities, not a shell. Each agent declares which tools it may use and the kernel denies everything else. Tools carry a risk level: reading is free; changing the PC goes through the approval queue, and every path is checked again at execution time.
• Privacy enforced by the tools. Photos and university documents are forbidden zones; no agent can read them, not even to measure their size.
• Durability tested, not assumed. The first version used PGlite and a Windows restart corrupted the database. I switched to SQLite in WAL mode and added a test that kills the process in the middle of thousands of writes: the database always reopens healthy.
• A model that cannot do harm. Its output is constrained by a schema to four intents and none of them approves or deletes, so a file that “gives orders” is just data. Figures are computed by the code, and the summary is checked number by number before it is shown.
• A summary that never contradicts the numbers. While reviewing the app’s design I found the model’s summary said 25.6 GB while the report said 24.8: it was written only at login while the agents kept working. Now it is rewritten as soon as an agent finishes or I decide on a proposal.
• Choosing with data. I built an evaluation with expected answers: the 4B model scored 8 out of 8 in 1.5 seconds and beat the 9B one, so I kept the smaller model.
• A hardened local API. The app talks to the kernel with a secret token, Host header validation against DNS rebinding and CORS for the app only; the native Rust side runs fixed commands only.

Outcome

In daily use on my PC. On its first day it helped me free about 64 GB through approvals that can be undone, without a single error, and the security agent caught a database exposed to the network. It has 61 tests in the kernel, 14 in the app, continuous integration and a 2.4 MB Windows installer.