6,000 downloads in three weeks: what we learned building agent memory infrastructure

The problem we set out to solve

Multi-agent AI systems have a memory problem that nobody talks about plainly. When two agents work on the same project, the second agent does not know what the first one learned. When a long-running agent is killed and restarted, it loses its working state. When an agent generates a plan, a draft, or a finding in one session, that output vanishes when the context window clears.

The standard responses to this problem are well-known: stuff everything into the context window until it overflows, embed everything into a vector database and hope similarity retrieval finds the right thing, or use whatever memory the agent framework bundles. None of these are wrong. They are wrong for this specific job.

What was missing was an infrastructure layer that treats memory as a first-class system concern: persistent, identity-addressed, conflict-aware, and visible to operators. The kind of thing that, once you have it, you wonder how you ran serious agent workflows without it.

What we built

Iranti is a local-first memory server for multi-agent AI systems. The backend is PostgreSQL with pgvector. The protocol layer is MCP (Model Context Protocol), which means any MCP-compatible agent host can connect without a custom adapter. The runtime exposes a structured set of tools that implement a specific memory discipline, not just storage primitives.

The design is identity-first. Every fact is addressed by an entity and a key:project/my-api +deployment_status. Retrieval is deterministic: same address, same result. No similarity threshold, no probabilistic miss. Vector search exists for when the exact key is unknown, but the primary path is direct addressed lookup.

Four internal components handle different concerns. The Librarian owns all writes: it detects conflicts when two agents write different values to the same key and resolves them by confidence, recency, and source identity. The Attendant owns memory injection: it decides what facts to surface to an agent before each reply, based on task context. The Archivist handles lifecycle: archiving superseded facts, running compaction, maintaining the temporal record. The Resolutionist handles escalation when the Librarian cannot resolve a conflict automatically.

The full setup for Claude Code is one command:

The benchmark data

We ran two benchmark suites before publishing. The first is competitive: Iranti against Mem0, Shodh, and Graphiti across four scenarios covering same-session recall, cross-session persistence, shared pool behavior, and conflict resolution. The second is internal: 13 tests covering the Iranti-specific capabilities that competitive systems do not even attempt.

The 20/20 persistence score matters because process isolation is the failure mode that actually hurts in practice. Starting a new terminal session, switching from Claude Code to Codex, restarting an agent after a crash: all of these kill in-memory state. The 20 reruns span cold boots, process restarts, and session handoffs. Every fact written before the restart was retrievable after.

The 14/14 coordination score covers scenarios where two or more agents run concurrently or sequentially and need to share state without explicit handoff. Agent A writes a discovery. Agent B picks up the task from a different process. The question is whether B knows what A learned. In all 14 scenarios, it did.

What surprised us about the adoption

We expected slow adoption. Infrastructure is hard to sell. It does not have a dramatic demo. The value only shows up after you have run a few multi-agent workflows and experienced the re-briefing problem firsthand. We thought we would spend the first few months explaining why this category exists.

We did not have to. Engineers who found Iranti already knew the problem. They were already running Claude Code and Codex on the same projects. They were already copying context between tools by hand. They were already losing work when agents restarted. The install rate among people who landed on the benchmarks page was notably high: they checked the evidence first, then installed.

The three-tool setup pattern was also more common than we predicted. We assumed most installs would be single-agent users who wanted cross-session persistence. What we found was that a meaningful fraction of early adopters were running at least two of Claude Code, Codex, and GitHub Copilot on the same project and wanted all three to share the same memory layer. That drove the Copilot integration up the roadmap.

The download numbers also arrived steadily, not in a spike. There was no launch event. The curve was organic search and word of mouth. That is a better signal than a Product Hunt spike: it means people with the specific problem found the specific solution.

What the adoption tells us about the market

The agent tooling market is further along than the public discourse suggests. Engineers are not experimenting with multi-agent systems in sandboxes. They are running them on real projects and hitting real infrastructure gaps. The gap between "agent frameworks are maturing" and "agent infrastructure exists" is where a lot of practical pain lives right now.

Memory is one of the clearest gaps. Compute is solved: you can spin up as many parallel agents as you can afford. Coordination is partially solved: frameworks handle task routing and handoffs at the framework level. Memory is not solved: every agent starts blind unless you explicitly re-brief it, and cross-process shared state has no standard layer underneath it.

6,000 downloads does not prove product-market fit. It does prove that the problem is real, that engineers are actively looking for solutions, and that they will install something that looks credible and backs its claims with benchmark data. That is enough signal to keep building.

What is coming next

v0.3.21 is in progress. The main additions are iranti list-rules and iranti delete-rule for managing user operating rules from the CLI. User operating rules, introduced in v0.3.20, let you write policy rules that surface only when the agent is about to do something relevant: a rule about how to handle releases only fires when release keywords appear in context, not on every turn.

Beyond v0.3.21: MCP registry submissions for Smithery and Glama, remote and team mode for multi-machine setups, and continued hardening of the Copilot integration. The local-first design will not change: the default path should run with no external dependencies beyond Postgres, and that stays true.

If you are running multi-agent workflows and hitting the re-briefing problem, Iranti is built for exactly that. The feedback we most want right now is which failure modes you are hitting that Iranti does not yet cover.