Veda: The First Agentic Hobby Operating System

Veda is an operating system with an AI agent built into it — not an assistant added to a desktop, but a part of the system that every application is made to work with. You talk to it the way you would talk to someone in the room — "Hey Veda, switch my wallpaper to the dunes" — and it does the work through the same operations as your keyboard and mouse, in any application, and asks you before anything that is hard to undo.

Everything is written from scratch in Rust and lives in this repository: the UEFI bootloader, a capability-based microkernel, the drivers, the system services, the window system, the toolkit and the applications. A few mature crates provide the TCP/IP engine, TLS and cryptography (smoltcp, rustls, RustCrypto). Veda runs on x86-64 PCs and in QEMU.

Operating systems were designed for a person at a keyboard. An assistant added to one later usually has to read the screen, imitate clicks or make do with the few applications that offer an API, and the system has no say in what it does. Veda turns this around: the agent is a first-class user of the system, and the system is built so that its work is reliable, visible and safe.

┌───────────────────────────────────────────────────────────────────────┐ │ You: voice, keyboard, mouse │ ├───────────────────────────────────┬───────────────────────────────────┤ │ Agent service │ Desktop shell │ │ conversation (Deepgram Voice │ the ring and the agent's window │ │ Agent) · name listener · memory │ consent requests · notifications │ │ worker: functions and consent │ │ ├───────────────────────────────────┴───────────────────────────────────┤ │ Applications: actions · state · invoke (the agentapp protocol) │ ├───────────────────────────────────────────────────────────────────────┤ │ Services: windows · files · audio · network · Wi-Fi · launcher │ ├───────────────────────────────────────────────────────────────────────┤ │ vkernel: capabilities · IPC · isolation · scheduling │ └───────────────────────────────────────────────────────────────────────┘

Listening. Asleep, the agent runs a voice detector on the computer. When someone speaks, the speech goes to a recogniser that knows the agent's name; a sentence that calls it ("Hey Veda, …", "…, Veda?") wakes it, and what was said with the name is the first thing it hears.

Conversation. Waking opens a Deepgram Voice Agent session with the agent's instructions, the context above and its functions. Deepgram takes care of turn-taking, the language model and the voice; Veda's audio service carries the sound both ways.

Action. The model calls the agent's own functions — windows, files, volume, Wi-Fi, wallpaper, notifications, timers and reminders, memory, the system and its running programs — and, through use_app and read_app, every application's actions and state. The agent service runs each call and answers with a structured result.

Consent. A call that needs your OK is held and shown in the agent's window (or as a notification while the window is closed), saying exactly what will happen and to what. Allow it and it runs; decline it, or let it expire, and it does not. Sensitive actions can be allowed for good; destructive ones are asked about every time.

The agent describes the design in full: the protocols, the voice pipeline, consent, memory and how the agent is tested.

Microkernel. vkernel only does isolation, scheduling, memory and IPC: capability handles with rights, channels that carry handles, VMOs, events, futexes, interrupt objects. SMP with x2APIC, tickless timers and XSAVE. Drivers, the file system, the window system and the agent are user-space processes, supervised by init: if the window system crashes, it is restarted and the desktop comes back on its own.

Desktop. A startup sequence that fades a splash in from a black screen once the display is up (a breathing light around the ring, the name and tagline rising in) and dissolves it into the desktop once that is ready, its startup sound starting with it; a compositing window manager with server-side decorations, shadows, animations, window snapping and an Alt+Tab switcher with live thumbnails, which composes on the GPU with OpenGL ES on PCs with Intel graphics, every frame flipped whole at the vertical blank, and on the processor elsewhere; a shell with wallpaper, desktop icons (the Trash first), a taskbar, a searchable start menu, a calendar and notifications; the vui toolkit (widgets, menus, dialogs, vector icons, anti-aliased text with the Inter and JetBrains Mono fonts), whose applications are agent-compatible.

Networking and Wi-Fi. A user-space network service (IPv4 and IPv6, DHCP, DNS, routing, TCP, UDP, ICMP) and a Wi-Fi service that scans, joins WPA2, WPA3 and open networks with management frame protection, remembers networks, reconnects and roams on its own. The drivers, Linux's in the driver VM, only move frames and join the networks the Wi-Fi service chooses. Applications, the agent among them, get TLS 1.3 and 1.2 (HTTPS, secure WebSockets) from vtls, with certificates checked against the Mozilla roots. Under QEMU a simulated Wi-Fi environment provides access points bridged to the Internet. See Networking.

Audio. A mixing audio service with echo-cancelled capture and ducking, built for the agent's conversations as much as for music.

Linux's drivers, in a virtual machine. Veda drives its disks itself (and sound, for now), and takes the rest from Linux, which it runs in a virtual machine, the driver VM, on a hypervisor of its own (VMX with EPT, a paravirtual platform with no emulated hardware). Devices go to it whole, their DMA confined to its memory and their interrupts remapped by Veda's IOMMU driver, and its programs reach Veda's services through Veda's own system calls, carried across. Linux's drivers there serve Veda's keyboards, mice and tablets, USB, wired and Wi-Fi networks, displays and GPUs; when the VM fails, Veda resets its devices and starts it again. See the driver VM.

Storage. virtio-blk, AHCI (SATA) and NVMe drivers and a file system service that keeps the home directory on its own disk with crash-safe snapshots, so your files survive restarts. The agent's memory and key live in a private directory that only the agent can open.

Applications. Text Editor, Photos, Music, Files, Terminal, Task Manager, Settings and About, and two 3D games, Velocity (racing) and Starfall (a space shooter), rendered by the v3d software 3D engine.

3D graphics. OpenGL ES 3.0 with GLSL ES 1.00 and 3.00 (vgl, vglsl), every call checked as the specification requires. It renders on the GPU through Veda's renderer in the driver VM, on Mesa's driver of the GPU over Linux's (Intel's iris; under QEMU, virgl on the host's GPU), or with a multi-threaded software renderer where there is none. Prism shows it off: a reflective knot, shadow-mapped crystals drawn with instancing, and a fountain of sparks simulated with transform feedback, at 75 frames a second under QEMU.

C, and GCC inside Veda. Write a C program in the Terminal or the Text Editor, compile it with GCC 16 and run it, in an emulator or on a PC alike. C programs are static ELF executables on the musl C library, whose system calls go to vposix, a POSIX layer written in Rust: files, directories, pipes, a terminal with line editing and termios, threads, mmap, posix_spawn, clocks and signals they raise themselves. The toolchain is built from the upstream releases with small patches (ports/), and a cross compiler builds C and C++ programs for Veda on the development machine. See C on Veda.

Tooling. One command builds a bootable disk image and runs it in QEMU; scripted, headless runs drive the GUI and the agent and check screenshots and logs.

Screenshots

Text Editor Photos

Music Files

Velocity Starfall

GCC in the Terminal Prism (OpenGL ES 3.0)

All screenshots are taken in QEMU by cargo xtask script docs/screenshots.vts (the agent talking to the stand-in for Deepgram).

Requirements

Veda is built on an x64 PC with Linux.

cargo xtask doctor

Build and run

cargo xtask run

This builds every component, writes the disk image target/veda/veda.img and boots it in a QEMU window. The first build also builds the driver VM's Linux (its kernel, a cross compiler for its programs, and Mesa), which takes a while, and renders the sample pictures and music; later builds are incremental, and cargo xtask linux builds Linux again after its port changes. Useful options:

cargo xtask run --resolution 1920x1080 --smp 4 --memory 2048 cargo xtask run --cmdline "run=editor"

--cmdline "run=NAME" starts /system/bin/NAME.exe after boot. The machine is on QEMU's NAT through a wired card by default; for Wi-Fi:

cargo xtask run --net wifi

This also starts airsim, a simulated Wi-Fi environment whose networks ("Veda Home", "Veda WPA3", ...; password veda-wifi) lead to the Internet. --net both adds the wired card. See cargo xtask help for all commands and options.

cargo xtask iso

writes target/veda/veda.iso, a live system. Write it to a USB stick with Rufus (partition scheme GPT, target system UEFI, ISO mode), or as it is with any image writer, and start the PC from the stick (usually from the firmware's boot menu: F12, F11 or Esc at power-on) in UEFI mode with Secure Boot off, as Veda's loader is not signed. Veda runs from memory and leaves the PC alone: no disk driver starts, so it never reads or writes the PC's disks or the systems installed on them, and its home directory lasts until the PC is turned off. The stick keeps the system's log of each start, in VEDA/LOGS (the newest start's in the directory with the highest number: VEDA.TXT, Veda's log, and LINUX.TXT, the driver VM's Linux's), synced every second: whatever happened, even with nothing on the screen, can be read on any computer afterwards. To try the stick in QEMU first:

cargo xtask run --live

On real hardware the desktop appears in the screen mode the firmware provides (1920x1080, or the largest below it), drawn into the firmware's framebuffer; with the driver VM, Linux's display driver shows every frame whole, flipped at the screen's vertical blank, so animations run as smoothly as in a virtual machine. The driver VM needs the processor's virtualization (VT-x), and its devices the IOMMU (VT-d), which PCs of the last decade have, turned on in the firmware's settings: without them, Veda drives only the disks (with VT-x alone, PS/2 keyboards and mice too). Through it, USB keyboards, mice and hubs work on the USB 3 (xHCI) controllers that PCs have had since about 2012, as do PS/2 keyboards, mice and touchpads, USB network adapters, and Intel's and Realtek's Ethernet cards and Intel's Wi-Fi cards; USB disks, the stick included, are left alone. Sound plays through Linux's drivers too: HD Audio, the sound hardware of nearly every PC since 2005, through the speakers (a laptop's amplifiers among them: Cirrus Logic's CS35L41, with the calibration the firmware keeps for them), or the headphones when they are plugged in, and the line outputs, with the microphone on the codec (built in, or on a jack) for the agent. Built-in microphones wired to an audio DSP rather than to the codec, as in many recent laptops, are recorded through Linux's Sound Open Firmware on Intel's PCs from Tiger Lake to Raptor Lake (11th to 13th generation Core); later ones' stay silent for now. Intel's integrated graphics are Linux's too (i915, with Mesa's iris for the GPU), and HDMI and DisplayPort audio with them. To try USB input or HD Audio in QEMU:

cargo xtask run --input usb cargo xtask run --sound hda

Talking to Veda

Open Settings → Agent and add your Deepgram API key. The agent's name, voice, language model, listening and memory are on the same page.

Say "Hey Veda", click the small ring at the right of the taskbar or press Super+Space.

Talk naturally, ask follow-up questions, interrupt whenever you like, and say goodbye when you are done. It goes back to sleep and listens for its name.

Veda hears you through your PC's micropho