Agent Memory Bridge

简体中文

Give coding agents one shared, governed record of project decisions across tools and sessions.

Agent Memory Bridge is shared engineering memory for developers and teams that use more than one coding agent. It complements AGENTS.md, CLAUDE.md, and client-native preference memory rather than replacing them. SQLite/WAL is the durable authority, with FTS5 and optional local embeddings as derived indexes for lexical, semantic, or hybrid retrieval.

Current source release: 0.27.3

This is a local, unpublished source candidate; it does not assert a tag, push, publication, remote CI result, host certification, or productivity result. The candidate carries schema v10 and exactly 17 MCP tools. Governed-v2 profiles add typed events and CAS preconditions, bounded operator CLI verification receipts, and strong outcome authority. Watcher continuity uses an incremental cursor, explicit host close, and explicit continuation runs without storing message bodies in watcher state. Credit and consolidation evidence now keeps effective feedback, relation, and outcome heads consistent; distinguishes not_applicable from not_used; uses stable candidate subjects and separate evidence revisions; and closes immutability, provenance, artifact, privacy, procedure-conflict, opposition, and independence boundaries. Utility and consolidation remain shadow-only: they do not change ranking, policy, prompts, ordinary memory, or perform automatic writeback or self-improvement.

Codex is the reference workflow, not the product boundary. AMB uses local stdio MCP; client integrations are documented or locally verified only where labeled below.

Try it locally after install: <venv-python> -m agent_mem_bridge first-run --client generic --example

Why It Exists

Most agent memory either feels too shallow or too heavy:

• summaries become stale blobs

• vector stores hide why something was recalled

• every new session starts cold or gets a stale context dump

• handoff state turns into ad hoc notes or a queue you did not want to build

AMB takes a smaller path: local SQLite authority, explicit namespaces, inspectable records, capability-labeled retrieval, and a signal lifecycle for lightweight coordination.

Related MCP server: mcp-chest-memory

What You Get

• Durable memory: decisions, gotchas, procedures, concepts, beliefs, and supporting records.

• Coordination signals: claim -> extend -> ack / expire / reclaim without pretending to be a scheduler.

• Review-first writeback: learning candidates can be staged for human review before explicit promotion into durable records.

• Context assembly: startup and task-time context can be rendered from procedures, concepts, beliefs, gotchas, and linked support without adding more MCP tools.

• Governed change: explicit deletion, supersession, changed premises, and task-domain applicability are checked before guidance becomes actionable.

• Cross-client activation receipts: a read-only CLI receipt can show that two distinct declared client labels participated in one memory loop without exposing paths, content, session IDs, or model IDs.

• Retrieval feedback: callers can append a receipt-bound vote, correction, or retraction while AMB exposes at most one current effective vote without changing ranking or memory.

• Episode ledger: callers can create explicit server-minted runs/work items, append structured events, recover state after reconnect or compaction, and record evidence-backed outcomes without changing ranking or policy.

• Evidence context: recall can sign bounded SHA-256 digests for optional caller-declared model, harness, and chat_template labels without including raw values or treating them as authenticated identity.

• Proof discipline: release contract checks, public-surface checks, onboarding checks, benchmark snapshots, visual inventory checks, and targeted receipt/feedback regressions.

How It Works

AMB keeps the runtime path small: MCP-compatible coding agents call 17 public MCP tools, including four explicit episode tools; SQLite/WAL remains the durable authority; FTS5 and optional local embeddings are derived indexes; governed context and CLI reports are rendered without automatic durable writeback. Release checks, benchmarks, and the visual claim inventory stay outside that runtime path.

Who It Is For

• You use more than one coding agent and want project decisions, gotchas, and handoffs to remain shared across them.

• You already use AGENTS.md, CLAUDE.md, or native preference memory and need a governed cross-agent layer alongside it.

• You want memory that is local and inspectable instead of a hosted platform or opaque vector stack.

• You run review, handoff, or multi-agent workflows and need coordination signals without building a full task queue.

Install

Requirements:

• Python 3.11+

• SQLite with FTS5 support; optional local embeddings are derived indexes, not durable authority

• any MCP-compatible client that can launch a local stdio server

• optional uv / uvx for a pinned one-command GitHub smoke test

Pinned GitHub install with Python:

python -m venv .amb-venv
python -c "import os; from pathlib import Path; print((Path('.amb-venv') / ('Scripts/python.exe' if os.name == 'nt' else 'bin/python')).absolute())"

Treat the printed value as <venv-python>. Keep that resolved local path out of commits and issue reports. In a POSIX shell, shell-quote that path when needed. In Windows PowerShell, invoke it as & "<venv-python>". Then run:

The pinned GitHub tag route is the published v0.27.0 baseline. The local source candidate has no release tag; use a source checkout with <venv-python> -m pip install -e . to evaluate it.

<venv-python> -m pip install "https://github.com/zzhang82/Agent-Memory-Bridge/archive/refs/tags/v0.27.0.zip"
<venv-python> -m agent_mem_bridge doctor
<venv-python> -m agent_mem_bridge verify

An optional smoke test against the published baseline with uvx is:

uvx --from git+https://github.com/zzhang82/Agent-Memory-Bridge@v0.27.0 agent-memory-bridge verify

Quick Start: Unified First-Run

Use first-run when you want a complete copy/paste setup guide for a client. It renders install steps, a placeholder-safe config snippet, verification commands, and a first Task Brief preview. It does not write client config files or durable memory records.

<venv-python> -m agent_mem_bridge first-run --client generic --example
<venv-python> -m agent_mem_bridge first-run --client codex --example
<venv-python> -m agent_mem_bridge first-run --client opencode --example
<venv-python> -m agent_mem_bridge first-run --client hermes --example

If you only need the config snippet, use config directly:

<venv-python> -m agent_mem_bridge config --client generic --example
<venv-python> -m agent_mem_bridge config --client codex --example
<venv-python> -m agent_mem_bridge config --client opencode --example
<venv-python> -m agent_mem_bridge config --client hermes --example
<venv-python> -m agent_mem_bridge config --client cursor --example

Dockerized stdio works too when you want an isolated runtime:

docker build -t agent-memory-bridge:local .
docker run --rm -i -e AGENT_MEMORY_BRIDGE_HOME=/data/agent-memory-bridge -v /path/to/bridge-home:/data/agent-memory-bridge agent-memory-bridge:local

Client-specific notes live in docs/INTEGRATIONS.md. Runtime configuration lives in docs/CONFIGURATION.md. Authority and correction rules live in docs/AUTHORITY-CONTRACT.md. Security guidance lives in SECURITY.md. Agents that are installing the bridge should start with INSTALL_FOR_AGENTS.md.

The First Useful Loop

Session 1 discovers a project rule:

store(
  namespace="project:demo",
  kind="memory",
  content="claim: Use WAL mode for concurrent SQLite readers."
)

Session 2 asks about the same project:

recall(namespace="project:demo", query="SQLite concurrent readers")

The agent gets the rule back without the user typing it again.

For coordination, use signals:

store(namespace="project:demo", kind="signal", content="release note review ready")
claim_signal(namespace="project:demo", consumer="reviewer-a", lease_seconds=300)
extend_signal_lease(id="<signal_id>", consumer="reviewer-a", lease_seconds=300)
ack_signal(id="<signal_id>", consumer="reviewer-a")

For polling, use an empty query with kind="signal" and pass the previous next_since value back as since. Polling returns later insertions in ascending order. Missing, deleted, or cross-namespace anchors fail explicitly. The cursor does not report later claim or ack transitions on older Signals. Text and memory recall return next_since: null.

For a cross-client activation receipt, keep one correlation id across both clients:

# Client A stores one reviewed project memory.
store(
  namespace="project:demo",
  kind="memory",
  title="Reviewed SQLite guidance",
  content="record_type: gotcha\nclaim: Use WAL mode for concurrent SQLite readers.",
  tags=["workflow:cross-client-activation", "activation-role:writer", "reviewed:true"],
  correlation_id="activation-demo-001",
  source_client="client-a"
)

# Client B recalls it, then records and acknowledges the read signal.
recall(namespace="project:demo", query="SQLite concurrent readers", correlation_id="activation-demo-001")
store(
  namespace="project:demo",
  kind="signal",
  content="{\"observed_memory_id\":\"<writer_memory_id>\"}",
  tags=["workflow:cross-client-activation", "activation-role:reader"],
  correlation_id="activation-demo-001",
  source_client="client-b"
)
ack_signal(id="<reader_signal_id>")

Then render the local receipt:

<venv-python> -m agent_mem_bridge activation-receipt --namespace project:demo --correlation-id activation-demo-001 --format markdown

The receipt reports hashes and pass/review status. It does not print raw memory content, private paths, session ids, model ids, or authenticated identity claims.

The short version:

WITHOUT AMB
user> We hit this last time too: run the generator after schema edits.

WITH AMB
agent> I found the previous gotcha: run the generator after schema edits.

Task Briefs do not require Agent Memory Harness (AMH). The AMB CLI can render a derived task context report over recalled records, including what context was used, ignored, or marked for review. That brief is a derived view over AMB memory; it is not a second durable store and does not add MCP tools.

The terminal demo and the before/after gotcha story are in examples/demo, with the story source at examples/demo/before-after-gotcha.cast.md.

Client Support

Status labels are intentionally narrow.

MCP Tools

The bridge exposes 17 public MCP tools:

Same tools by group:

• store, recall, browse, stats

• forget, feedback, promote, annotate, revise, export

• begin_run, record_run_event, get_run, complete_run

• claim_signal, extend_signal_lease, ack_signal

annotate adds non-policy tags and provenance without rewriting the original content. revise creates a successor record and an auditable supersession receipt in one transaction. Both operations preserve the review boundary: callers cannot mint reserved governance tags or revise hidden learning candidates into authority.

Receipt-bearing recall returns rows and creates the signed complete exposure set from one SQLite read snapshot. Every exposure binds memory_id, rank, and exact content version. Optional evidence_context accepts only model, harness, and chat_template; the receipt contains bounded SHA-256 digests rather than raw caller-declared values. These labels do not affect retrieval order or feedback identity.

feedback defaults to a root vote. A correction or retraction must name the current supersedes_feedback_id, preserving the complete append-only event history while exposing at most one current effective vote. Caller-declared client and session labels cannot create additional votes for the same signed retrieval subject. receipt_hash remains the hash of the actual token; feedback_identity_digest is a separate canonical subject identity.

The richer behavior stays behind that surface: reviewed promotion helpers, consolidation, startup/task-time assembly, procedure policies, telemetry summaries, signal contention checks, learning-candidate review queues, Task Brief reports, human review workflows, and activation receipts. There are no separate task_packet, startup_packet, learning_candidate, task_brief, review_queue, review_workflow, or activation_receipt MCP tools, and no MCP Tasks, rerank, auth, ACL, ANN, graph, or auto-policy interface.

For normal service use, log capture helpers, promotion helpers, and strong consolidation are disabled by default. During each cycle, every enabled lane has its own exception boundary: one lane failure is reported with a failure count and bounded retry delay without stopping its siblings. The lanes still execute sequentially, so a slow call can delay later lanes; lane duration and slow-lane warnings make that delay visible. Watcher, reflex, consolidation, governance, and embedding scheduler state use tolerant atomic JSON and reset when a restored database has a different epoch. The service writes service-health.json, holds a local bridge-home singleton lock, exits 1 from service --once when any enabled lane fails, and exits 3 when another service owns the lock. Use --allow-multiple-services only when duplicate processing is deliberate.

Restore is an offline maintenance operation. Stop the service and every MCP/client process that can write the database before restoring, and reopen clients only after verification completes. The service lock excludes the background daemon; arbitrary MCP writers do not participate in that lock.

Operator review work is available as CLI reports, not MCP tools:

<venv-python> -m agent_mem_bridge review-queue --namespace project:demo --format markdown
<venv-python> -m agent_mem_bridge review-workflow --namespace project:demo --format markdown
<venv-python> -m agent_mem_bridge task-brief --namespace project:demo --query "release handoff" --format markdown
<venv-python> -m agent_mem_bridge activation-receipt --namespace project:demo --correlation-id activation-demo-001 --format markdown

review-queue shows staged candidates, review receipts, tombstones, stale records, and quarantined claims. review-workflow turns those queue items into explicit human decision prompts and manual steps. task-brief composes existing task-memory assembly, review queue items, and active signals into Used, Ignored, and Needs Review sections. activation-receipt reads existing rows for one namespace and correlation id and emits a sanitized declared-provenance receipt. These reports perform no automatic durable writeback.

MCP 2026-07-28 stdio compatibility

AMB 0.27.3 keeps modern MCP 2026-07-28 server/discover and legacy initialize over local stdio, with the same deterministic 17-tool surface. The independently exercised 0.27.0 interoperability run remains historical: it used mcp==2.0.0, a separate mcp==1.28.1 legacy client, and the official @modelcontextprotocol/client@2.0.0. Modern successful wire results contain resultType: "complete"; server/discover uses ttlMs: 300000 / cacheScope: "public"; the current canonical surface is deterministic and tools/list remains ttlMs: 0 / cacheScope: "private".

This is local Linux/Python 3.12 project-interoperability evidence only, not a GitHub CI result, official conformance, host certification, Windows proof, tag, publication, or productivity result.

The compact cache contract is 300000/public for discover and 0/private for the tool list.

Meaningful per-request clientInfo is caller-declared provenance, not authenticated identity. source_client precedence is explicit tool input, then meaningful MCP context, then the environment default; generic SDK names such as mcp are ignored.

Static-schema client compatibility

Some MCP clients generate one static input schema per tool and may send signal-only fields on kind="memory" paths: for example ttl_seconds or expires_at on store, and signal_status on recall, browse, or export. AMB drops those fields at the MCP transport boundary before creating or querying memory records. The lower-level memory store contract stays strict: durable memory and coordination signals remain separate lanes, and real signal lifecycle fields still belong only to kind="signal" operations.

Proof Snapshot

0.27.3 carries the explicit episode ledger through schema v10. Governed-v2 profiles require closed typed event/preflight evidence and server-minted operator verification receipts before strong verified_success authority; watcher scans are incremental, pause idle rollouts, close only on explicit host signals, and create explicit continuation runs after terminal growth. The credit/consolidation projections use only current effective feedback and outcome heads, keep not_applicable and not_used distinct, and expose stable candidate_subject_id versus evidence_revision_id identities. Keyset pagination, contested procedure handling, structured opposition, declared vs verified independence, and immutable/provenance/artifact/privacy validation are all fail-closed. The exact 17-tool surface is frozen by mcp_boundary.PUBLIC_TOOL_ORDER with schema digest 24c5c52321d61b4b6f647c0d74e2d8304ca68716c403e08a274e9badfd8dc9f8. The local suite reports 796 tests passed; this is local evidence only, not a remote CI, tag, publication, host-certification, ranking, auto-writeback, or self-improvement claim.

Current source test collection: 796 tests

Snapshot facts checked by the release contract:

question_count = 11
memory_expected_top1_accuracy = 1.0
memory_mrr = 1.0
file_scan_expected_top1_accuracy = 0.636
file_scan_mrr = 0.909

sample_count = 16
classifier_exact_match_rate = 0.875
fallback_exact_match_rate = 0.062
classifier_better_count = 13
fallback_better_count = 2
classifier_filtered_low_confidence_count = 2

case_count = 7
flat_case_pass_rate = 0.429
governed_case_pass_rate = 1.0
flat_blocked_procedure_leak_rate = 1.0
governed_blocked_procedure_leak_rate = 0.0
governed_governance_field_completeness = 1.0

signal_contention_case_count = 5
signal_contention_case_pass_rate = 1.0
unique_active_claim_rate = 1.0
duplicate_active_claim_count = 0
active_reclaim_block_rate = 1.0
stale_ack_blocked_rate = 1.0
stale_reclaim_success_rate = 1.0
pending_under_pressure_claim_rate = 1.0
initial_hard_expiry_cap_rate = 1.0

adversarial_case_count = 6
adversarial_task_count = 7
adversarial_governed_task_pass_rate = 1.0
adversarial_governed_blocked_record_leak_rate = 0.0

memory_evolution_case_count = 6
memory_evolution_task_count = 7
memory_evolution_governed_task_pass_rate = 1.0
memory_evolution_governed_blocked_record_leak_rate = 0.0
memory_evolution_governed_disposition_reason_hit_rate = 1.0

review_queue_item_count = 6
review_queue_actionable_count = 6
review_queue_hidden_lane_count = 2
review_queue_writeback_plan_count = 6
review_queue_no_auto_mutation = true
review_queue_public_mcp_surface_change = false
review_queue_item_type_count = 6

review_workflow_source_queue_item_count = 6
review_workflow_item_count = 6
review_workflow_manual_step_count = 27
review_workflow_requires_human_count = 6
review_workflow_auto_write_count = 0
review_workflow_no_auto_writeback = true
review_workflow_public_mcp_surface_change = false
review_workflow_item_type_count = 6

task_brief_used_count = 2
task_brief_ignored_count = 1
task_brief_needs_review_count = 4
task_brief_review_queue_item_count = 2
task_brief_active_signal_count = 1
task_brief_no_auto_writeback = true
task_brief_public_mcp_surface_change = false
task_brief_needs_review_source_type_count = 3

v019_case_count = 12
v019_pass_count = 12
v019_pass_rate = 1.0
v019_retrieval_case_count = 4
v019_retrieval_pass_rate = 1.0
v019_task_brief_case_count = 4
v019_task_brief_pass_rate = 1.0
v019_first_run_adoption_case_count = 4
v019_first_run_adoption_pass_rate = 1.0
v019_public_mcp_tool_count = 10
v019_public_mcp_surface_change = false
v019_client_config_write_count = 0
v019_durable_writeback_count = 0
v019_amh_required = false
v019_native_memory_comparison_required = true

v020_case_count = 6
v020_pass_count = 6
v020_pass_rate = 1.0
v020_import_sanity_pass = true
v020_stdio_round_trip_pass = true
v020_first_run_pass = true
v020_task_brief_pass = true
v020_public_mcp_tool_count = 10
v020_public_mcp_surface_change = false
v020_client_config_write_count = 0
v020_explicit_demo_memory_write_count = 1
v020_explicit_demo_signal_write_count = 0
v020_non_demo_durable_writeback_count = 0
v020_amh_required = false
v020_external_vendor_adoption_claim = false

v021_case_count = 20
v021_category_count = 4
v021_flat_baseline_hazards = 17
v021_flat_baseline_hazards_expected = 17/20
v021_governed_case_pass_count = 20
v021_governed_failures = 0
v021_governed_failures_target = 0/20
v021_governed_checkpoint_passes = 40
v021_governed_checkpoint_passes_target = 40/40
v021_governed_checkpoint_result_count = 40
v021_useful_current_retention_pass = true
v021_suppress_all_can_pass = false
v021_public_mcp_tool_count = 10
v021_public_mcp_surface_change = false
v021_auto_writeback_count = 0
v021_config_write_count = 0
v021_durable_live_writeback_count = 0

Full proof details are in benchmark/README.md.

Boundaries

AMB is not a graph database, general unlearning system, hosted memory platform, HTTP MCP service, Tasks or Apps runtime, OAuth/ACL system, scheduler, worker runtime, distributed lock, exactly-once coordination system, packet API, reranker, automatic policy engine, compliance certification, authenticated identity system, or unreviewed durable writeback path from raw transcripts. Its episode ledger is evidence authority, not an autonomous task runtime. forget remains an explicit mutating operation; governed change makes that operation more conservative and auditable rather than automatic.

For alternatives and trade-offs, see docs/COMPARISON.md.

Docs

• Client integrations

• Configuration

• Authority contract

• Trust boundary

• Agent install protocol

• Benchmark and proof harness

• v0.27.3 announcement

• v0.27.2 announcement

• v0.27.1 announcement (historical)

• v0.27.0 announcement (historical)

• v0.26.1 announcement (historical)

• Release communications

• Context assembly

• Memory taxonomy

• Promotion rules

• Client provenance

• Examples

• Contributing

• Security

License

MIT. See LICENSE.