Can Multiple AI Agents Share a Single ai‑memory Store?

Yes—akitaonrails/ai‑memory is architected so that any number of AI agents (Claude Code, Codex, Open‑Code, Kiro, and others) can read from and write to the same persistent SQLite database concurrently.

The akitaonrails/ai-memory repository provides a unified memory layer for AI-assisted development. Instead of isolating each tool’s context in separate databases, you can configure multiple AI agents to share a single ai‑memory store, enabling seamless collaboration and session hand‑offs across different tools working on the same project.

How the Shared SQLite Backend Works

Single Database, Multi‑Agent Access

At its core, ai‑memory uses a single SQLite database managed by the ai‑memory‑store crate. All agents connect to this same backend, which scopes data per‑workspace and per‑project while remaining open to any authenticated agent.

In crates/ai-memory-store/src/lib.rs, the store exposes a WriterHandle thread that serializes all write operations. This guarantees that concurrent agents—whether two instances of Claude Code or a mix of Codex and Kiro—never trigger “last‑write‑wins” race conditions. Every upsert travels through this single writer actor, ensuring atomic updates to the shared state.

Project Isolation with Open Collaboration

Rows in the database are uniquely identified by the tuple (workspace_id, project_id, path). This structure keeps projects separate while allowing free collaboration within them.

According to docs/users.md, the schema supports an optional owner_id field per row. When owner_id is set to NULL, the row is shared with the entire project, meaning any agent or human operator can view and edit those pages. This design lets multiple agents work on the same codebase without leaking data into unrelated projects.

Setting Up a Shared ai‑memory Server

You only need to run one ai‑memory daemon per machine or per user. All agents subsequently connect to this instance.

Launch the shared server:

# Starts the daemon on 127.0.0.1:49374 by default

ai-memory serve &

Once the server is active, connect any supported agent by targeting the same project identifier:

# Claude Code session

claude-code --project my-project

# Codex session (in another terminal)

codex --project my-project

# OpenCode or Kiro (configured via environment or CLI)

opencode --project my-project

Because both sessions reference my-project on the same daemon, they immediately share the same memory pages.

Cross‑Agent Hand‑offs and Session Resumption

Publishing Shared Batons

To explicitly signal that an agent is yielding control, use the memory_handoff_begin API with the shared flag set to true. This publishes a “baton” that any other agent in the same project can claim.

As documented in docs/users.md, the request structure looks like this:

use ai_memory_store::api::handoff::MemoryHandoffBegin;

let handoff = MemoryHandoffBegin {
    cwd: std::env::current_dir()?,
    shared: true,          // Makes the baton visible to all agents
    ..Default::default()
};
let resp = client.memory_handoff_begin(handoff).await?;
println!("Handoff ID: {}", resp.id);

Setting shared: true ensures the hand‑off record is written without an owner lock, allowing the next available agent—regardless of tool type—to resume the workflow.

Resuming Work From Any Agent

The ai‑memory‑workstream crate enables agents to read the full history of a project, regardless of which agent originally created the data. In crates/ai-memory-workstream/src/transcript.rs, the SessionTranscript type opens the shared store and replays all messages:

use ai_memory_workstream::transcript::SessionTranscript;

// Open the store that other agents wrote to
let transcript = SessionTranscript::open("my-project", "my-workspace")?;
let messages = transcript.read_all()?; // Aggregates data from every agent

This allows Claude Code to pick up exactly where Codex left off, maintaining full conversational and contextual continuity.

Concurrency Safety and Data Consistency

When multiple agents write simultaneously, ai‑memory maintains consistency through two mechanisms:

1. Single‑writer serialization – As implemented in crates/ai-memory-store/src/writer.rs, a dedicated writer actor queues all mutations, ensuring the SQLite database never encounters conflicting writes from parallel threads.

2. Atomic file‑and‑database transactions – The Wiki component, defined in crates/ai-memory-wiki/src/wiki.rs, updates both the markdown file on disk and the corresponding row in the SQLite store within a single transaction. This guarantees that agents reading the database always see a state that matches the actual filesystem.

Cleanup of shared pages is restricted to owners or administrators:

ai-memory memory_delete_page \
    --workspace my-workspace \
    --project my-project \
    --path "notes/shared-insight.md"

Summary

• One server, many agents – A single ai-memory serve instance can backend Claude Code, Codex, Kiro, and other tools simultaneously.
• SQLite with serialized writes – The WriterHandle in ai-memory-store serializes concurrent updates, preventing data loss.
• Project‑scoped sharing – The (workspace_id, project_id, path) tuple isolates projects while NULL owner IDs enable open collaboration within them.
• Explicit hand‑offs – Use memory_handoff_begin with shared: true to publish session state for any peer agent to resume.
• Atomic consistency – Wiki operations update both disk and database in one transaction, ensuring all agents see identical content.

Frequently Asked Questions

Do I need a separate ai‑memory server for each AI agent?

No. You should run a single server (one ai-memory serve process) per machine or per user account. All agents connect to this same daemon and differentiate their data by project name. The SQLite backend handles concurrency safely through its single‑writer actor pattern.

How do agents prevent overwriting each other’s work?

The ai‑memory‑store crate implements a WriterHandle thread that queues all write requests. This serializes updates to the SQLite database, ensuring that even if Claude Code and Codex submit changes at the exact same millisecond, they are applied sequentially rather than colliding.

Can human users and AI agents access the same memory pages?

Yes. When a row’s owner_id column is NULL (the default for shared pages), both human operators and any authenticated agent can read and edit that entry. This is documented in docs/users.md and allows teams of developers and AI tools to collaborate on the same wiki pages and session transcripts.

What happens if two agents try to edit the same page simultaneously?

Because writes are funneled through the single WriterHandle actor in crates/ai-memory-store/src/writer.rs, SQLite transactions execute one at a time. The second write waits until the first commits, preserving data integrity. In the Wiki implementation (crates/ai-memory-wiki/src/wiki.rs), both the markdown file and the database row are updated atomically, so agents always see a consistent snapshot even under concurrent load.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}