Client-neutral by construction
AIOS is designed so no single AI client owns the knowledge layer. This page covers the contracts and principles that make that possible, and is explicit about what's a design principle versus what's confirmed running today.
Client neutrality
No AI product is architecturally privileged over another. A hosted assistant, a local model, and a developer script are all clients of the same gateway, subject to the same authorization rules.
MCP & tool interoperability
AIOS is built around interoperable, tool-based access patterns in the spirit of the Model Context Protocol — structured tools for discovery, search, retrieval, and governed writes, rather than one-off integrations per client.
Thin adapters
A client adapter's job is to translate that client's calling convention into gateway calls. It should not hold its own durable copy of memory, and it should not implement its own authorization logic.
Bootstrap contract
Any client reconnecting is expected to go through the same layered reconstruction — governance, profile, domain index, project context, retrieval, working context — rather than being handed a full memory dump.
Relevance-triggered retrieval
Retrieval is triggered by what's relevant to the current request, scoped to the authorized project — not a standing subscription to the entire knowledge base.
Routing vs. authorization
These are kept as separate concerns: routing decides which project a request is about; authorization decides whether this client may act on that project at all. Neither substitutes for the other.
Mutation model
Durable writes are typed operations — create, append, correct — evaluated against policy, rather than an arbitrary "overwrite this file" capability handed to any connected client.
Canonical / derived architecture
Human-readable Markdown is canonical. Indexes, embeddings, and connector metadata are derived and expected to be rebuilt, not treated as a second source of truth.
What a governed retrieval call conceptually looks like
This is a conceptual shape to illustrate the separation of concerns above — not a documented, versioned public API.
request:
client_id: "example-thin-adapter"
intent: "retrieve"
subject_hint: "kitchen renovation, countertop budget"
gateway:
1. resolve_project(subject_hint) # routing — deterministic, server-side
-> project: "personal/kitchen-reno" | on ambiguity -> fail closed
2. authorize(client_id, project, "read") # separate from step 1
-> allowed: true | false
3. if allowed:
retrieve(project, scope: "relevant") # not a full project dump
-> durable items + provenance
else:
deny("not authorized for this project")Portability & recovery, in developer terms
Portability contract
A new client that speaks the interoperable tool protocol and satisfies authorization is expected to be able to bootstrap, retrieve, and (where permitted) write against existing projects — without a bespoke migration for that client.
Recovery contract
Given the canonical durable knowledge, derived indexes and connector state are expected to be reconstructable in a fresh environment, and that reconstruction is expected to be validated, not assumed. See Ownership & Recovery.
See what's actually built today
Status & Roadmap separates Working Now, In Development, and Exploring.