different-ai/openwork merged commit 0b61e24 on July 2, adding Memory Bank v0 across database schema, API routes, MCP capability tags, ownership tests, a fulltext proof harness, and an agent prompt that tells the model to discover memory through search_capabilities before using it.
For agent operators and platform teams, the watch item is whether shared memory becomes a governed product surface: the strongest source makes recall useful only when scope, search, deletion, and secret hygiene are visible early.
Facts
- PR
#2436adds memory and memory-context tables, user-scoped routes, ownership tests, a delete cascade, and a live eval that saves and recalls memory through MCP. - The architecture note says v0 is user-scoped, uses fulltext search, and deliberately avoids automatic recall.
- OpenWork's same-day org-level MCP and Google Workspace merges add a separate access surface for connected tools, OAuth, and Gmail drafting.
Evidence
The public sources are the OpenWork Memory Bank commit, the memory architecture document, the memory route tests, and the org MCP and Google Workspace commits. Together they show stored context moving from a prompt idea into schema, API, capability, and eval receipts.
Context
This is not today's lead because a memory feature exists. It leads because it makes the hard part inspectable: a team agent that remembers work also needs ownership checks, search discipline, deletion, and connected-tool boundaries before operators can trust the memory.
Limits
The sources do not prove production adoption, safe defaults for every connected workspace, or that plaintext memory is acceptable for all teams. What to watch: whether OpenWork adds org-shared memory policy, retention controls, and redaction tests before broader rollout.