Runex

ADR-0001: runex Is an Agent-Native Ontology Runtime ​

  • Status: Accepted
  • Date: 2026-05-19

Context ​

runex is easy to misclassify.

From one angle it can look like:

  • a note-centric knowledge tool
  • a workflow engine with graph state
  • a protocol surface for agents
  • a structured memory layer for LLM systems

Those descriptions capture parts of the system but miss the center.

The project now has:

  • a typed graph store
  • runtime-loadable supertags, machines, and actions
  • a reactive event cascade
  • a machine-first contract (Result, manifest(), events)
  • source and sink channels at the edge

This is already beyond "an app feature" or "a protocol adapter". A clear top-level classification is needed so later product and architecture decisions remain coherent.

Decision ​

We classify runex as an agent-native ontology runtime.

Equivalent acceptable phrasing:

  • an ontology operating system for agents
  • an ontology operating substrate
  • a machine-first ontology platform

The preferred internal phrase is:

runex is an agent-native ontology runtime

This means:

  1. the durable center of the system is the ontology-shaped runtime, not any one UI shell
  2. agents and human-facing products consume the same contract and the same semantic world
  3. the project's job is to own what is true and why, not merely to expose tools or render screens

Alternatives Considered ​

1. runex is primarily an app ​

Rejected.

Reason:

  • an app implies a human-facing product shell is the center
  • runex's architecture instead centers the runtime contract and semantic graph
  • multiple shells can sit on top of it without changing the truth model

2. runex is primarily a protocol ​

Rejected.

Reason:

  • the protocol is the external surface, not the whole system
  • the deeper value is the runtime that maintains typed state, reactive behavior, and event provenance
  • calling it only a protocol understates the substrate and invites underinvestment in the runtime itself

3. runex is primarily an LLM memory layer ​

Rejected.

Reason:

  • "memory" is too weak a category
  • the system models typed objects, identities, links, lifecycles, and actions, not only recollection
  • ontology is the correct abstraction, not memory snippets

4. runex is primarily a workflow engine ​

Rejected.

Reason:

  • workflows answer what step runs next
  • runex's runtime must also answer what object exists, why it is in this state, and what semantic cascade followed from a write
  • workflow is one consumer shape, not the center

Consequences ​

Positive ​

  • keeps the runtime, not the UI, as the architectural center
  • aligns the white paper, architecture, and product direction
  • gives a stable frame for future desktop-shell and agent-shell work
  • clarifies that manifest() and the event contract are not incidental APIs but category-defining surfaces

Negative / Tradeoffs ​

  • "ontology runtime" is a stronger and less familiar claim than "app" or "protocol"
  • the project takes on the burden of justifying a new class of system, not merely shipping features

Implications ​

  • desktop and web products should be treated as shells on top of the runtime
  • agent support should target the runtime contract first, not ad hoc UI automation
  • documentation should distinguish clearly between:
    • runtime architecture
    • contract surface
    • product shells