OpenOx is an open protocol designed around a specific idea: an AI agent should be able to evolve on its own, share what it learns, and maintain its identity regardless of which app or model is doing the actual thinking. The protocol separates an agent's interface, runtime, model, memory, and capabilities into seven distinct components, each with a defined role.
Seven components of the protocol
An Ox is built from seven parts. The Ox Client is any interface — mobile app, desktop app, web app, or command-line tool — that connects to an Ox Host. The Ox Host is the process or device that opens an Ox Profile, runs the Ox VM, and supplies platform and service adapters. A Client can use an embedded Host or target a compatible Host running elsewhere.
The Ox Agent is the reasoning and tool-using process that pursues the user's goals. It uses whatever model the user selects, reads from the Ox Profile, and accesses capabilities through the Ox VM. The Ox Model Provider is the connection to the chosen language model; OpenOx does not prescribe any particular provider, and the Host adapts provider-specific APIs to a provider-neutral agent loop.
The Ox Profile is a portable folder containing the agent's persistent state — identity, memory, skills, artifacts, and conversation history. This keeps the agent's state independent of any particular Client or model. The Ox VM is the execution environment where the agent runs code. The Ox Service Repository is a versioned collection of service definitions, each described by a repository.json manifest.
The VM and its capability model
When a task requires action, the model can produce JavaScript that the agent submits to the Ox VM. The Host validates the request, binds it to the calling conversation, and queues execution. The VM runs code in a capability-limited environment with no direct access to the network, host filesystem, or device. It provides JavaScript, a console, and the global ox capability interface — nothing more.
Everything outside the VM must pass through an explicit Host capability. The VM reaches the Host through the ox.* capability tree, where every operational function accepts a single options object with a user-visible purpose and validates its input against a closed schema. A synchronous help() method describes the expected inputs and outputs. The VM validates the options object against its runtime catalog before the Host performs authorization, requests approval, executes the operation, and records structured diagnostics.
Evolution and sharing
The protocol's core innovation is distributed evolution. An Ox can study a website or workflow through an existing capability, convert what it learns into typed actions and reusable instructions, and make those available immediately. Those additions can remain local or be recorded in Git and shared through a repository. Another Ox can install them, use them as-is, or adapt them to new work.
This means each Ox evolves independently, and when users choose to share, different Oxes can evolve together. The boundaries of the VM, services, skills, and repositories make this possible without coupling an agent's growth to a specific host application or model provider.
Skills, services, and artifacts
Services give an Ox typed actions for work outside the VM. Rather than receiving ambient access to a device or network, the agent discovers explicit actions with documented inputs and outputs and invokes only the capability it needs. A service can expose device capabilities, operate a website through the user's browser session, or connect to an MCP server. The Host owns authentication, resources, approvals, and handoffs.
Skills are reusable instructions that teach an Ox when and how to carry out a workflow — ordered steps, decision rules, checkpoints, and safety boundaries — without adding new authority. This separation keeps know-how distinct from access: services define what can be done, while skills explain how to combine those actions.
Artifacts are durable outputs stored with an Ox Profile. Unlike a standard chat response, an artifact can be reopened, revised, attached to another conversation, or carried with the profile. An artifact might be a Markdown note, an imported file, or a self-contained HTML Canvas that runs as an independent browser page and can call Host services through the same contracts and approvals used in chat.
What this means for agent architecture
OpenOx represents a design philosophy where the agent's growth, identity, and capabilities are decoupled from the application interface and the underlying model. The protocol defines the observable execution boundary but leaves the Host responsible for the runtime engine, thread model, permissions, and execution queue. Any Client that implements the OpenOx Host contract can work with any compatible Host, regardless of platform or provider.
The protocol also defines a messaging model where each boundary uses the narrow typed contract it needs rather than a single universal envelope. Clients talk to Host-owned chat operations, the Agent exchanges provider-neutral messages through a model adapter, and JavaScript crosses the VM boundary through ox.*. This modular approach means OpenOx can accommodate different transport and runtime choices without forcing a single implementation path.