Skip to content
ONTO
How it works

Architecture: humans hold the write path.

Autonomous agents read and write state in one uninterrupted loop. ONTO breaks the loop in two — the agent proposes, the human commits — and enforces the split in the runtime, not the prompt.

The request path

One run, five checkpoints — every one auditable.

Data flow: agent reads and proposes, Policy Guard and Plan Mode gate, human approves, then execute and write to UPO. AGENT (PROPOSES) HUMAN (COMMITS) Read state UPO + SMO Propose tasks no side effects Policy Guard check consent scopes Plan Mode halt review the plan Approve grant execute scopes Execute write UPO + audit
  1. 1

    Agent reads state

    The runtime loads relevant UPO + SMO facts and hands the model a small, typed context — not a replayed chat log.

  2. 2

    Agent proposes

    The model proposes tasks and tool calls. In Plan Mode the run halts here: nothing has executed and nothing has been written.

  3. 3

    Policy Guard checks scopes

    Each proposed tool call is matched against the consent scopes granted for the run. Unauthorized calls are refused before they can fire.

  4. 4

    Human approves

    The reviewer reads the plan, edits or rejects tasks, and grants execute scopes. Approval is an explicit human write — the model cannot self-approve.

  5. 5

    Execute + write UPO

    A second run with execute scopes performs the approved work. Durable facts are committed to UPO with provenance, and the audit log records the whole path.

The stack

Four layers, one core.

ONTO keeps the surface small on purpose. Everything below the SDK binding is shared Rust, so a fact written from Python reads back identically in TypeScript or Rust.

One Rust core

The runtime, the UPO + SMO memory model, extraction, and Policy Guard are implemented once, in Rust. Python (PyO3), TypeScript (napi-rs), and native Rust are thin bindings — identical semantics across all three.

Typed memory store

UPO holds durable facts; SMO holds session context. Pluggable storage: Sled for a local single binary, or Postgres + pgvector for a networked, multi-tenant deployment. fastembed gives you local embeddings with no external call.

Policy Guard

A gate in front of every tool call. Tools declare required scopes; runs carry granted scopes; the guard refuses anything unauthorized with a structured, auditable error. Enforcement is server-side and independent of the prompt.

Provider adapter

Defaults to Ollama Cloud open-weight models. One env var swaps to Anthropic or OpenAI, or to a local Ollama server for a fully on-prem path. The cost meter attributes spend per user and per tenant.

Deployment

From a single binary to on-prem Kubernetes.

Start with Sled and an open-weight model in one process — no services to run. Scale to Postgres + pgvector, a local Ollama server, and Helm-managed pods when you need multi-tenant scoping and no data leaving your network.

  • Sled (embedded) or Postgres + pgvector storage
  • fastembed local embeddings — no embedding API needed
  • Helm recipes for Kubernetes rollouts
  • Local Ollama or any OpenAI-compatible endpoint
Explore the features Read the glossary
onprem.env 
# stay fully on your network
ONTO_STORE=postgres
ONTO_PG_DSN=postgres://onto@db/onto
ONTO_EMBED=fastembed

# point at a local Ollama server
ONTO_PROVIDER=ollama
ONTO_BASE_URL=http://ollama.internal:11434

# no data leaves the cluster
Run it

Read the quickstart and ship your first agent.

Five minutes from install to an approved plan. Free open-weight default, so there is no API-key relationship to set up first.

Open the quickstart Full docs pip install onto-core