OMIR is the open, friendly memory format for agents: the standard way to write down, share, and preserve what an intelligent system remembers.
Modeled after FHIR's resource-oriented clarity, OMIR makes agent memory portable, inspectable, and interoperable without sacrificing the real-world complexity of forgetting, source trust, and temporal context.
Why this spec is necessary
Modern agents already speak to each other over MCP and A2A. But once memory leaves an agent and lands on disk, there has been no shared standard for what that memory should look like.
- Different systems call the same concept by different names.
- Memory is more than text: it has confidence, decay, provenance, and relationships.
- Without a shared format, hand-offs become fragile, and migrations become expensive.
OMIR solves that gap by defining a stable, vendor-neutral document format for memory at rest — the same way FHIR defined the document model that made healthcare data portable.
What OMIR aims to do
1. Make memory portable
OMIR describes memory as a Bundle of typed Resources. That Bundle can be exported, shared, archived, and consumed by any OMIR-compatible system.
2. Keep the core small
The spec captures the most useful fields for the majority of implementations, while still letting systems include extra data through extensions.
3. Preserve real memory behavior
Fields for decay, tiering, relationship strength, and invalidation make forgetting and salience first-class, not optional.
4. Support honest evolution
OMIR uses a maturity model so implementers can trust which resources are stable and which are still evolving.
Why this is hard — and how OMIR makes it easier
Agent memory is not just a log of text or a simple record. It is a live structure with:
- temporal decay and anchoring
- relationships between concepts
- multiple memory tiers
- trust and provenance
- future intentions and invalidation
OMIR accepts that difficulty up front. The spec does not pretend memory is easy. It gives you:
- a resource model that is grounded and familiar
- clear rules for references and containment
- a strict core plus an extension mechanism
- a schema-driven contract you can implement against immediately
Logical sections for fast adoption
New developers can adopt OMIR in clear stages. Start small, then grow with confidence.
- Bundle: every OMIR document is a `Bundle`. It is the container for the data you exchange.
- MemoryRecord: capture what was remembered, with timestamp, confidence, decay, and provenance.
- Entity: name the people, places, concepts, and things your system extracts from memory.
- Relationship: connect entities with directed edges and strength values.
- Episode: represent bounded experiences that explain how records and entities relate.
Once the core is in place, add your implementation-specific values using `extension[]` rather than inventing new top-level fields.
How a new developer can make leaps and bounds
If you are just starting, the schema is your fastest path. It gives you a ready-made domain model so you don’t have to design memory from scratch.
- Use the JSON Schema under `schemas/` as the authoritative field list.
- Build your first `.omir` file as a `Bundle` of `MemoryRecord` and `Entity` resources.
- Link resources through typed references like `Entity/jane`.
- Keep unknown extensions safe: consumers ignore unknown extensions, so you can innovate without breaking compatibility.
- Check maturity levels in `meta.maturity` before depending on a resource shape.
This means you can jump from a prototype to a shareable, standard-compliant export in a few days instead of weeks of custom schema design.
Fast adoption checklist
- Read the schema for the resources you need.
- Create a `Bundle` document with an `entry` array.
- Implement `MemoryRecord` first, then add `Entity` and `Relationship`.
- Use `extension[]` for anything outside the core model.
- Validate with a schema-aware tool before sharing your `.omir` file.
Where to go next
Once your first OMIR document works, the next step is to explore:
- Overview — the full scope of OMIR.
- Design Principles — why the spec is shaped this way.
- Extensions — how to keep the core stable while innovating.
- Conformance — what makes a Bundle valid.