Persistent session-aware context and tools across every AI-client you use or delegated agent.
At its core mippi is four infrastructure primitives and a coordination layer.
The primitives
Transport
A proxy layer that proxies mippi's capabilities to different transport protocols. Now MCP, CLI, RestAPI, prepared for whatever the future brings (eg A2A). Full capabilities, adapted and optimized per protocol.
Connectors
A single place where you set up all the connections (inbound, outbound, sync, realtime) that all your AI/agents might need. Not per client. Once for all of them. Includes a credential vault. Think Zapier/n8n.
Shared Memory
One shared memory layer for all your clients. Knowledge graph (in a per-user SQLite) with continuous write-behind backup to S3-compatible storage as human-readable flat files. Graph rebuildable from flat files alone; the metadata lives in the files themselves. Fully exportable, JSON-LD compatible. Think PKM, but designed agent-first, not human-first.
Execution
V8 isolates (JS/TS, Python) and full container VMs. Gives any LLM/client full power. Combines with Connectors to let your AI's do anything internally or externally.
The coordination layer
Our design philosophy/challenge: 1,000 AI/agents, from differing intelligence capability and degree of specialisation, concurrently working with 1 mippi instance for 1 human principal with a knowledge graph containing 1M+ nodes and 1,000+ active connectors. We try to solve for this using:
Connect in 30 seconds.
Add mippi to any MCP-compatible client. One config block.
{
"mcpServers": {
"mippi": {
"url": "https://mippi.ai/mcp"
}
}
}Early alpha. MCP is the primary interface. The API surface is not frozen and will change between releases. MCP absorbs most of this, so your config stays stable. CLI and REST API coming with beta.
How mippi compares.
Every competitor in the AI memory space runs LLMs server-side: embedding, summarization, or retrieval. mippi doesn't. That's the fundamental architectural bet.
| mıppı | Mem0, Letta, Cognee, Zep | |
|---|---|---|
| Server-side LLM | None. Your AI does the thinking. mippi stores and serves the result. | Required. Ingestion runs LLM extraction, embedding, and summarization. |
| Switching providers | No re-processing. Context is structured text, not vectors. | Multi-provider, but switching embedding models means re-processing your entire memory store. |
| Your cost at scale | Zero on mippi’s side. Use your existing AI subscription. | LLM inference on every write. Cost grows with your memory. |
| Data isolation | Per-user database. Your own storage, your own files. | Shared infrastructure with logical tenant separation. |
| Observability | Deterministic. Every retrieval path traceable without LLM reasoning steps. | LLM-driven extraction and ranking. Results visible, but the reasoning that produced them is non-deterministic. |
Mippi use case examples
Cross-tool development
Design in Claude. Implement in Cursor. Debug in Codex. Same project context across all three. Decisions made in one session carry forward to the next, regardless of which tool you pick up. No copy-pasting context. No re-explaining the architecture.
Research to reference
Save documentation, API references, architecture decisions. They're structured and tagged, searchable across months of work. Six months later, ask any AI "what did we decide about the auth flow?" and it finds the answer, because the decision is a record in your knowledge graph, linked to everything it touches.
Deliver anywhere
Send a formatted design doc to your Kindle for offline reading. Push a generated report to email. Pipe project updates to your team's feed. Your AI's output shouldn't live and die in a chat window.
Event-driven pipelines
PR merged. Update project context. Notify the team. No manual steps. Connectors and flows turn events into automated sequences that span your tools. The kind of glue work you'd script yourself if you had the time.
Team onboarding
New team member joins. Their AI reads the project's full context: decision log, architecture notes, open threads, and the reasoning behind them. Immediately. No onboarding doc that went stale two sprints ago.
Six bets mippi makes.
Deterministic, not probabilistic
No LLM on the server. The pipeline is testable, predictable, observable. When your AI calls mippi, you can trace the full round-trip in your own logs.
Mippi gets smarter when your AI improves. No model updates on our side. No hidden inference costs that grow with scale.
Quad-agnostic
Mippi doesn't care which model you use, which client you connect from, which transport you prefer, or which provider you pay. Build with Claude today, switch to Gemini tomorrow, run a local model next month. Or all at the same time. The same context and tools for all.
Mippi targets full usability with the lowest-power current-generation models: Claude Haiku-class, Gemini Flash Lite-class.
Everything composes
Memory, delivery, connectors, execution. Built on the same primitives, in the same per-user storage layer. Your delivery receipts are searchable alongside your research notes. Tag a delivery the same way you'd tag a memory. Search works across everything.
You compose on it too. Workflows, scheduled pipelines, tailored apps with an audience of one. The primitives are yours to wire however you want. Every new pillar inherits the full stack for free.
Agent-native (AX-first)
Every tool and response is designed so that any AI, cold-starting, first time, different model, different intelligence level, can figure out what to do without human help.
The interface is built for AI agents to consume. Humans interact through their AI, not with mippi directly. Zero human intervention is the design target.
Your data, structurally isolated
Per-user storage. Your own bucket, your own files, your own export path. Nobody else's data touches yours. The isolation is architectural, not a permission layer.
Built for 1,000 concurrent agents
When every person has dozens of specialized agents, the memory layer can't be the bottleneck. Collections scope what each agent can see and write. Policy enforces constraints you set once. Scoring ranks what matters for each session. The architecture anticipates this: powerful models for complex reasoning, specialized models for routine tasks, all reading from and writing to the same memory with governance per tier.
The core engineering problem.
Ten million stored records. Every time an AI connects, one question: given everything this person knows, what does this specific session need right now? Distilled into a thousand tokens.
The inputs change every time. Which AI is connecting. Which project's API key. What the user just asked. What collection the session is scoped to. The output is always the same shape: a compressed context briefing with the highest-signal subset of the user's entire memory.
Collections, scoring, and the agent-experience design philosophy exist to answer one question: how do you serve the right context from an ever-growing memory to a thousand different agents?
The graph compounds.
Every new record can relate to every existing record. At 100 records you have a useful notebook. At 10,000 the reactor surfaces connections you forgot existed. At 100,000 it knows your work better than you remember it yourself.
We're honestly unsure whether the growth is exponential. But building mippi with mippi, we're starting to feel graph effects compound in ways we didn't predict. The more you put in, the more it gives back.
Collections govern what agents can do.
Collections scope your memory into workspaces. Each one can carry its own rules. Three layers, each optional:
Instructions
Prose guidance for AI agents. "This collection tracks project decisions. Log the date, the alternatives considered, and the rationale." Every agent reads instructions before its first write. Think of it as a README for a workspace.
Policy
Structural constraints. Allowed record types, required tags, capacity limits. Hard gates reject violations. Soft gates accept with a warning. You set the admission rules once and mippi enforces them on every write, regardless of which AI or model is calling.
Schema
JSON Schema validation on every record. Required fields, format enforcement, per-field error messages on rejection. Subcollections inherit their parent's schema.
Open by default. A new collection has no rules. Add governance when you need it. The strictness scales with the trust tier of the agents writing to it.
Three autonomy tiers.
How much you hand over to your AI is up to you. mippi supports three levels, built on the same primitives.
Client-direct
You talk to Claude Code. Claude Code calls mippi to save context, search memory, send a document. The human initiates. The AI tool-calls. Mippi executes.
Delegated
Scheduled workflows that run without you. Check RSS feeds every morning, summarize new papers, save to a collection, send a digest to your Kindle. When a PR merges, update project context and notify the team. You set the policy. Mippi and your AI follow it.
Autonomous
AI agents with their own mippi sessions. They self-schedule, maintain working memory, report by exception. A research agent monitoring a topic space, surfacing connections you didn't ask for. Governed by collection policy and budget.
The boundary between layers is soft. A Claude Code session running /loop to check a task list every ten minutes is already delegated autonomy. The same primitives compose differently depending on how much control you hand over.
Flat files are the rebuildable truth.
The graph is the power.
Most systems pick one side: graph databases give you powerful queries but lock your data in proprietary storage. Flat file storage is portable and human-readable but has no relationships. Mippi does both.
Your data lives as flat files on S3-compatible storage. Human-readable paths, standard metadata. The knowledge graph (relations, tags, collections, scoring) is an index over those files.
Start building.
Three tools. Thirty seconds to connect. Your memory. Your tools. Your models.
Connect your AI →