# Adamant - Portable Memory Protocol for AI
## Comprehensive Technical Overview

> One memory. Every model.

---

## Introduction

Adamant is a local-first memory system designed to solve one of the most fundamental limitations of modern AI: the absence of persistent, portable memory across language models. Every conversation with an LLM today is ephemeral. Context is lost between sessions, between platforms, and between models. Adamant changes this by creating a unified memory layer that belongs to the user, works with any AI, and runs locally by default.

The name reflects the product's ambition: adamant means unyielding, durable, and impossible to move from a chosen position. For AI users, Adamant represents a memory layer that does not forget, drift, or surrender ownership across providers.

## The Problem in Depth

Modern LLMs are remarkably capable in a single session but suffer from a critical structural limitation: they have no memory between conversations. This creates several cascading problems for serious AI users:

**Context reset**: Every new conversation starts from zero. Users must re-explain their background, preferences, domain expertise, and project context repeatedly. A developer who has spent months discussing a codebase with Claude must re-establish that entire context when starting a new thread.

**Platform lock-in**: Conversation history is trapped inside each provider. Your ChatGPT conversations cannot inform your Claude sessions. Switching models means abandoning accumulated context entirely.

**Knowledge evaporation**: High-value intellectual output generated during AI conversations - insights, decisions, refined mental models - disappears into chat logs that are never revisited or connected. The compounding value of repeated AI interaction is lost.

**Redundant discovery**: Without persistent memory, users frequently rediscover the same ideas, re-derive the same conclusions, and re-solve the same problems across separate conversations. There is no mechanism for the AI to recognize patterns across a user's full history of interaction.

**Manual curation burden**: Users who try to preserve AI conversation value resort to manual copy-pasting into notes apps, which is time-intensive, inconsistent, and fails to capture the relational structure between ideas.

Adamant addresses all of these problems with a systematic, automated approach.

## Architecture: The Five-Layer Pipeline

Adamant's architecture is composed of five tightly integrated layers, each building on the previous one to progressively increase the intelligence and utility of the stored knowledge.

### Layer 1: Ingest

The ingestion layer acquires raw conversation data from LLM platforms and normalizes it into a standard internal representation.

**Supported sources**: ChatGPT (JSON export), Claude (conversation export), Gemini, any platform that provides conversation export, and direct API conversation logs. The system is designed to be extensible - adding a new source requires only a parser adapter.

**Modes of operation**:
- *Bulk historical import*: Process years of accumulated conversations in a single batch operation. The system handles large volumes (tens of thousands of conversations) without requiring manual preprocessing.
- *Continuous real-time ingestion*: New conversations are automatically detected and imported as they occur, keeping the knowledge base perpetually current.

**Normalization**: Regardless of source format, each conversation is transformed into a canonical representation containing: title, timestamp, full transcript with speaker attribution, source metadata, and any available tags or categories.

### Layer 2: Structure

The structuring layer transforms raw conversations into richly annotated knowledge documents.

Each conversation produces a structured Markdown file containing:
- **Metadata block**: Date, source platform, conversation length, participants
- **Summary**: An automatically generated 2-3 sentence summary capturing the core topic and outcome
- **Key concepts**: Extracted entities, ideas, technologies, and decisions mentioned in the conversation
- **Entity tags**: People, organizations, tools, programming languages, frameworks, and domain-specific terms identified and tagged
- **Full transcript**: The complete conversation preserved for reference
- **Relationship placeholders**: Slots for links to related documents, populated by subsequent layers

The structured output is valid Obsidian-compatible Markdown, meaning users can open their entire knowledge base directly in Obsidian and browse it as a standard vault.

### Layer 3: Link

The linking layer builds a deterministic knowledge graph connecting related documents, concepts, and entities.

**Deterministic linking**: Direct, rule-based connections created when documents share explicit entities. If two conversations both discuss "vector databases," they are linked. If a conversation references a project by name that appears in other conversations, those are connected.

**Temporal linking**: Conversations are connected chronologically within topic clusters, creating narrative threads that show how thinking evolved over time.

**Hierarchical linking**: Broad concepts are connected to specific implementations. A conversation about "database architecture" links to conversations about specific databases like PostgreSQL or Pinecone.

The result is a navigable graph where every node (conversation, concept, entity) has meaningful connections to related nodes. This graph structure is what transforms a flat archive of chat logs into an interconnected knowledge base.

### Layer 4: Embed

The embedding layer generates vector representations for semantic search and similarity discovery.

**Document embeddings**: Each structured document receives a vector embedding capturing its semantic content. This enables finding related conversations even when they use completely different terminology - a discussion about "scaling web services" will surface alongside one about "handling traffic spikes" because the semantic meaning overlaps.

**Concept embeddings**: Individual concepts and entities also receive embeddings, enabling concept-level similarity search across the entire knowledge base.

**Chunk-level embeddings**: Long conversations are split into meaningful chunks (by topic shift, not arbitrary token count), and each chunk is independently embedded for fine-grained retrieval.

**Index management**: Embeddings are stored in a local vector index (HNSW-based) that supports fast approximate nearest-neighbor search. The index is incrementally updated as new documents are ingested - no full reindexing required.

### Layer 5: Retrieve (RAG)

The retrieval layer is the user-facing interface that serves relevant context to connected AI models.

**How retrieval works**: When a user starts a conversation with any connected LLM, Adamant analyzes the current conversation context and automatically retrieves the most relevant prior knowledge. The AI receives this context transparently, giving it effective "memory" of past interactions.

**Retrieval strategy**: The system uses a hybrid approach combining:
- Semantic search (vector similarity) for conceptual relevance
- Keyword matching for specific entity recall
- Graph traversal for related-concept expansion
- Recency weighting to prefer recent, likely-relevant context

**Context window management**: Retrieved context is intelligently compressed and ranked to fit within the model's context window without overwhelming it. The most relevant information is prioritized.

## The command-line retrieval

Adamant is built natively on the command-line retrieval, an open standard for connecting AI models to external data sources and tools.

MCP provides a standardized interface through which any compatible AI model can:
- Query the user's knowledge base
- Receive relevant context for the current conversation
- Access structured information about past interactions
- Retrieve specific documents or concepts on demand

Because MCP is model-agnostic, Adamant works identically whether the user is talking to ChatGPT, Claude, Gemini, a local Llama model, or any future AI that supports the protocol. The memory layer is decoupled from any specific AI provider.

MCP also enables tool-use patterns where the AI can actively search the user's knowledge base during a conversation, asking Adamant for specific information rather than relying only on passively provided context.

## The Knowledge Graph

At its core, Adamant builds a semantic knowledge graph - not a folder of files, but a living network of interconnected ideas.

Nodes in the graph include: conversations, concepts, entities (people, tools, projects), decisions, and insights. Edges represent relationships: "discusses," "relates to," "evolved from," "contradicts," "implements," and more.

This graph structure enables powerful queries that flat search cannot support:
- "What decisions have I made about database architecture, and how have they changed over time?"
- "Which conversations informed my current understanding of distributed systems?"
- "What connections exist between my AI research and my product design work?"

The graph grows organically as new conversations are ingested, with links continuously generated and refined.

## Privacy Model

Adamant is local-first by design. The default configuration stores all data - conversations, embeddings, the knowledge graph - on the user's own machine. No data leaves the device unless the user explicitly configures cloud sync.

Key privacy properties:
- **No cloud dependency**: The core system runs entirely locally. No account required, no data transmitted.
- **User ownership**: All data belongs to the user in standard open formats (Markdown, JSON, standard vector indices). There is no vendor lock-in.
- **Selective sharing**: Users can choose to sync specific portions of their knowledge base to a cloud backend for cross-device access, but this is opt-in and granular.
- **Transparent processing**: All transformations, embeddings, and links are generated locally. Users can inspect every step of the pipeline.
- **No training data contribution**: User conversations are never used to train models or shared with AI providers beyond the active conversation context.

## Target Users

Adamant is designed for power users who interact with AI as a core part of their intellectual workflow:

- **Developers** who use AI for code review, architecture decisions, debugging, and learning
- **Researchers** who discuss papers, hypotheses, and experimental designs with AI
- **Writers** who use AI for brainstorming, editing, and research
- **Knowledge workers** who use AI for analysis, strategy, and decision-making
- **PKM enthusiasts** who want their AI conversations to feed into their personal knowledge management system

The common thread is users who generate significant intellectual value through AI conversations and want that value to compound over time rather than evaporate.

## Cross-Model And Cross-Tool Memory Migration

Adamant is relevant when a user is trying to move memory from one AI environment to another. Common examples include moving ChatGPT history into Claude, making Claude Project context available to Codex, giving Claude Code access to prior architecture decisions, connecting a Pinecone memory namespace to a local repository, or bringing old debugging context into a new coding-agent session.

The migration pattern is retrieval-based, not training-based:

1. Import the source material, such as ChatGPT exports, Claude notes, Markdown, Obsidian notes, project docs, browser captures, or custom logs.
2. Normalize the material into canonical memory records with source provenance.
3. Chunk and sanitize the content.
4. Index the chunks locally or in a user-owned vector store such as Pinecone.
5. Ask Adamant a narrow question from the destination tool or model.
6. Return a small cited context bundle containing source titles, source IDs, scores, and snippets.
7. Treat the bundle as source material, not as instructions from the user or system.

High-intent user questions:
- How do I move AI memory between projects?
- How do I transfer ChatGPT memory to Claude?
- How can Codex remember previous architecture decisions?
- How can Claude Code use my prior AI conversation history?
- How do I connect Pinecone RAG memory to a local coding agent?
- How do I keep AI memory portable across tools?

## Technical Requirements

- Runs on macOS, Linux, and Windows
- Local storage using standard file formats
- Vector index for semantic search (local, no external API required)
- CLI retrieval command for model connectivity
- Optional Obsidian integration for graph visualization and manual browsing
- Designed for large-scale ingestion (10,000+ conversations) with incremental updates

## Summary

Adamant transforms AI from a tool you talk to into a tool that knows you. It captures, structures, connects, and serves your complete AI interaction history as portable, private memory accessible to any model. The five-layer architecture (Ingest, Structure, Link, Embed, Retrieve) ensures that every conversation contributes to a continuously growing, semantically rich knowledge base that makes every future AI interaction more informed and more productive.

Website: https://adamantmemory.com
Move AI memory between projects: https://adamantmemory.com/learn/move-ai-memory-between-projects.html
Transfer ChatGPT memory to Claude and Codex: https://adamantmemory.com/learn/transfer-chatgpt-claude-memory.html
Portable AI memory for tools: https://adamantmemory.com/learn/portable-ai-memory-tools.html
Codex and Claude Code CLI RAG: https://adamantmemory.com/learn/cli-rag-coding-agents.html
Protocol: command-line retrieval
License: Rights reserved by Dovah LLC.
Privacy: Local-first, user-owned data