The vm0 repository's page sells a different product, and its three licence declarations do not agree

The repository is named for one product and the page sells another

The single largest thing to know about this project is that its two names do not match.

The repository is recorded under one organisation and named for a product called Zero, described as a trustworthy AI teammate for real work. Everything on the project page belongs to a different organisation and a different name.

The header links a brand site on a different domain, with light and dark logo files hosted as assets for that brand. The badge row links a wiki, a workflow run page and a coverage page for a repository under a third account path. The call to action links a sign-up page, a Slack installation endpoint, a use case page and a blog, all on that same domain. The product name in the page's own headline line is used throughout the body text, in every example conversation, in every table.

So this is a rename that landed on the hosting side and in the README and did not land everywhere else, or a repository that was pointed at documentation for a sibling product. Either way, the mismatch is complete rather than partial, which is why it is the first thing to check.

The internal artefacts agree with the page rather than with the repository name. The root JavaScript manifest names the package with the page's brand, and the repository carries an editor workspace file named for it as well. That tells you the code and the documentation agree with each other, and it is the recorded metadata that is behind.

One more detail worth noting: the page asks readers to star the repository on GitHub, which is the kind of line that makes sense when a repository has been renamed and is trying to rebuild its star count under a new identity.

Three licence declarations, three answers

There are three places a licence can be stated in a repository, and all three are filled in differently here.

The stored licence metadata for the repository is empty. That is the recorded value.

The root JavaScript manifest declares a licence field, and it names ISC. That is a permissive licence with a short form and a short grant, and it is not the licence the readme points at.

The readme itself states no licence at all. It links a licence file in the repository root and says to see that file for details. And the file is not reproduced anywhere in the page.

So a reader has three candidate answers and one dead end. The metadata says nothing, the manifest says one thing, and the readme refuses to summarise and points at a file whose contents they have to go and open.

For a project that invites people to inspect, fork or self-host it, this is the wrong place to be vague. The readme's own open source bullet makes the invitation, and the invitation is answered three different ways three lines apart.

It is worth noting what the readme does say precisely elsewhere. It spells out that credentials never leave the sandbox, that every run has logs, metrics and network visibility, and that permissions are set read or write per tool and per agent. Those are specific claims about behaviour. The licence is the one claim it declines to make, and it is the one claim that decides whether you can ship the thing.

Read the file in the root. Do not infer the terms from either of the other two.

The root package manifest is still the scaffold a generator produced

The root JavaScript manifest is the most revealing file in the repository, and not as a description of the project.

It is five fields of real content and four of placeholders.

"name": "okou",
"version": "1.0.0",
"description": "",
"main": "index.js",

The description is an empty string. The keywords array is empty. The author field is empty. The main entry points at a file at the repository root that is not in the file list.

And the test script is the one every package generator writes before anyone has written a test: it echoes an error message about no test being specified and exits with a failure.

Now put that next to what else is in the repository. There is a coverage service configuration and a coverage badge, a coverage badge pointing at a workflow run page filtered to merge queue events, a development container configuration, an end to end directory, a fixtures directory, a development container, a commit message linter and its configuration, a hook runner configuration, a secret scanning configuration with its own ignore file, a static analysis ignore file, a release automation configuration and its manifest, agent instruction files, and a turbo directory indicating a task orchestrating a monorepo.

So the engineering surface says this is a monorepo with continuous integration, coverage, linting, secret scanning and release automation, and the manifest at its root is a placeholder that would fail its own test command. The real manifests are in the workspace members. The root one is a leftover.

It is harmless, and it is also the file a package manager will read if you install from the root.

Three runners, three version numbers, released seconds apart

The release history says more about the architecture than the feature list does.

There is no release for the product. There are releases for three components, and all three were published on the same day within a handful of seconds of each other: a supervisor at patch version nineteen of a zero point two line, a remote runner at a zero point ten line, and the Rust runner at a version whose numbering is unusual.

So the shipping unit is a set of runners, versioned independently, cut together by an automated release process rather than chosen together by a person.

Two observations follow.

The first is that the root manifest's version belongs to none of them. The root package is at one point zero point zero; the runners are at zero point two, zero point ten, and a much higher patch number. A repository can have one product version and several component versions, but the product version here is not on any release page, so there is nothing to install that is called version one.

The second is the numbering of the Rust runner. A zero-two-one-nine point fifteen line is not a sequence anyone picks deliberately; it reads like a prefix that lost a decimal point. If it is correct it is a very long lived component. If it is a typo then some automation is publishing it and nobody has noticed, and the fact that the same day's release cut it unchanged is either a sign the mistake is intentional or a sign nothing is checking.

The release process is automated, and the manifest and configuration files for that are both committed at the root, alongside a conventional commit linter and a hook configuration. Whatever cut these three releases did so without a human deciding on a product version, which is consistent with the root manifest being a placeholder nobody has had a reason to fix.

It drafts and a human sends, and the boundary is per tool

The safety section is the one with the most specific claims, and its framing sentence is the whole policy.

Anything that leaves your company or spends your money stops for a human. That is a single sentence defining the boundary in terms of consequence rather than in terms of a feature list, and the five bullets below it are the implementation of it.

The first bullet is the mechanism. It drafts rather than sends. The concrete example is email landing in the mail client unsent, and an advertising budget shift waiting in the advertising platform for approval. Both cases are money or reputation moving outside, and in both the artefact exists and is ready, it simply has not gone.

The second is granularity of permission: read or write, per tool, per agent. So the guarantee is not that the agent cannot send email, it is that this agent does not have write access to mail. A different agent, configured differently, can.

The third is isolation. Every task runs in its own microVM, using a virtualisation technology built for serverless isolation, and credentials never leave the sandbox. Per task rather than per session matters: it means a task that goes wrong does not inherit anything from the task before it.

The fourth is auditability, described as logs, metrics and network visibility for every run. The fifth is the open source claim, which points at the repository itself and invites inspection, forking and self-hosting.

The workflow permissions rule in the other section is the one that ties the two halves together: a shared workflow never borrows someone else's access, and each teammate runs it with their own permissions. So a team can share a procedure without sharing a credential.

A workflow is saved when the job repeats, and it belongs to the workspace

The workflow section is a four row table, and the second row is where the interesting decision sits.

The first row is running: someone asks for work the way they would ask a colleague, and the system works out the steps. The worked example in the page is a chat, where a person asks for a one page document with a hero, a story and three room tiles, and the reply is that the brand brief was read and publishing will happen as soon as it reads right. A second exchange in the same chat shows a follow-up request to send a launch note, and the reply says the draft is in the mail client, unsent.

The second row is saving, and the trigger is the condition to notice. When it sees the job repeat, the system offers to keep the run, saving together the instructions it followed and the tools it reached for. So the capture is not a template a human writes; it is an observation that something has happened twice, followed by an offer rather than an assumption.

That is the right default in one respect, since nobody has to learn a new authoring format. It is also the risky one: the first repeat of a two-off job is indistinguishable from a habit, and the page does not say what the offer looks like or who approves it.

The third row is handover, and it is where ownership is settled. The workflow belongs to the workspace rather than to one person, and a teammate runs it from chat or from Slack without rebuilding any setup.

The fourth row is automation: put it on a schedule or a trigger and the work starts arriving before anyone asks.

The example above the table makes the fourth row concrete with a week of work running at once: four chats opened and all running, a landing page published, four hundred and twelve records updated in the customer system, a newsletter drafted and not sent, and an eight slide deck built from the numbers.

MicroVM isolation, three thousand connectors, and a Slack install endpoint

The last details are the infrastructure claims and the file list.

The connector list is long and named: a chat workspace, a forge, a mail client, a calendar, a spreadsheet, a note tool, an issue tracker, an error tracker, a log store, a customer system, a support desk, a design tool, a hosting platform, a file store, an electronic signature service, an HR platform, a database, a search tool, an advertising platform, and two social networks, followed by a claim of three thousand more.

Model choice is explicitly left to the user: several named providers, selected per run or per agent. That is a deliberate contrast with the connector list, where breadth is the pitch. Which model runs a given task is yours to decide, but what the task can reach is the platform's list.

The install surface is a Slack endpoint described as an OAuth installation, alongside a web sign-up. There is no desktop or mobile application described anywhere on the page, and no iOS application either, which is worth noting because the repository contains an iOS directory that the page never mentions.

The rest of the tree is the shape of a serious monorepo. Rust crates sit beside the JavaScript, orchestrated by a task runner. There are directories for deployment automation, operations, containers, an end to end suite, fixtures, scripts, documentation and assets. A development container configuration means the environment is reproducible. A mailmap file and a code of conduct are both committed. Two agent instruction files, a context file and a review file sit next to a security policy and a contribution guide, which is a lot of process for a repository whose root manifest is a placeholder.

Secret scanning, static analysis and commit message linting are all configured at the root. The last push to the default branch is recorded as 2026-10-02, and the repository is not archived.

Editorial conclusion

Adopt this if your problem is that work handed to an agent leaves the building, because the send boundary is stated in terms you can check: email lands unsent, a budget change waits for approval in the advertising platform, and every task gets its own microVM. Two things to resolve first. The repository you are reading is described as one product and documents another, so check the contribution guide and security documents before you assume which one you are installing. And the root package manifest is a placeholder with a deliberately failing test script and a licence field that contradicts both the file the readme points at and the stored licence metadata, so read the licence file directly before any commercial use.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes