Dev Log #0: A look inside GSV

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 set up, 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.

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 specialised 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 in a virtual computer on some edge runtime, right?

Machines: Your Digital Everything

It's pretty nuts to think that 20 years ago, close to no one owned a phone. Fast forward to today and over 80% of the global population does, with 95%+ in high income countries.

Smartphones became the first digital extension of ourselves. Yet we kept going, and our digital lives are now scattered across devices: your phone, your laptop, your browser, your old desktop where you still keep some pictures, and so on. True personal intelligence is able to interact with all of them at the same time, just like a human, but without the hassle.

This is the pinnacle of GSV: your machines should be part of your personal intelligence stack, seamlessly and privately. You and your agents should be able to access your laptop and your server back at home.

Your GSV has a public address that your machines can connect to. They establish a private long-lived WebSocket connection with the Kernel and report what capabilities they support so the Kernel can register them for future use.

By default, a device that runs gsv device run will implement:

• fs.*: full file system capabilities. Read, write, edit, delete, search.
• shell.exec: command execution on whatever shell the device runs on.
• net.fetch: HTTP requests made from the machine instead of from the cloud, which can help avoid restrictions or blockages.

This is useful for both humans and agents. A user can read and edit files from the web UI regardless of whether they're on the cloud computer or on a physical machine connected to it.

For agents, it's even more interesting.

What Agents See

GSV takes a Unix approach and always exposes the same fixed set of tools to agents.

• Read, Write, Edit, Delete, Search: tool wrappers around the fs.* syscalls.
• Shell: the wrapper around the shell.exec syscall.
• CodeMode: a tool to execute JS, allowing programmatic access to any syscall.

That's it. We don't grow the tool list any further than that. It doesn't matter if you connect 1,000 devices or 10 MCPs. So how?

Previously, I mentioned how each syscall has its own argument shape, but there's a detail I didn't cover. All syscalls that can be implemented by any connected machine, such as fs.*, shell.exec, and net.fetch, have an extra parameter: target: string.

All syscalls work exactly the same regardless of the target, which creates a hardware abstraction that allows agents to interact with arbitrary numbers of machines from the same agent loop.

In our evaluations, models like GLM 5.2 behave incredibly well for tasks that span a fleet of 1,000 devices. They can even make use of tools like CodeMode to script operations on multiple devices at once, unprompted.

Thus, the result is that a user gets to ask "Where did I put the flight tickets?" and their agent can immediately read the files in their laptop, phone, or wherever else.

A Browser Is a Second OS

One could argue that a significant amount of computer time is spent on the browser to read websites and use web services.

If you've worked with browsers before, you know that they are heavily locked down from the rest of the OS, making it hard to interact with them through the computer's command line.

We're not trying to make the personal intelligence layer integrate with third party services. Instead, we're integrating it with the same tools the user has, so we've built a solution to connect the user's browser as if it was just another machine.

Popular browser integrations for agents rely on exposing CDP or Playwright-like tools to the agents. As previously mentioned, we have a fixed set of tools, but we get to extend them. We've built a browser extension that implements a filesystem and shell, just like a machine. The shell has CLIs that wrap around browser features, so agents can not only use a browser, but use the user's browser that already has authenticated sessions for all relevant sites. This reduces bot detection by a very large margin.

This pattern of exposing any device or pseudo-device with a file system and shell has proved very flexible and effective for the use cases we've tried.

Rapid Fire

I could keep writing about the reasoning behind every feature and decision, but this would be too long of a post. I'll save that instead and end with a quick rapid fire description of some other features your personal GSV includes:

Repos

GSV uses a custom built WASM Worker that implements a very fast Git remote. You and your agents can use git repositories from GSV directly. You can clone it and push from anywhere too, just like you do on GitHub. Internally, they're managed with repos.* syscalls.

Packages

Packages deserve their own writeup. Users can build CLIs, UIs, and services using the existing syscalls through JavaScript. To install packages, you point your GSV to a git repository, like GitHub or another GSV hosting the package, spawn an agent to review the code for any fishy business and, if approved, you can get started right away. You're free to inspect the source code fully. Internally, they're managed with pkg.* syscalls.

Schedules

This one is simple and important. GSV can schedule actions to happen recurrently or at a future point in time. Whether those are running a command at 9PM or spawning an agent every morning, internally they're managed with sched.* syscalls.

Library (Wikis)

Following up from repositories, GSV comes with a wiki builder/viewer. You or your agents can create and read wikis. By default, GSV will include a GSV manual as a wiki aimed at both humans and machines. Internally, these are just repositories that include a wiki.json file.

Messengers

Even though we've put a lot of effort into our web UI so that it's easy to use and understand, there is no need to interact with your GSV or its agents through it. You could also use our CLI, or connect messengers and use your day-to-day platforms as a bridge to your agents. Telegram, Discord, WhatsApp, and more are on the way.

Everything is open source, so if your messenger platform is missing, create an issue or a PR directly. We want the community to have a say in everything we do.

What Are You Waiting For?

You made it to the end, which probably means you align with our vision. Feel free to read through the code at github.com/deathbyknowledge/gsv, try it out from deploy.gsv.space, or drop by our Discord to ask questions or show what you're doing with it. Thanks!