Veda: The First Agentic Hobby Operating System

Veda: The Agentic-Native 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. Why agentic-native 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. The agent is part of the system. It is a system service, started at boot and restarted if it fails, present as a small ring on the taskbar and asleep until you call it — by its name, with a click on the ring or with Super+Space. Every application speaks to it natively. Agent support is part of the application platform: an application describes its actions, with typed parameters and a risk level, reports what it shows as structured state, and carries out actions through the same code as the keyboard and mouse — so the window shows the result exactly as if you had done it. No screen scraping, no simulated clicks. The built-in applications offer more than 70 actions between them, from writing in a document to starting a race. The system holds the agent to your consent. Every action is routine, sensitive or destructive. Routine actions just happen; the others wait for your OK. The agent service enforces this, not the language model: the call is held until you answer, only the desktop shell can answer (the system knows each program by the identity init attaches to its connections), and nothing the agent reads in a document or an application can approve anything. It works from real context. Every conversation starts with what the agent needs to help: the time, the windows on the screen, every application's actions, what you have told it about yourself and how your last conversation ended. While it works it reads the applications' state, so it acts on what is really there. Your memory stays yours. It remembers what you tell it plainly — your name, the people in your life, how you like things done — never its own guesses. That memory is kept on your computer, and Settings shows all of it and forgets any of it. Voice comes first. Conversations happen in real time: interrupt the agent and it stops and listens. The audio system is built for it — echo cancellation and an echo gate so that the agent never hears itself, and other sound turned down while it talks with you. While it sleeps, a voice detector on the computer listens for speech, so that nothing leaves the computer while nobody speaks. The intelligence is a setting. Speech recognition, the language model and the voice come from Deepgram's Voice Agent platform, with the audio opted out of Deepgram's model improvement; the model, the voice and even the agent's name are chosen in Settings. How the agent works ┌───────────────────────────────────────────────────────────────────────┐ │ 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. The operating system 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 All screenshots are taken in QEMU by cargo xtask script docs/screenshots.vts (the agent talking to the stand-in for Deepgram). Quick start Requirements Veda is built on an x64 PC with Linux. Rust (stable). rust-toolchain.toml makes rustup install the extra targets on first use. The user-space programs are PE executables, which LLVM's linker that comes with Rust (rust-lld) links. QEMU and the OVMF UEFI firmware: the distribution's packages (on Debian and Ubuntu qemu-system-x86, qemu-system-gui, qemu-system-modules-opengl and ovmf), and access to /dev/kvm (members of the kvm group have it), with which QEMU runs Veda on the processor's hardware virtualization. For the agent: a Deepgram API key, entered in Veda's Settings. For C and GCC in the image (optional): the distribution's build tools, for the toolchain cargo xtask toolchain builds once (see C on Veda). For the driver VM, whose Linux drives every device but the disks and sound: the Linux kernel's build tools, and the distribution's build tools for a cross compiler and Mesa, for cargo xtask linux, and KVM's nested virtualization (kvm_intel nested=1), on which QEMU gives Veda the processor's VMX (see the driver VM). Check the environment: 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. A real PC, from a USB stick 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 microphone and answers through its speakers, under QEMU too. Things to ask: "Switch my wallpaper to the dunes." "Play Neon Horizon." "Write a shopping list with eggs, milk and coffee." "Show me the lighthouse photo, full screen." "Remind me to stretch in twenty minutes." "What's using the most memory?" "Start a race in Velocity." "Delete the City Lights photo" — and see it ask you first. "What do you know about me?" Using the desktop Click the logo (the ring in the middle of the taskbar) or tap the Super key for the start menu; type to search for an application. Click a taskbar button to open, focus or minimise an application; middle-click opens another window. Click the clock for the calendar. Double-click desktop icons. Right-click the desktop to change the wallpaper. What you delete goes to the Trash, the first icon on the desktop: open it to restore items where they were, or to empty it. Drag items of the desktop onto it, or press Delete in Files (Ctrl+Z puts them back; Shift+Delete deletes for good). Drag a window to the top of the screen to maximise it, or to a side to fill that half (or use Super+Left/Right/Up/Down). Super+D shows the desktop, Alt+Tab switches windows and Alt+F4 closes the active one. The speaker icon on the taskbar opens the volume control (scroll over it to change the volume). The network icon next to it shows the Wi-Fi signal and opens the list of networks to join. Your files live in /home/user, kept on target/veda/home.img across restarts and rebuilds (--fresh-home starts over). Applications Every application is agent-compatible: what you can do with the mouse and keyboard, the agent can do too, through the application's own actions. The games are drawn by v3d, a multi-threaded fixed-point software 3D renderer, and Prism by OpenGL ES. Beyond the applications, the agent's own functions cover windows, files, sound, Wi-Fi, the wallpaper, notifications, timers and reminders, its memory and the system. Building agent-compatible applications Agent support is part of the vui application platform. An application describes what it can do, reports what it shows and performs actions; vui::run registers it with the agent service and answers the agent between frames: use vui::agent::{self, Action, AppAgentInfo, Risk, Value, arg_path, arg_str, object, show_path}; impl vui::App for Notes { fn update(&mut self, ui: &mut vui::Ui) { /* ... */ } fn agent_info(&self) -> Option { Some(agent::info( "A notes app: one note per file in ~/Notes.", vec![ Action::new("add_line", "Adds a line at the end of the note shown") .param("text", "string", "The line", true) .build(), Action::new("delete_note", "Deletes a note for good") .param("path", "string", "The note's file, such as ~/Notes/Ideas.txt", true) .risk(Risk::Destructive) .build(), ], )) } fn agent_state(&self) -> Value { object! { "note" => self.title.as_str(), "lines" => self.lines.len() } } fn agent_invoke(&mut self, action: &str, args: &Value) -> Result { match action { "add_line" => { self.append(arg_str(args, "text")?); Ok(object! { "lines" => self.lines.len() }) } "delete_note" => { let path = arg_path(args, "path")?; self.delete(&path).map_err(|e| format!("{} could not be deleted: {e}", show_path(&path)))?; Ok(object! { "deleted" => show_path(&path) }) } other => Err(format!("Notes has no action called {other}")), } } } Actions are written for a language model (short imperative descriptions, units and defaults spelled out), declare their risk, name their targets explicitly and go through the same code as the keyboard and mouse. The consent, the memory and the conversation are the system's job, not the application's. See Making an application agent-compatible. Testing cargo xtask test runs the host unit tests of the libraries (the agent's protocol, tools, prompt, memory, wake word and echo gate, the kernel ABI, heap, IPC, service protocols, math, rasterizer, fonts, image codecs, 2D graphics, text editing, paths and file types, audio, ELF loading, the POSIX layer, build tool) and then boots Veda headless with the systest integration tests (IPC, sockets, memory, threads, file system, launcher, crash reports, recovery of the window system after it is killed, and C programs that check the C library and the POSIX layer), failing on any panic. The agent is tested end to end against a stand-in for Deepgram that runs on the host (tests/agent/): conversations, function calls, interruptions, echo, consent in the window and in notifications, waking by name over music, every application's actions and restarts — deterministic, offline and free. tests/real/agent-*.vts talk to the real Deepgram with the key in DEEPGRAM_API_KEY, with a synthetic voice speaking into a virtual microphone. Networking has its own host tests (the 802.11 protocol and cryptography against published test vectors, station against access point, TCP/IP stacks over a simulated cable, the Wi-Fi simulator, TLS handshakes against a rustls server and real certificate chains), and nettest checks DNS, TCP, HTTP, HTTPS and ping from inside Veda. GUI automation scripts in tests/ui/ click through the desktop and applications, check the log and save screenshots; two of them run C programs in the Terminal and compile one with GCC inside Veda (they need the toolchain, and are skipped without it). The Wi-Fi scripts join networks through the desktop and break the simulated network in many ways (access point gone, disconnection, outages, the radio or the Wi-Fi service vanishing) to check that Veda recovers by itself. Run them all, the agent's included, with the unit and integration tests, or one at a time: cargo xtask test --ui cargo xtask script tests/agent/wake-name.vts cargo xtask shot --wait 20 (shot boots headless and saves target/veda/screen.png.) The serial console (kernel log plus every program's output) is saved to target/veda/serial.log. Repository layout Documentation The agent: the voice agent, its functions, consent and memory, and how applications become agent-compatible. Architecture: how the system fits together. Networking: the network and Wi-Fi services, the simulated Wi-Fi environment, security and tests. C on Veda: writing, compiling and running C programs, the POSIX layer, and how the toolchain is built. The driver VM: Linux's drivers in a virtual machine: the hypervisor, the platform, the bridge, the IOMMU and the devices. Developing: build commands, the system image, writing applications, performance notes. Coding conventions. License Copyright © 2026 Vahid Mohammadi. Veda is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License, version 3, as published by the Free Software Foundation (see LICENSE). It is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The bundled fonts (Inter, Lato, JetBrains Mono) are under the SIL Open Font License 1.1; see assets/fonts/. The firmware the driver VM's Linux loads into devices (ports/linux/firmware.txt) comes unmodified from the Linux firmware collection, under the terms its WHENCE gives each file's maker (who allow its redistribution), and from Sound Open Firmware's releases (sof-bin: Intel's signed builds of the audio DSP's firmware, under the BSD licence and Intel's patent licence of its LICENCE.Intel); it runs on the devices, not in Veda. Vendored third-party code keeps its own license; see third_party/. The C toolchain an image may contain keeps its own licences too: GCC and binutils GPL version 3 or later (the GCC runtime library with its Runtime Library Exception, so programs GCC builds keep their own licences), GMP, MPFR and MPC LGPL version 3 or later, musl MIT; their source is the upstream releases ports/*/port.toml names, with the patches beside them.