MemoryHub makes shared agent memory an OpenShift governance boundary

MemoryHub is a Red Hat AI Americas field build that treats agent memory as shared platform infrastructure rather than a private data structure inside each application. Its repository describes persistent memory, semantic search, version history, scoped access control and an MCP-compatible interface, with a local SQLite-backed edition and a cluster edition aimed at Red Hat OpenShift AI (repository).

Authorization is shipped; the wider governance design is not

The project’s clearest implemented governance boundary is authorization. Its subsystem inventory marks service-layer RBAC, JWT verification, OAuth 2.1 client management, project and campaign membership resolution, on-behalf-of authorization for service agents and a tenant-scoped admin API as implemented. The governance design further says every tool that touches memory data calls the authorization layer, with tenant isolation and scope-specific read and write checks (system inventory; governance design).

That evidence does not support treating the entire governance design as shipped. The design document describes immutable logging for every operation, configurable retention through custom resources and policy enforcement through MemoryPolicy CRDs. But the inventory is internally inconsistent: its governance row says a structured audit-logging stub shipped, while its later “What’s not yet shipped” section says audit logging is still a stub interface and is not wired through. The same inventory marks the Kubernetes Operator as a skeleton, observability as TBD and FIPS validation as pending (system inventory). Until those contradictions are resolved in code and release evidence, immutable audit, automated retention and CRD-backed policy enforcement should be read as target architecture rather than production guarantees.

The cluster edition’s identity and membership controls therefore offer a useful evaluation surface, but they do not remove the operator’s burden. Teams would still need to verify which events are actually recorded, establish retention outside the unfinished operator path, and supply monitoring while the project’s Prometheus and Grafana work remains unshipped.

Operations are not lightweight

The cluster guide requires OpenShift with Red Hat OpenShift AI, cluster-admin access, a default StorageClass and Python 3.11 or newer. Its make install path deploys PostgreSQL with pgvector, MinIO, Valkey, embedding and reranker models, an OAuth service, the MCP server and a dashboard; GPUs are optional because the default model deployment is CPU-based (installation guide). That is a meaningful operational footprint for a memory layer. Platform teams would need to own availability, upgrades, storage growth, identity integration and the consequences of memory becoming unavailable to dependent agents.

Persistent, shared records can cross application and team boundaries over time. MemoryHub’s shipped scope checks constrain who can reach a memory, but the project documents retention sweeps, legal hold, immutable forensics and policy CRDs across design and subsystem descriptions whose implementation status is uneven. Evaluators should test each required control directly instead of inferring it from the architecture narrative.

Treat the benchmarks and maturity claims carefully

The project reports 83.7% on AMB PersonaMem 32k, with that submission marked as pending review, and R@5 of 0.999 on the LongMemEval oracle configuration (repository). Those are project-reported results, not evidence that a particular OpenShift deployment will deliver the same recall under its own data, access policies and latency constraints.

The system inventory lists implemented core storage, memory, authorization and client surfaces alongside a skeleton operator, absent observability and other design-stage integrations (system inventory). Combined with its field-build provenance, that makes MemoryHub useful as an architectural reference and evaluation target, not a substitute for a supported product commitment. Its practical contribution is the boundary it draws: shared agent memory is governed state. Its present maturity requires teams to separate working access controls from governance capabilities that are still aspirational, partial or undocumented in operation.