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

> Discover if multiple AI agents can share a single ai-memory store. Yes, akitaonrails/ai-memory enables concurrent reads and writes to a persistent SQLite database for any number of agents.

- Repository: [Fabio Akita/ai-memory](https://github.com/akitaonrails/ai-memory)
- Tags: how-to-guide
- Published: 2026-09-12

---

**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`](https://github.com/akitaonrails/ai-memory/blob/main/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`](https://github.com/akitaonrails/ai-memory/blob/main/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:

```bash

# 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:

```bash

# 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`](https://github.com/akitaonrails/ai-memory/blob/main/docs/users.md), the request structure looks like this:

```rust
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`](https://github.com/akitaonrails/ai-memory/blob/main/crates/ai-memory-workstream/src/transcript.rs), the `SessionTranscript` type opens the shared store and replays all messages:

```rust
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`](https://github.com/akitaonrails/ai-memory/blob/main/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`](https://github.com/akitaonrails/ai-memory/blob/main/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:

```bash
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`](https://github.com/akitaonrails/ai-memory/blob/main/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`](https://github.com/akitaonrails/ai-memory/blob/main/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`](https://github.com/akitaonrails/ai-memory/blob/main/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.