DEV Community

floworkos
floworkos

Posted on

Building a Self-Hosting AI Agent OS: Flowork's Microkernel Architecture with WASM Sandboxing and Frozen Core Design

The rise of AI agents brings a painful contradiction: they work best when they learn from past interactions, yet most cloud-hosted solutions reset your context with every session. You don't own the data. You don't own the logic. You're renting cognitive cycles from a vendor.

Flowork Agent flips this model. It is a self-hosted microkernel operating system designed to run sovereign AI agents on your own hardware—with a persistent memory they build over time, a security conscience baked into the kernel, and zero vendor lock-in.

The Core Insight: Microkernel Architecture

At the heart of Flowork lies a deliberately frozen design philosophy: the microkernel is written once and never edited again. Every capability—thinking, remembering, running tools, sending messages—flows through a single contract called the loket (the counter). Modules ask the kernel for capabilities by name: call(cap, args). The kernel checks the grant, routes to a provider, enforces isolation, and returns the result.

This constraint is intentional. It forces radical modularity. When an agent breaks, you fix its folder. When a tool fails, you patch that tool. The kernel itself—the forever code—remains untouched. This is the opposite of monolithic systems where one bad update cascades through everything.

The kernel is written in Go 1.25, compiled to a single static binary with no cgo dependencies, no Docker, no runtime to install. Deploy it on Linux, macOS, or Windows with one command. That binary contains not just the kernel but also the embedded web UI, eliminating the need to host a separate frontend.

Sandboxing via WebAssembly: Agents as Isolated Citizens

Every AI agent runs as a sandboxed WebAssembly module using wazero, a pure-Go WASM runtime. This is not a performance optimization; it is a security boundary. Each agent executes in its own sealed environment, unable to read the filesystem, spawn processes, or call system functions unless explicitly granted via a capability.

When an agent requests call("tool.run", {name: "list_files", args: ...}), the kernel checks its grant list. If that agent lacks the files capability, the call is rejected. If it has the capability, the kernel routes the request to the file provider and returns a sandboxed result.

This design prevents a hallucinating agent from corrupting shared state, and it prevents a compromised agent from pivoting to other agents or the host system. Each agent is a citizen with a passport; the loket is the border.

Memory: SQLite with Full-Text Search

Every agent gets its own private SQLite database with FTS5 (full-text search) enabled. This is the agent's brain. When an agent learns something—a fact it retrieved, a correction to a previous error, a tool it successfully used—it writes to its brain. When facing a new problem, it queries its brain: Have I seen something like this before?

This is not just caching. It is learning from its own mistakes at runtime. An agent that misclassifies a stock symbol stores the correction; the next time it encounters similar input, it recalls the lesson. The brain persists across sessions. Turn off the machine, turn it back on, and the agent remembers.

In practice, this makes the agent noticeably more accurate and coherent over days and weeks of use. It develops a personality, a style, and a set of learned blindspots.

Bidirectional MCP: Opening the Loket to the Outside

Flowork implements the Model Context Protocol (MCP) in both directions:

  • As a client: An agent can call external MCP servers (GitHub API, filesystem tools, web search) by name. The kernel brokers these calls.
  • As a server: External tools—Claude Desktop, Cursor, other agents—can call your Flowork agents as MCP tools.

This creates a bridge. You can equip agents with powerful third-party capabilities without embedding them in the code. And you can share agents with colleagues via MCP without sharing source code.

Capability-Based Security: The Guardian's Radar

Flowork includes a self-protecting kernel. A component called the Guardian watches for tampering. If any part of the core code is modified, the kernel detects it and drops into safe-mode—continuing to serve requests but refusing to load untrusted modules.

Beyond detection, Flowork ships with a security scanner—a real arsenal of static analysis tools that examine the code your agents are about to run. This is not a theoretical idea; it is a working scanner that looks for injection vectors, privilege escalation, and unsafe patterns.

No other AI agent framework includes this. Most assume the agent code is trustworthy. Flowork assumes it might not be.

The Plugin Architecture: One Fixed ABI

The project map reveals the structure:

  • main.go + internal/kernel/: The frozen microkernel and HTTP handlers.
  • internal/loket/: The single counter all modules call through.
  • internal/guardian/ + internal/protector/: Tamper detection and safe-mode.
  • internal/floworkdb/ + internal/agentdb/: Global state and per-agent brains.
  • agents/: Installed agents (each a .fwagent folder with its own SQLite database).
  • apps/: Sandboxed applications (flowalpha, notepad).
  • Everything else: Tools, slash commands, scanners, channels, MCP connectors—all plug-and-play.

When you add an agent or tool, you drop a folder into the appropriate directory. The kernel hot-loads it. No recompilation. No kernel restart. This is the promise of microkernel design delivered in practice.

Self-Hosting Trade-offs

Running everything locally eliminates cloud dependency, but it trades bandwidth and processing power for privacy and control. An agent on your machine is as fast as your CPU and internet are good. For LLM inference, Flowork delegates to local models (via routers to Ollama, LM Studio, or cloud APIs) rather than embedding inference in the binary.

The SQLite brain is optimized for recall and full-text search, not for distributed training or cross-agent learning. If you need agents to learn from each other, they do it through message buses and the loket, not through shared memory.

Conclusion: Own Your AI

Flowork Agent is an operating system for agents, not just a framework. It gives you the ownership that cloud AI lacks—persistent memory, local execution, capability-based security, and a frozen core you can trust. The microkernel design ensures that adding features never breaks the foundation. The WASM sandbox ensures that agents cannot harm each other or the host. The SQLite brain ensures that learning persists.

Deploy the single binary. Start the shell script. Open the web UI. Everything you need is running on your machine, owned by you, locked by no vendor, and ready to remember.


Flowork is open source — both products:

Top comments (0)