NNunchi AI
← 블로그로 돌아가기

The Nunchi AI Memory Ecosystem

AI agents are getting good at using tools. They can search the web, call APIs, write code, manage files. But ask any agent what you discussed last week, what decisions you've made across projects, or how your preferences have evolved — and you get nothing.

The tool layer has MCP. The collaboration layer has A2A. The memory layer has nothing. Every agent starts from zero, every session.

Nunchi AI exists to build that missing layer.

The Problem in One Sentence

Your AI's memory is trapped — in a single tool, a single session, a single vendor's proprietary format — and it disappears the moment you switch contexts.

This isn't a minor inconvenience. Memory is what transforms a generic AI into your AI. Without persistent, portable memory, every agent is trivially replaceable by any competitor with the same model access and the same tool integrations. Memory is the moat.

And right now, every attempt to solve this — Claude's built-in memory, ChatGPT's memory, Mem0, Zep, MemPalace — locks your knowledge into one platform. Switch tools, lose your history. Switch models, start over. This is the same lock-in pattern we've seen before with data silos, except the data being siloed is your accumulated intelligence.

Five Components, One Architecture

The Nunchi AI ecosystem is built on a simple conviction: memory should be infrastructure, not a feature of any single product.

The ecosystem has five components across four layers. Each does one job. Together, they form a complete memory stack that no single product owns end-to-end.

<!-- [Architecture diagram: nunchiai-ecosystem-architecture.svg] -->

Layer 1: Synapsis Engine — The Foundation

Every memory system needs to answer one question first: how do you turn a messy, sprawling conversation into structured knowledge?

Synapsis is the atomization engine that answers this. It takes raw conversations and breaks them into discrete knowledge units — atoms — each with type, confidence, temporal scope, domain, and relational links to other atoms. A single conversation might produce atoms like:

  • Decision: "Migrated auth from Auth0 to Clerk" (confidence: 0.95, valid_from: 2026-01-15)
  • Preference: "User prefers Postgres for projects expecting concurrent writes" (confidence: 0.8)
  • Relationship: the decision atom updates a previous atom about Auth0 being the current provider

This is fundamentally different from storing raw conversation text and searching it later. Raw storage optimizes for retrieval — "find the conversation where we discussed auth." Atomization optimizes for understanding — "what is our current auth provider, and why did we choose it?"

Synapsis powers all three backends in the ecosystem. It's the shared foundation that ensures consistent knowledge representation regardless of which product you're using.

Three design laws emerged from extensive benchmarking (six iterations of LongMemEval testing):

1. Never delete atoms — invalidate them with temporal markers 2. Never reorder atoms — insertion order carries implicit temporal signal 3. Never inject non-similarity signals into retrieval scores — keep the recall path clean

These aren't theoretical principles. They're empirical findings from production testing.

Layer 2: AMCP — The Contract

AMCP (Agent Memory Continuity Protocol) is the open standard that sits between harnesses and backends. Apache 2.0 licensed. It defines:

  • A standard atom shape for knowledge units
  • Scope and visibility controls (project, user, session)
  • Recall interface with similarity search and scope filtering
  • Export/import in a portable JSONL format
  • Backend-agnostic transport

The key insight: memory should be a protocol, not a product. Just as MCP standardized how agents connect to tools — so any agent can use any tool — AMCP standardizes how agents connect to memory — so any harness can use any memory backend.

This means:

  • You can switch from local storage to a hosted backend with one command
  • You can export your entire memory and import it into a different system
  • You can migrate between backends without losing knowledge
  • A third-party harness can integrate with AMCP without knowing anything about Nexus, Norfolk, or MaaS specifically

AMCP is the answer to the portability problem. Your memory belongs to you, not to your tool vendor.

Spec: github.com/goldberg-aria/amcp

Layer 3: Three Backends, Three Audiences

All three backends implement AMCP and run on Synapsis. They serve different users with different needs.

Nexus is the reference backend for agents and developers. It's where the atomization pipeline, the recall algorithms, and the benchmarking happen first. If you're building an agent that needs persistent memory, Nexus is the backend you point it at. It exposes AMCP endpoints (/v1/amcp/remember, /v1/amcp/recall, /v1/amcp/export, /v1/amcp/import) and handles the complexity of atom storage, relation management, and scope-aware retrieval.

Norfolk is the personal knowledge backend. Where Nexus is optimized for agent workflows, Norfolk is optimized for a human's lifetime of knowledge — notes, conversations, documents, and the connections between them. The CLI-first architecture uses the server for storage and search, the web interface for viewing and organizing, and mobile for collecting. Citation graphs and provenance grading ensure you know where every piece of knowledge came from.

MaaS (Memory as a Service) is the enterprise deployment model. It provides the same atomization and recall capabilities as Nexus, but with multi-tenant isolation, team-level scoping, and enterprise knowledge API paths. Products like TravelSpeak (a language learning app) and IndiePulse (an AI-operated editorial magazine) run on MaaS to give their users persistent, invisible memory that improves the experience over time without the user ever seeing the machinery.

Three products. One atom shape. One protocol. One engine.

Layer 4: 3122 — The Reference Client

A protocol without a working client is just a PDF. 3122 is the proof that AMCP works in practice.

3122 is a terminal-first, model-neutral coding harness. No built-in model — you bring your own via API (Anthropic, OpenAI, Ollama, and more) or use authenticated adapters for Claude Code and Codex. The harness handles everything else: prompts, permissions, tool execution, session continuity, and backend selection.

The critical design decision in 3122 is the explicit separation between two types of state:

Continuity Runtime State stays local in the harness:

  • Session transcripts (JSONL)
  • Trajectory compression (goal → attempt → failure → verification → next-step)
  • Handoff snapshots for model switching
  • File-level working memory
  • Skill candidate detection from repeated workflows

Portable Memory flows through AMCP:

  • One atom shape across all backends
  • local-amcp: SQLite on your machine
  • nexus-cloud: hosted backend over Nexus
  • third-party-amcp: extension slot for anything that speaks the protocol

The harness makes all the context management decisions — what to include in the prompt, how to budget tokens as sessions grow long, what to preserve during compaction. But the results of those decisions flow into portable memory. Delete the workspace, rebuild, reconnect to the same backend — your knowledge is intact.

3122 memory export --format amcp-jsonl --output my-knowledge.jsonl
3122 memory migrate --from local-amcp --to nexus-cloud

Repo: github.com/goldberg-aria/3122-harness

Why This Architecture

The industry conversation about agent memory is currently stuck between two positions.

One camp says memory must be embedded in the harness — it's too intimately tied to context management to separate. This is the Letta/MemGPT view. The problem: your memory dies with your harness choice.

The other camp says just make the harness open source. This is the LangChain/Deep Agents view. The problem: open source harnesses still use proprietary memory formats. Switch harnesses, write custom ETL, and hope nothing is lost in translation.

The Nunchi AI ecosystem takes a third position: separate the concerns, standardize the interface.

The harness owns context management. The memory layer owns persistence and recall. AMCP connects them. Neither creates lock-in because neither is a closed system.

This is the same pattern that built the internet. HTTP didn't require open-source browsers. It required an open protocol that any browser could implement. AMCP is that protocol for agent memory.

Current Status

  • AMCP: published, Apache 2.0, on GitHub
  • Nexus: production backend, LongMemEval benchmarked (83.2% with atomization pipeline, six iterations of empirical refinement)
  • 3122: functional harness with multi-provider support, AMCP portable memory, trajectory indexing, and model-switch handoffs, on GitHub
  • Norfolk: CLI architecture finalized, API spec and implementation plan in progress
  • MaaS: powering TravelSpeak and IndiePulse in production

What's Next

The separation between harness and memory works. The next phase is making the boundary richer:

Trajectory auto-promotion — successful work patterns in the harness automatically become portable memory atoms, no manual save required.

Budget-negotiated recall — the harness tells the memory backend "I have 2,000 tokens of budget, give me the most critical atoms" instead of fetching everything and truncating client-side.

Compaction checkpoints — when the harness compacts context, it tells AMCP what was dropped, making invisible decisions visible and recoverable.

Capability advertisement — AMCP backends declare what they support at connection time, so minimal third-party implementations still work while full implementations unlock advanced features.

The Bet

We're betting that memory becomes the most important layer in the agent stack. Tools are commoditized — any agent can call any API. Models are commoditized — they're converging in capability and competing on price. What's not commoditized is accumulated understanding — the knowledge an agent builds about you, your projects, your team, your preferences, over months and years of interaction.

That knowledge should be yours. Not your model provider's. Not your harness vendor's. Not locked in a proprietary database on someone else's server.

That's what Nunchi AI is building.

---

AMCP: [github.com/goldberg-aria/amcp](https://github.com/goldberg-aria/amcp) 3122: [github.com/goldberg-aria/3122-harness](https://github.com/goldberg-aria/3122-harness) Nunchi AI: [nunchiai.com](https://nunchiai.com)