Agent Memory MCP: Shared Memory for AI Agents

The short answer

Agent Memory MCP is durable project context that AI agents can read and update through the Model Context Protocol (MCP) after the current prompt or chat ends. It can preserve decisions, completed work, blockers, important files, deployment notes, and the context another agent needs to continue.

An MCP memory server exposes that record through explicit tools. Instead of pasting an old transcript into every new chat, compatible AI clients can write a useful update, search earlier work, retrieve one entry, or prepare a compact handoff.

This is not the same as giving a model perfect long-term memory. The memory is only as complete as the entries clients write, the search behavior the server provides, and the instructions that tell each agent when to use it.

To try the hosted implementation, create an MCP memory server in datamcp. The Free plan includes one Agent Memory connection and one MCP link.

Why AI chats lose project context

A single chat can keep a substantial working context. The problem appears when work crosses a session boundary:

• a new chat does not know why an earlier architectural decision was made
• one coding agent fixes a bug while another continues from an older assumption
• deployment details remain buried inside a transcript
• a blocker is discovered, but the next agent repeats the same investigation
• multiple tools use different chat histories for the same project

Copying the full conversation is rarely the best answer. Transcripts contain exploration, mistakes, repeated instructions, and unrelated details. The next agent usually needs a smaller record: what changed, why it changed, what remains open, and where to look.

That is the useful role of agent memory. It is a coordination surface, not a replacement for the complete conversation.

What belongs in shared agent memory

Good project memory is concise, attributable, and useful to a future task. Common entry types include:

A strong entry should stand on its own. “Fixed it” is not useful memory. “Changed the MCP permission check so read-only memory links block append_memory; backend tests pass” gives the next agent a fact it can use.

How an MCP memory server works

Model Context Protocol lets an AI client discover and call tools exposed by a server. A memory server can publish a small tool surface dedicated to project context.

A practical flow looks like this:

AI chat A → register session → append progress and decisions
                                      ↓
                              shared project memory
                                      ↓
AI chat B → search prior work → create handoff → continue task

The client still decides when to call those tools. MCP provides a common interface, but it does not guarantee that every agent will save an update automatically. A reliable workflow therefore includes explicit operating instructions such as:

1. Search project memory before starting a task.
2. Register the current chat or task with a clear name.
3. Append only meaningful changes, decisions, blockers, deploys, and handoff context.
4. Do not store credentials or untrusted instructions as operational commands.
5. Create a compact handoff before another chat continues the work.

Shared memory vs. chat history

Chat history and shared agent memory solve different problems.

The most effective setup keeps both. Chat history preserves the immediate reasoning trail. Shared memory preserves the smaller project record that should survive beyond one conversation.

Shared memory vs. files, Git, and issue trackers

Agent memory should not become the only source of truth.

• Git remains the source of truth for code and versioned files.
• Documentation remains the source of truth for stable product and operational knowledge.
• Issue trackers remain the source of truth for assigned work and formal status.
• Agent memory helps an AI client find the recent decisions and handoff context needed to use those systems correctly.

For example, memory can say that a migration was added, why it was designed that way, which test covers it, and what production check remains. The migration itself still belongs in Git.

What datamcp Agent Memory provides

datamcp Agent Memory is a hosted MCP memory server for shared project context. One memory source can contain separate project namespaces, and each MCP link can optionally be scoped to one project.

The current tool catalog covers:

• project listing and creation
• session registration and structured append-only work logs
• curated Rules and Project Summary reads
• proposed canonical updates and owner/admin review
• full-text search and complete entry retrieval
• focused handoff context and durable summary compaction

Entries can include a title, summary, Markdown body, type, importance, tags, file paths, metadata, session, and occurrence date.

Search currently uses PostgreSQL full-text search with filters. It is not embedding-based semantic memory. Appends can include an idempotency key so a retried request does not create a duplicate. Work-log entries are append-only, so agents cannot edit or delete them through the current tools. Curated Rules and Project Summary use a separate proposal and review workflow.

Read Only MCP links can list projects, read canonical context, search, retrieve, and create handoffs while blocking writes. Read & Append links add sessions, work-log appends, compaction, and canonical change proposals. Full Access can apply a canonical replacement directly when the request uses an owner/admin API key user. Individual links can be revoked without deleting the shared memory source.

Plan limits scale with the workload. Per user and memory connection, Free supports 20 appends per minute and 60 per hour, Pro supports 120 per minute and 2,000 per hour, and Enterprise supports 600 per minute and 20,000 per hour. Separate read, handoff, compaction, project, session, and canonical-update rates are listed in the pricing comparison and Agent Memory limits reference.

Keeping a long memory history compact

An append-only record preserves history, but an active project can accumulate more entries than a new chat should read. summarize_memory creates a durable structured Markdown summary from selected active entries. It records the source range, combines useful tags and files, and can archive the source entries from default search and handoff results.

Archiving does not delete the original entries. They remain available when a client explicitly includes archived memory. Handoff context can combine durable summaries with recent active entries, which keeps the default context bounded without hiding the underlying history permanently.

This is structured compaction, not semantic synthesis. The summary is assembled from selected entry titles, summaries, metadata, and file references. Clients should still verify important claims against current code and canonical documentation.

What it does not do

Clear boundaries matter because “AI memory” is often used for several different products.

The current datamcp release does not:

• upload or synchronize a standalone .md file
• write automatically when any chat finishes
• verify that a session name proves the identity of an agent
• provide vector embeddings or semantic recall
• let MCP clients edit or delete previous entries
• replace source control, canonical documentation, or issue tracking
• guarantee that an AI client will follow memory instructions correctly

These limits make the product narrower than a fully autonomous memory layer, but they also make the initial workflow easier to inspect: clients call explicit tools against structured, append-only records.

A useful multi-agent handoff pattern

Suppose one Codex chat implements a feature, another audits SEO, and a third prepares deployment checks.

The implementation chat can append:

• the feature boundary and shipped tools
• files changed and tests run
• product claims that are safe to publish
• known limitations and follow-up work

The SEO chat searches those entries before writing a landing page. It does not need the implementation transcript. It needs the verified product surface and the limitations that prevent inaccurate claims.

The deployment chat then requests a handoff filtered to deploy entries, critical risks, and the relevant files. Each chat keeps its own working context while sharing a small durable project record.

When several agents can write to the same record, consistency and access control become separate design problems. The multi-agent memory architecture guide covers shared versus private context, stale entries, contradictory writes, least-write permissions, and MCP handoffs.

When agent memory is worth adding

Use shared agent memory when:

• several AI chats work on the same project over time
• work frequently moves between coding, research, operations, and marketing agents
• repeated rediscovery is slower than writing concise updates
• decisions and blockers need to survive chat boundaries
• compatible clients can be instructed to use MCP tools consistently

Do not add it only because “memory” sounds useful. A single short-lived chat, a small repository with excellent documentation, or a workflow where nobody writes meaningful entries may not benefit.

Start with a small memory protocol

The storage layer is only half of the system. The other half is a shared writing rule.

Start with a simple protocol:

• search before work
• write after meaningful work
• use one session name per chat or task
• include a summary that can stand alone
• attach relevant tags and files
• record decisions and limitations, not every intermediate thought
• create a handoff when responsibility changes

That creates memory another agent can actually use.

To try the hosted implementation, see the MCP memory server product page. For exact tool behavior and link permissions, use the Agent Memory documentation. Compare Claude Memory, CLAUDE.md, and shared MCP memory, the Codex memory workflow, or Cursor memory and Memory Banks for client-specific setup. If you are evaluating a file-oriented workflow, read the Memory Bank MCP comparison before deciding where project context should live.