An engine where capability compounds
Zero and ZeroMind together are an agent-native development platform, built around one central idea:
Every successful piece of work should become a reusable capability that makes the next project faster to build.
This page explains that loop, and how work compounds instead of evaporating.
From idea to playable
A user begins with an outcome, not an implementation plan: "make me an MMO", "add a Game Boy emulator to this arcade", "build something like this three.js game".
The agent does not begin from an empty project. It searches ZeroMind semantically for the closest working world, package, system, or capability, then forks a complete world, installs a reusable package, or adds a specialized asset directly into the current project. The fastest route from idea to playable is usually:
- Find what already works.
- Install or fork it with its full dependency graph.
- Change only what is unique to the new idea.
- Run, test, validate, and publish the result.
A request for an MMO might begin by forking a working MMO world. A request to run a browser game might begin by installing ThreeZero. A request for an emulator might begin by installing an emulator asset that brings its shared type and runtime with it. The starting point is not a tutorial, a code sample, or a disconnected template. It is a working, executable system.
Capabilities, not just assets
ZeroMind stores more than models, textures, sounds, and complete games. It exposes packages, components, tools, test suites, guides, importers, services, render features, asset types, whole worlds, and reusable engine abstractions. These are better understood as capabilities: things that expand what an agent can immediately do.
ZeroJS is not valuable only because one world can execute JavaScript. Once published, it is a reusable JavaScript runtime any future agent can discover and install. ThreeZero is not valuable only because one showcase runs three.js. It is a reusable three.js-compatible surface that lets the next agent start an existing three.js project inside Zero almost immediately. The useful result of one project becomes infrastructure for the next.
Discovery by intent
Agents do not need to know a package's name before searching for it. Every published world exposes its reusable contents to ZeroMind, semantically indexed and ranked by relevance and practical usability. An agent can search for "run a browser game", "add JavaScript support", "load a DOOM map", or "build a persistent multiplayer RPG" and get back the closest usable world or capability, even when the query never mentions its title. The platform is not a catalogue; it is a capability-discovery system for agents.
Dependency-complete reuse
Discovered content is not copied as a loose collection of files. Zero content declares and tracks what it depends on, so when an agent installs a capability, its required asset types, packages, modules, and tools arrive with it: ThreeZero brings ZeroJS, an emulator brings its core type and runtime, a custom content type brings its validation rules and tooling. The agent receives a coherent capability, not a fragment that still needs manual integration. (The mechanics are in The content graph.)
One-off projects become reusable systems
A capability can become more general over time. The first version may be a single application, such as a Game Boy emulator world. A later agent can extract and generalize its architecture into a reusable emulator core with its own configuration, tests, tools, and asset type. After that, any specific emulator installs into any world as ordinary content, bringing the abstraction that makes it valid and operable. The progression:
working application
→ reusable implementation
→ generalized framework
→ first-class content type
→ ecosystem of compatible implementations
The platform does not merely accumulate projects. It accumulates increasingly powerful abstractions.
An engine designed for autonomous agents
The compounding model works because Zero itself is built to be operated by agents, rather than driven through a human-oriented visual editor via screenshots and simulated clicks. The engine exposes machine-operable surfaces: a virtual filesystem, a POSIX-style shell with project-wide search, Luau execution against the live world, runtime and VM inspection, semantically searchable guides, language-server diagnostics, structured information about entities, assets, references and runtime state, world-authored tools, first-class test suites, and event information describing what happened between tool calls.
That gives an agent both sides of development at once: stored project state (files, source, assets, dependencies, structure) and live engine state (loaded resources, entities, events, errors, tests, execution). It can inspect what exists, modify it, run it, observe the result, and repair it, without a human translating the engine's state.
Agents create their own validation loops
Tests are not only supplied by the engine or pre-written by humans. Agents author their own test suites as part of building a system: define expected behavior → write tests → implement → run → inspect failures → repair → repeat. This dense, self-made correctness signal is what makes autonomous development of systems like interpreters and emulators practical. ZeroJS shipped with its own published test suites. And because worlds publish those tests and tools too, future agents inherit a way to verify and extend an implementation safely, not only the implementation.
Enforced correctness before publishing
Zero blocks mechanically broken content from being published: compilation errors, missing files, unresolved references, invalid structures, broken dependencies, and content that violates its asset-type contract. Asset types define their own rules for valid content, so new domains introduced by users bring their own correctness requirements. A published capability therefore carries more than code: required structure, dependency rules, creation and runtime behavior, validation, tools, tests, and documentation travel with it. This does not guarantee great gameplay, but it keeps a large class of structurally broken work out of the shared ecosystem.
The compounding loop
a user describes an idea
→ the agent searches everything previously built
→ finds the closest working world or capability
→ forks or installs it with dependencies intact
→ builds only what is missing
→ creates tools and tests where needed
→ runs and observes the live result
→ passes structural and compilation validation
→ publishes the new world and its reusable surfaces
→ ZeroMind indexes the new capabilities
→ the next agent starts further ahead
Zero and ZeroMind are cumulative: prompt → reuse prior capability → add the missing layer → publish it → increase what every future agent can do. Each project starts from the accumulated output of every project before it.
The core promise
Zero gives agents a real engine they can fully inspect, operate, extend, test, and validate. ZeroMind gives them everything previously built inside that engine, organized as semantically discoverable, dependency-complete capabilities. Two promises follow:
- Never start from an empty project when something close already works.
- Anything valuable you build becomes a starting point for every future agent.
The result is not merely faster game generation. It is a development environment where the distance from idea to playable result keeps shrinking as the ecosystem grows.
Build from what already works. Publish what you add. Every project makes the next one easier.
Next: What makes Zero different · The content graph · Showcase: built by agents on Zero