Skip to content

Agent Memory Bridge v0.33.0 — Operationalization

Latest
Latest

Choose a tag to compare

View all tags
@zzhang82 zzhang82 released this 08 Sep 02:34
v0.33
cb314eb
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Agent Memory Bridge v0.33.0 turns the v0.33 operationalization work into a published release. The release focuses on making AMB easier to validate, safer to operate across supported environments, and clearer about what counts as a real first win. It does not add a new durable authority, expand the public MCP surface, or enable automatic learning.

A real first win across sessions

The primary onboarding success criterion is now a fresh coding-agent session recalling a real project decision and its reason from the same configured AMB home.

The intended path is:

  1. install AMB;
  2. connect the coding client explicitly as a local stdio MCP server;
  3. initialize the project;
  4. store one real project decision through the public store tool;
  5. close the first session completely;
  6. open a fresh session and ask a normal project question;
  7. confirm the decision and reason come back through AMB recall.

doctor, verify, Explore, and Inspect remain useful checks, but they are not substitutes for the fresh-session first win.

The automated first-win proof validates process separation and durable recall. External live Codex, Cursor, and Claude first-win observation remains separate and is not claimed as empirical release evidence here.

Install and PyPI Distribution

Install the release package with:

pip install agent-memory-bridge==0.33.0

Installing the package does not automatically connect every coding agent. Each coding client must be configured separately, and clients that should share project memory must point at the same persistent AGENT_MEMORY_BRIDGE_HOME.

Publication continues through PyPI Trusted Publishing with GitHub OIDC after the matching GitHub Release is published.

MCP compatibility and CI

The Python MCP SDK runtime policy is:

mcp>=2.0.0,<3

CI validates the supported floor and the latest supported 2.x release, and both feed the stable CI success aggregate gate. The release also preserves legacy Python MCP client interoperability and TypeScript MCP client interoperability through explicit compatibility jobs.

Cross-platform first-win process proof

The fresh-session acceptance test uses a non-destructive process-liveness check.

  • POSIX uses os.kill(pid, 0) as an existence probe.
  • Windows uses OpenProcess(SYNCHRONIZE) followed by WaitForSingleObject(handle, 0); WAIT_TIMEOUT means the process is still running and WAIT_OBJECT_0 means it has terminated.

This avoids treating an open Windows process handle as proof of liveness.

Multi-machine authority boundary

The documented deployment topology keeps one canonical SQLite/WAL authority host. Remote machines reach that authority through an adapter rather than opening the SQLite database over a network filesystem. PostgreSQL remains deferred until a real multi-writer or server-native requirement justifies it.

The failure model explicitly distinguishes SQLite transaction atomicity from caller certainty: a write can commit while the response is lost, producing a committed-but-unacknowledged outcome.

Public error semantics

Expected public validation failures can surface as model-correctable ToolErrors. Unexpected internal ValueErrors are not blindly exposed as public validation text.

Compatibility and authority boundaries

  • Durable schema remains v12.
  • Public MCP surface remains exactly 17 tools.
  • The public tool-schema digest remains 24c5c52321d61b4b6f647c0d74e2d8304ca68716c403e08a274e9badfd8dc9f8.
  • Knowledge Explorer remains CLI-only with no MCP tool #18.
  • There is no automatic learning.
  • Repository-derived knowledge remains rebuildable and separate from governed durable project knowledge.
  • The product remains local-first stdio MCP over SQLite/WAL; no public HTTP product surface or PostgreSQL migration is introduced.

Release verification

The release cut must be validated on the exact release-candidate SHA before tagging. The normal gate includes the OS/Python test matrix, quality checks, release/public-surface/onboarding contracts, MCP floor/latest compatibility, interoperability checks, distribution build validation, and the aggregate CI success check.

GitHub Releases remains the publication authority for the source tag and release notes; PyPI is the normal package-install route.

Assets 2
Loading