Ox

Distributed Evolution

An Ox can learn a new way to act without waiting for a new version of its Host or Client. It can study a website or workflow through an existing capability, turn what it learns into typed actions and reusable instructions, and make them 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 they are, or adapt them to new work.

This lets each Ox evolve independently and, when users choose to share, lets different Ox evolve together. The VM, services, skills, and repository boundaries that make this possible are defined below.

Protocol Components

An Ox separates the interface, runtime, model, persistent state, and capabilities into seven components.

01 Ox Client

An interface that connects to an Ox Host. A Client may be a mobile app, desktop app, web app, or command-line tool. The Host binds VM execution to the selected conversation, its permissions, attached services, and virtual filesystem view.

02 Ox Host

A 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 elsewhere.

03 Ox Agent

The reasoning and tool-using process that pursues the user’s goals using the selected model, the state in an Ox Profile, and the capabilities exposed through the Ox VM.

04 Ox Model Provider

The connection to the language model selected by the user. OpenOx does not prescribe a model or provider; the Host adapts provider-specific APIs to the provider-neutral agent loop.

05 Ox Profile

A portable folder containing the Agent’s persistent state: its identity, memory, skills, artifacts, and conversation history. This keeps the Ox’s state independent of a particular Client or model.

06 Ox VM

The execution environment supplied by an Ox Host. The Agent writes and runs code inside the VM without direct access to the network, Host filesystem, or device. Instead, it uses explicit ox.* capabilities to interact with the Profile, services, websites, users, and device capabilities. The ox.fs virtual filesystem presents Profile content, skills, services, chats, and user-granted files while preserving each source’s permissions.

07 Ox Service Repository

A versioned collection of service definitions described by a repository.json manifest. Every Host manages an editable local repository and may install compatible remote repositories. Web and MCP services can be shared through Git; device services are supplied by the Host.

Protocol Resources

Protocol Messaging

OpenOx does not impose one universal message envelope. Each boundary defines the narrow typed contract it needs. A Client talks to Host-owned chat operations, the Agent exchanges provider-neutral messages and streaming events through a model adapter, and JavaScript crosses the VM boundary through ox.*.

let chat = host.chats.startNewChat()
let outcome = await chat.submitAndWait(
    "Find Ada Lovelace's email address"
)

const contacts = await ox.service.invoke({
  name: "ios:contacts:search",
  input: { query: "Ada Lovelace" },
  purpose: "Find Ada's email address"
});

console.log(contacts);

{
  "function": "ox.service.invoke",
  "arguments": {
    "name": "ios:contacts:search",
    "input": { "query": "Ada Lovelace" },
    "purpose": "Find Ada's email address"
  }
}

Canvas uses the same service-action contract through window.ox.service, but cannot call the rest of the ox.* tree. Each receiver validates incoming requests, and results, events, and errors follow the same boundary back. A remote implementation can serialize these contracts over a transport without exposing the Host's internal state.

Client–Host Compatibility

Clients target the OpenOx Host contract rather than a particular platform, model provider, or VM engine. Any Client can work with any Host that implements a compatible version of that contract and exposes a route the Client can reach.

The Host keeps ownership of the Ox’s Profile, chats, model connection, services, permissions, and VM lifecycle. Embedded and remote routes expose the same responsibilities, although authentication, discovery, reconnection, and event synchronization become transport concerns when the connection crosses a process or network.