# Current Memory Status — Post Install

## What is now live

- Hermes has an MCP server named `openbrain-bridge` registered in the active profile.
- The server runs from a project-local virtualenv:
  - `.venv-openbrain/bin/python`
- The bridge file lives at:
  - `mcp/openbrain_bridge.py`
- Hermes can connect to the server and discover 8 tools.
- The bridge exposes:
  - archive search
  - approved-memory lookup
  - source-only lookup
  - source chunk fetch
  - review-item listing
  - status reporting

## What the bridge is backed by

- `index/archive.db` for archive search
- `approved-memory/install-batch-proposed.jsonl` for approved memory
- `approved-memory/source-only-index.jsonl` for source-only items
- the reviewed install batch preserves provenance metadata

## What was predicted vs what actually happened

### Predicted

- tuning would likely be needed
- retrieval ranking and query shape might need adjustment
- install policy and memory boundaries might need refinement

### Actually discovered so far

- the archive search path already works well for the local index
- the MCP bridge was the missing connection point, not the archive data itself
- the biggest immediate gap is that the bridge is still a local OpenBrain-style layer, not the full hosted Supabase/OpenBrain backend
- Hermes needed explicit MCP server registration and tool enablement
- the project-local Python environment was required because the system Python is externally managed

## Assessment

The system is now **connected and usable**, but it is not yet the final hosted OpenBrain deployment.

## Suggested next tuning items

- decide whether to keep the local bridge as the active working layer or swap it for the hosted OpenBrain backend
- align the bridge tool set with the exact memory operations we want Hermes to use most often
- add periodic pruning / review instrumentation once the live backend is stable
- compare search quality over time against the report template and maintenance schema