Runex

runex White Paper ​

Toward an Agent-Native Ontology Runtime ​

Executive Summary ​

Modern software assumes one of two centers of gravity:

  • a human-facing application with data trapped behind screens
  • a model-facing API that can answer questions but cannot own durable, typed, inspectable business state

Neither is sufficient for the next generation of software.

Agents need more than chat completions and tool calls. They need a durable world model they can inspect, mutate, and observe with the same discipline an operating system gives a process: stable objects, typed transitions, auditable effects, and a closed event stream. Humans need the same substrate, presented through a product shell.

runex's thesis is that this missing substrate is an agent-native ontology runtime: a typed graph where object types, lifecycle rules, reactive actions, and channel connections all live as data and are exposed through one machine-first contract.

This paper argues three claims:

  1. the missing layer in the AI stack is not "another app", but a runtime that owns what is true and why
  2. this runtime must be ontology-shaped, eventful, typed, and runtime-malleable
  3. the correct product form is not merely a protocol and not merely an app, but a small operating substrate for agents and human-facing shells alike

1. The Problem: Agents Can Speak, But They Cannot Yet Operate a World ​

The current AI software stack is strong at generation and weak at durable operation.

Large language models can:

  • interpret intent
  • draft plans
  • call tools
  • transform text

But most agent systems still lack a trustworthy substrate for:

  • persistent typed state
  • explicit object identity
  • lifecycle management
  • causal auditability
  • long-running reactive behavior
  • cross-source data convergence

What fills the gap today is usually one of three unsatisfying patterns.

Pattern A: The Screen-Centric Application ​

A traditional application keeps truth inside product-specific tables and UI workflows. An agent can click the app or call its APIs, but it does not share the application's inner semantic model. The result is a split brain:

  • the human sees one model of the world
  • the agent reconstructs another model from APIs and prose

This is fragile and expensive.

Pattern B: The Tool-Calling Agent ​

An LLM plus tools can act, but the system of record often remains:

  • untyped
  • implicit
  • spread across tool payloads
  • difficult to inspect as one world

The agent has verbs, but no durable ontology.

Pattern C: The Workflow / Automation Graph ​

Workflow engines are good at moving payloads between systems. They are less good at maintaining a long-lived semantic world model. They answer:

  • what step runs next

More weakly, they answer:

  • what object now exists
  • why it is in this state
  • which rule caused the transition
  • how multiple sources converge on one identity

These are not incidental limitations. They point to a missing layer.

2. The Missing Layer: A Runtime That Owns Truth, Not Just Tools ​

The central technical problem is not "how do we give agents more tools?" It is:

How do we give agents and humans one shared, durable, inspectable world whose semantics can evolve at runtime?

That world needs several properties at once.

It must be typed ​

Objects cannot just be JSON blobs. A durable system needs:

  • object kinds
  • field schemas
  • links
  • identities
  • lifecycle fields

Without types, every agent call re-derives meaning from raw payloads.

It must be eventful ​

A system is not understandable if writes happen silently. Durable operation requires:

  • explicit events
  • replayable history
  • causal provenance
  • resumable observation

Without an event log, there is no trustworthy closed loop.

It must be reactive ​

The interesting behavior in real systems is not the initial write, but what follows from it:

  • a note becomes a topic
  • a URL becomes a bookmark
  • a state transition triggers writeback
  • multiple sources enrich the same node

These should not be hardcoded orchestration branches in every adapter or UI. They should be first-class runtime semantics.

It must be runtime-malleable ​

In most systems, changing business semantics means editing code, redeploying, and migrating interpretation by hand. That is too slow for agent-driven systems. Agents need to be able to author and load new rules into the world they operate.

This is where ontology stops being a static modeling artifact and becomes runtime infrastructure.

3. A New Class of System: The Agent-Native Ontology Runtime ​

runex's proposed class of system is not best described as "a note app", "a workflow tool", or "a protocol server".

It is a new runtime class with the following shape:

  • a typed graph store as the durable world model
  • supertags as runtime type declarations
  • state machines and actions stored as data
  • a reactive bus that turns writes into cascades
  • source and sink channels that translate external systems at the edge
  • a machine-first contract for agents and UI shells

This can be thought of as an ontology operating substrate.

Not because it replaces an operating system kernel in the literal sense, but because it plays a similar role one layer up:

  • it owns stable objects
  • it mediates effects
  • it exposes an inspectable contract
  • it provides event observation
  • it lets many shells sit on the same truth

In this framing:

  • human-facing desktop or web apps are shells
  • autonomous agents are shells
  • channels are drivers/connectors
  • ontology bundles are runtime-loaded semantics

This is why "protocol" is too small a word and "app" is too small a word.

The protocol matters. It is how outside consumers talk to the runtime. But the deeper idea is the runtime itself: a shared semantic operating layer for humans and agents.

4. Why Ontology, Not Just Memory ​

Many AI systems use the word "memory" to describe stored context. That is useful but insufficient.

Memory says:

  • the system remembers facts

Ontology says:

  • the system knows what kinds of things exist
  • how they are identified
  • how they are related
  • what lifecycle they are in
  • what actions may follow

This distinction matters.

A bag of memory snippets cannot robustly express:

  • one Person seen across WeChat, notes, and media data
  • one Thought moving from draft to zettelized
  • one Bookmark transitioning from pending to pushed
  • one Project becoming the identity hub for multiple channels

Ontology is the minimal structure required for durable multi-agent operation.

That is why the project's real ambition should not be phrased merely as "ontology for everyone". That phrase is broad but underspecified.

The stronger and more technically accurate ambition is:

Build the ontology runtime that agents can actually operate.

If that succeeds, it can later become ontology infrastructure for many people. But the technical forcing function is the agent, because the agent demands:

  • a complete machine-first contract
  • introspection without source reading
  • deterministic event semantics
  • explicit, typed boundaries

5. Why a Machine-First Contract Is the Right Product Surface ​

An agent-native runtime cannot rely on prose as its interface.

Its external surface must be machine-first:

  • one Result envelope
  • one manifest() introspection surface
  • one closed event vocabulary
  • one resumable event cursor

This is not incidental implementation taste. It is what lets:

  • a CLI
  • a desktop UI
  • an autonomous agent
  • a background watcher

all consume the same source of truth.

The consequence is powerful:

  • a product shell does not invent its own hidden business model
  • the agent does not scrape or reverse-engineer the app
  • both operate on one contract

This is the right answer to the common failure mode where "the AI layer" and "the application layer" drift into separate world models.

6. Why Channels Live at the Edge ​

A durable ontology runtime must be strict about its boundary to the outside world.

External systems are:

  • high-churn
  • third-party controlled
  • schema-unstable
  • impossible to normalize at the protocol layer alone

So the runtime needs an explicit channel edge:

  • inbound DataSourceSpec
  • outbound SinkSpec
  • generic core-owned capabilities beneath them

This separation matters because it preserves four architectural properties:

  1. the core owns stable capabilities, not channel-specific semantics
  2. CanonicalItem remains the single typed boundary
  3. manifest() remains a complete introspection surface
  4. external churn is isolated at the channel layer, not injected into core primitives

This is why adapters cannot simply be collapsed into kernels without architectural loss. The adapter is not an accidental class. It is the explicit translation layer between heterogenous external worlds and the runtime's typed internal world.

7. What This Makes Possible ​

Once the substrate exists, new product forms become natural rather than forced.

A desktop ontology shell ​

A desktop app can show:

  • connect folder
  • connect NocoDB
  • load ontology bundle
  • inspect actions and machines
  • watch events

without becoming the business engine itself. It simply drives the runtime contract and renders the results.

Agent-authored business systems ​

An agent can:

  • write .scm bundles
  • extend channels
  • load semantics at runtime
  • observe event cascades
  • debug against a formal local e2e environment

This is qualitatively different from merely prompting an LLM inside a SaaS product.

One truth across many shells ​

The same runtime can be driven by:

  • a human UI
  • a CLI
  • a background daemon
  • one or more agents

without each consumer inventing its own state model.

This is the operating-system analogy in practical terms.

8. What to Look for in This Class of System ​

If this category is real, then a serious implementation should meet a high bar. The following criteria define that bar.

1. Typed objects, not payload plumbing ​

The system should have:

  • explicit object kinds
  • field schemas
  • identities
  • links
  • lifecycle state

It should not reduce durable semantics to ad hoc JSON movement.

2. Runtime-loadable semantics ​

The system should let new lifecycle and reactive rules load as data at runtime, with migration safety.

3. Eventful observability ​

The system should expose:

  • a closed event vocabulary
  • causal provenance
  • replayable history
  • resumable observation

4. Strict effect boundaries ​

The system should distinguish:

  • pure reads
  • internal mutations
  • external I/O escape hatches
  • channel translation logic

Without this, the runtime becomes ungovernable.

5. One contract for agents and products ​

The same introspection and event surfaces should be usable by:

  • UI shells
  • CLIs
  • agents

Otherwise the architecture has already forked its truth.

runex is being built to satisfy exactly these criteria.

9. The Vision in One Sentence ​

The biggest technical vision behind runex is:

an agent-native ontology runtime that serves as the shared operating substrate for humans, agents, and external systems

If a shorter phrase is needed, the closest accurate formulations are:

  • an ontology operating system for agents
  • an agent-native ontology runtime

If a weaker, outward-facing phrase is needed for broad audiences:

  • a machine-first ontology platform

What it is not, at its core:

  • just a protocol
  • just a note app
  • just a workflow engine
  • just an LLM memory layer

Those may all exist around it. None of them capture the center.

10. Conclusion ​

Software is entering a period where humans will not be the only durable operators of business systems. Agents will inspect, mutate, and extend the semantic world directly. That world cannot be a pile of tool payloads, screens, and hidden application tables.

It needs to be:

  • typed
  • inspectable
  • reactive
  • auditable
  • runtime-malleable
  • shared across shells

That is the role of an agent-native ontology runtime.

runex's technical direction points toward that class of system. The goal is not merely to help an agent call tools more effectively. The goal is to provide the world the agent can actually inhabit and operate.