Dev Log #0: A look inside GSV — GSV Blog

← all posts

GSV has an ambitious goal. Personal intelligence systems have been attempted before, so we have big shoes to fill.

GSV offers a wide range of features that may appeal to different people for different reasons. Here I'll describe how those features work, and how GSV is implemented from the code and architecture point of view, for the technically inclined.

First Came the Cloud Computer

The first contact you'll have with GSV is the "cloud computer ." It's not a computer in the traditional sense where you buy some hardware, like a laptop, and then use macOS, Linux, or Windows on it.

This is a virtual computer that runs on top of workerd , Cloudflare's open source JS and WASM runtime that powers its entire developer platform. Both GSV and workerd are engineered to use few resources. To get a rough idea, each worker instance is single threaded and has only 128MB available.

We use "cloud computer" not because it runs on a cloud platform, but because it's globally reachable. When you deploy GSV, you get your own public address on the internet from where you can access your computer. You'll complete an onboarding and, once setup, the instance will lock down and only allow access to your credentials.

While this computer has a file system (R2), can run scripts , and can execute code (Dynamic Workers), it is not made for heavy computation. Instead, it acts as a hub for all your machines to connect to and route messages through, bookkeeping for where's what and who's who, storing configuration settings, and managing any agent loops currently running on it.

workerd 's Durable Objects are a great fit for this, since they can act as hibernatable WebSocket servers with embedded SQLite databases. The singleton DO at the core of the cloud computer, the one that manages everything, is called the Kernel.

Architecture sketch of a personal GSV.<br>The Kernel

The Kernel is always aware of everything happening in the cloud computer.

The user is trying to log in? The Kernel checks its database records to authenticate them.

Request to start a new agent? The Kernel spawns a new process, which is also a specialized DO , to run the agent loop and handle routing of events and messages to connected clients and machines.

A user or agent is trying to open /foo/bar.txt? The Kernel compares the capabilities of the account with the file permissions of /foo/bar.txt and decides whether to allow or deny it.

Everything goes through the Kernel.

It is clearly different from the Linux kernel, but they do share some similarities. Every primitive action in GSV is backed by a system call . They define what the action does and the shape of its arguments and return types. For example:

fs.read: reads a file. Expects path: string and returns content: string | Blob.

shell.exec: runs a command in the available shell. Expects cmd: string, cwd?: string and returns stdout?: string, stderr?: string, exitcode: number.

net.fetch: makes an HTTP fetch request. Expects and returns similar shapes to JavaScript's fetch.

And many more.

Like the Linux kernel, users are also at the core. Whether they're human accounts or agent accounts owned by one or more human users, capabilities define which syscalls each can use, therefore gating their capabilities and shaping our security model.

Speaking of Agents

The whole point of our personal intelligence stack is to integrate the fluid intelligence of the latest AI models into our digital lives without giving the keys of the kingdom to a third party.

Of course, the Kernel has AI built in:

Inference: whether you want to use third party providers, a ChatGPT subscription, or your own local AI server, the Kernel handles it. Anyone and anything in the system with the right permissions can request the Kernel to run AI inference.

Agents: if inference gives us intelligence, the agent loop gives us liquid intelligence. The Kernel processes are not programs, but agents. When you start a new conversation with an agent, you'll see it in the system as a new process busy with work. If your agent spawns five subagents, you'll see five subprocesses doing work.

Agents can be quite restricted in their capabilities, so their user has the option to either review and approve all their actions or give them full access to work on their own, without supervision. Regardless of permissions, agents are capable of performing the same actions a user can. This represents the user's entry point to fluid intelligence: you can speak natural language and see your words manifest in the digital space.

One reason we decided to shape the cloud computer as similarly to Unix as we could is that LLMs have seen hundreds of millions of tokens of Unix/Linux writing, docs, and source code during training. Therefore, as long as the computer behaves similarly to those systems, we get to cut a lot of instruction context about the runtime.

This is interesting, but it's very limiting to only run this...