A minimal, vendor-neutral JSON format for carrying AI, assistant, and agent memory between tools.
Memory is becoming the most valuable thing an AI system holds about you — and today it is trapped. Every assistant, agent framework, and memory store keeps it in a private shape, behind a private runtime. Move tools and you start over.
Open Memory Interchange (OMI-AI) is a small file format whose only job is portability:
A producer can emit an OMI-AI file, and a consumer can read it without sharing a storage engine, query language, governance model, ontology, vector index, or vendor-specific runtime.
It is deliberately thin. OMI-AI defines a file envelope, a human-readable memory record, a
handful of optional descriptive fields, and an extension object (ext) for everything above the
floor — in two serializations of the same model: a single JSON document (.omi.json) and a JSON
Lines streaming form (.omi.jsonl).
The core invariant is simple:
A floor-only OMI-AI record remains legible from its
contentalone.
A record may carry type hints, source hints, validity dates, tags, entities, relations, language metadata, and extension profiles. But a consumer that understands none of those still receives a readable memory.
OMI-AI's value is what it leaves out. The format explicitly does not define — and a floor implementation must not require — any of the following:
| Concern | Where it lives instead |
|---|---|
| Query / traversal language | Consumer / runtime |
| Schema, shape, or ontology language | Optional schema profile |
| Governance & lifecycle model | Optional governance profile |
| Integrity / hashing / signatures | Optional integrity profile |
| Embeddings & vector portability | Optional retrieval profile |
| Sync protocol (deltas, tombstones, conflicts) | Optional sync profile |
| Storage engine, index, transport, authz | Out of scope (runtime infra) |
These exclusions are a commitment, not an omission. They are what make OMI-AI small enough to be a shared floor between parties who disagree about everything above it.
The smallest valid file (L0 Core) — every record needs only id, content, and created:
{
"format": "open-memory-interchange",
"version": "0.1",
"memories": [
{
"id": "01JZ0WFR4K2Q6N7S8T9V0ABCDF",
"content": "Prefers direct, critical pushback over hedging.",
"created": "2026-05-01T09:02:11Z"
}
]
}A richer file (L1 Interchange) — an envelope with a subject and generation metadata, wrapping a fully-described record:
{
"format": "open-memory-interchange",
"version": "0.1",
"serialization": "json",
"subject": { "id": "user-123", "type": "person", "label": "Sam" },
"generated_at": "2026-06-06T09:00:00Z",
"generator": "example-tool/1.4",
"memories": [
{
"id": "01JZ0WFR4K2Q6N7S8T9V0ABCDF",
"content": "Prefers direct, critical pushback over hedging.",
"type": "semantic",
"created": "2026-05-01T09:02:11Z",
"confidence": 0.96,
"lang": "en",
"tags": ["communication", "preference"],
"source": { "platform": "example-chat", "ref": "session-882", "method": "extracted" },
"valid_from": "2026-05-01",
"valid_to": null
}
]
}OMI-AI defines two data conformance levels, validated by the schemas in schema/:
| Level | Name | Requirements |
|---|---|---|
| L0 | Core | A valid envelope; every record has id, content, and created. |
| L1 | Interchange | L0, plus: every record has type; record IDs are unique within the file; timestamp fields are valid RFC 3339 date-times; valid_from / valid_to are valid dates where present; every record has an effective subject (inherited from the envelope or present on the record). |
A producer should emit L1 unless performing a minimal legacy conversion. A consumer must
accept L0 and should accept L1 — and must not reject a record solely because it carries
optional fields, unknown fields, or unknown ext profiles.
| Extension | Media type | |
|---|---|---|
| Document | .omi.json |
application/vnd.omi+json |
| Streaming | .omi.jsonl |
application/vnd.omi+jsonl |
The JSON Lines form is one record (or envelope-then-records) per line, for large exports and streaming pipelines. Both serializations describe the same model.
This repo is the source of the omi-ai.org site (served via GitHub Pages) and the home of the specification and canonical schemas.
.
├── index.html # Landing page
├── docs/ # Rendered specification (multi-page)
├── schema/ # Canonical JSON Schemas — omi-l0, omi-l1 (Draft 2020-12)
├── downloads/ # Spec + schemas, packaged for download
├── assets/ # Site styles and scripts
├── favicon.svg · *.png # Brand icons + web manifest
├── CNAME · .nojekyll # GitHub Pages configuration
├── LICENSE · NOTICE # Apache-2.0
└── README.md
Note
The schema $id URLs in this draft (https://open-memory-interchange.example/...) are
intentional placeholders and will be replaced with final governance-domain URLs before a stable
release. They do not need to resolve to validate a file.
This is a public review draft (OMI-AI/0.1-draft), not a stable 1.0 release. The format and
even its name are provisional, and the design is intended for neutral stewardship — a memory
portability floor that adopters do not perceive as one author's front door is the floor most likely
to be adopted.
A stable 1.0 should require:
- versioned schemas;
- conformance fixtures;
- at least two independent import/export implementations;
- an extension/profile registry policy;
- declared license and governance (this repo declares Apache-2.0);
- a resolved publication name, domain, and repository.
OMI-AI is at the stage where the most valuable contribution is scrutiny: where does the floor leak, where is it too thin, and what belongs in a profile rather than the core?
- Read the spec: omi-ai.org/docs
- Open an issue to propose changes, report ambiguities, or float a profile idea.
- Build an adapter or implementation and tell us what the format made hard — real import/export experience is what moves this toward 1.0.
Contributions are accepted under the terms of the project license (Apache-2.0), per section 5 of the LICENSE.
Licensed under the Apache License, Version 2.0. See LICENSE and NOTICE.
Unless you explicitly state otherwise, any contribution you intentionally submit for inclusion in the work shall be licensed as above, without additional terms or conditions.