How MetaopAI works · Technical overview

A memory that compounds.
A model that stays stateless.

The pages below are for the technically curious — the KRL substrate, the cognition orchestrator, the composer that hands the model a policy-governed package, and the economics that come out of building this way. If you want the product experience instead, start here.

01 — The approach
An open experiment
// hypothesis Applications should maintain durable memory outside the model, assemble only the context needed for the current operation, and route that context to the appropriate LLM.

// method Build a typed, multi-dimensional memory layer — the KRL — then retrieve and compose relevant context as needed. Treat the LLM as a stateless reasoning provider.

// posture Patterns, not verdicts.
Probabilistic, not absolute.
Evolving, not static.

Applications should own context.
Models should consume it.

Everyone is scaling models. We’re investigating context.

Models are getting larger, faster, and more capable. But an application still has to decide what should persist, what should decay, what is relevant now, and what the model should receive. MetaopAI treats that as an application-layer problem.

The KRL maintains durable, structured memory. The memory controller retrieves the relevant state, composes a bounded context package, and routes it to the selected reasoning engine. Different models still have different capabilities — but the application’s continuity does not have to belong to any one of them.

The load-bearing invariant

The model can change.
The memory does not have to.

02 — From narration to reasoning
A continuous cognition loop

Users communicate naturally.
The application does the rest.

MetaopAI extracts structured observations, preserves them in the KRL, detects changes over time, and retrieves only what matters for the current question. The LLM reasons over the context it is given. It does not have to own the memory behind it.

01
Narration
The user writes naturally, in their own words.
02
Extraction
Structured observations pulled from the prose in parallel.
03
Typed Memory
Observations land in the KRL, addressable by kind and scope.
04
Signals & Patterns
Reinforcement, contradiction, decay — and emergent pattern.
05
Relevant Retrieval
Only what matters for the current question is fetched.
06
Context Composition
A bounded context package is assembled from the retrieved slice.
07
Model Routing
The package is handed to the selected reasoning engine.
08
Reasoning
The LLM reasons over the context and streams the response back.
The MetaopAI cognition loop: narration flows into structured extraction, is preserved in the KRL, compounds into signals and patterns, is retrieved as a scope-correct slice, composed into a bounded context package, routed to the selected reasoning engine, and returned as response — then traced and learned from.
Fig. 01 — Narration → reasoning. The application owns the memory. The model owns the reasoning.
03 — The Knowledge Representation Layer
The Knowledge Representation Layer

Memory is application state.

The KRL separates different kinds of information instead of flattening everything into one transcript. Every observation lands in a typed cell — addressable by kind and by scope. This gives MetaopAI addressable memory instead of an ever-growing block of prose.

Memory persists. Context is composed.

Kind 01

Context

Most stable

Relatively stable facts. Who someone is, what role they play, the scaffolding a relationship stands on.

Kind 02

Events

Anchored

Things that happened. Discrete happenings with timestamps — the argument on Tuesday, the promotion in March.

Kind 03

Signals

Volatile

Observations that may indicate change. Raw, granular, decay-aware — the texture of moment-to-moment interaction.

Kind 04

Meta-context

Interpretive

Broader or interpretive state. How a space feels, the atmosphere around a person, the interpretive backdrop.

Kind 05

Patterns

Emergent

Structures that emerge across evidence over time. Computed, not extracted — reinforced, decayed, reactivated as evidence evolves.

Read the full technical whitepaper
04 — Context composition
Context composition

The model only gets what it needs.

MetaopAI does not need to send everything it knows into every prompt. The memory controller selects relevant state according to the current scope, intent, and operation.

The underlying memory remains intact. The same memory can produce different context for different questions without rewriting the user’s history.

Composed, not replayed

One structured package in. One grounded answer out.

Each prompt is a policy-governed package: scope-correct continuity, session state, fresh external knowledge if needed, safeguards, and the user’s prompt. The model unpacks the package and answers within those bounds. Composed context can be compressed, reordered, model-specific, or discarded after inference — the KRL is untouched.

The composer assembles a structured prompt package from the user prompt, KRL continuity, session state, external knowledge, and policy directives. The LLM unpacks the package and answers within the composed bounds.
Fig. 02 — The Composer. Compose → route → unpack → answer within bounds.
05 — Bring Your Own Storage
Bring Your Own Storage

Your artifacts should remain yours.

MetaopAI separates artifact ownership from application intelligence. Artifacts uploaded through MetaopAI can live inside a dedicated MetaopAI folder in supported user-controlled storage such as Google Drive or Dropbox.

MetaopAI maintains the references, provenance, and derived knowledge required to reason about those artifacts. The original files remain in storage controlled by the user. If the user leaves MetaopAI, their files remain theirs.

User-owned storage  ↓  Artifacts  ↓  References + provenance  ↓  MetaopAI KRL
Fig. 03 — Bring Your Own Storage. Files stay with the user; MetaopAI keeps the knowledge that references them.
Aligned incentives

Privacy is one benefit. Aligned incentives are another.

Centralized storage creates cost and responsibility — storage, security, retention, backup, deletion, and incident-response overhead. Users and enterprises already have an incentive to retain control of their own artifacts and intellectual property. MetaopAI has an incentive not to unnecessarily duplicate custody of that data. That alignment is intentional. Users keep the artifacts. MetaopAI keeps the context.

06 — Bring Your Own AI
Bring Your Own AI

The memory should outlive the provider.

Because memory is maintained above the model, a user can change reasoning providers without rebuilding their accumulated context. The same KRL can support reasoning through MetaopAI’s included model, a supported provider using the user’s own API key, or a self-hosted model.

The providers are not identical — they can differ in reasoning quality, cost, speed, context capacity, multimodal support, and tools. But they can perform the same architectural role: reason over context assembled by the application.

KRL  ↓  Composed context  ↓  Router  →  MetaopAI model  ·  BYO API provider  ·  Self-hosted model
Fig. 04 — Provider-neutral routing. One memory controller. Many possible reasoning engines.
07 — Bring Your Own LLM
Bring Your Own LLM

Your model. Your hardware. Same memory.

The MetaopAI Thin Client extends the same architecture to locally hosted models. Prompts issued from the MetaopAI web or mobile app route through an outbound, encrypted connection to a model running on the user’s own hardware, and the reasoning happens locally.

The local model does not need direct ownership of the KRL or the user’s storage. It receives the context required for the current inference operation. That keeps the reasoning engine separate from the memory and data layers.

MetaopAI KRL  ↓  Context composition  ↓  Thin client  ↓  Local runtime  ↓  User-selected LLM
Fig. 05 — The Thin Client. Memory and storage stay above; reasoning runs below, on user hardware.
Read how the thin client works
08 — The architecture in one view
The architecture in one view

Three layers. Separate responsibilities.

One coherent split. Files belong to the user, cognition belongs to MetaopAI, reasoning belongs to whichever model the user chooses. Each layer can change independently — the invariant is the boundary between them.

Layer 01

Artifact layer

Owned by the user

Files, documents, notes, media, and intellectual property remain in user-controlled storage.

Layer 02

Cognition layer

Managed by MetaopAI

Memory, provenance, retrieval, patterns, policy, context composition, and routing.

Layer 03

Reasoning layer

Selected by the user

MetaopAI model, BYO API provider, or self-hosted LLM — interchangeable without rebuilding memory.

You own the artifacts.
MetaopAI manages the context.
You choose the reasoning.
That is the architecture.
See the product tour
09 — Read deeper
The whitepapers

Four views. One product.

The complete reference, plus three focused cuts — a product walkthrough, an investor view, and a technical deep-dive. Pick the read that fits.

01 — Unified Everyone

Full Whitepaper

The complete merge. Positioning, philosophy, the cognition substrate, the orchestrator, the pattern engine, safety, and economics — the whole picture in one document.

97 pages PDF
Read the full whitepaper 02 — Focused Product & curious readers

Product View

What the product is and how it feels to use. Spaces, entities, the profile, the ten chat surfaces, and the ontology that ties every screen back to one substrate.

45 pages PDF
Read the product view 03 — Focused Investors & advisors

Investor View

Positioning, defensibility, and the economics of pattern-not-verdict AI. The structural moats, the unit-economics math, and the honest disclosures.

51 pages PDF
Read the investor view 04 — Focused Engineers & technical readers

Technical Reference

Schema, pipeline, latency profile, eval roadmap, and deployment specifics. The KRL matrix, the extraction pipeline, the orchestrator, and the safety module in implementation detail.

63 pages PDF
Read the technical reference