Memory injection

How validated facts and searchable history actually reach an agent — an MCP tool it can query on demand, and a generated block in the project's guidance file at launch.

Indexing memory is pointless if the agent never reads it. Open Free Max delivers it two ways, which fail in different situations — that is why both exist.

Path A — memory as a tool

OFM hands the agent an MCP server, so it can query memory whenever it decides it needs to:

• search_history — search the project’s ingested conversations
• search_project_memory — search validated project facts

Turn it on with Wire MCP search_history tool in memory settings.

Supported CLIs: Claude Code and Antigravity. Claude receives the servers as --mcp-config files, which vanish with the session. Antigravity accepts no configuration flag at all, so the same stdio servers are written into a project-scoped plugin — see Antigravity for what that means on disk.

The strength of Path A: unlimited depth. The agent can search the whole history, repeatedly, and pull only what it needs. The weakness: it is model-driven. An agent that never thinks to call the tool gets nothing.

Path B — memory as a file

OFM writes the top validated facts into the project’s guidance file when a session starts:

Turn it on with Inject memory at launch (Path B), and cap the size with Number of injected facts.

The strength of Path B: deterministic. The agent reads the file because it always reads the file — no decision involved, and it works on CLIs that support no MCP injection at all. The weakness: it is a fixed budget, so only the top facts fit.

The generated block is bounded

OFM writes only between two markers:

<!-- MEMVAULT:BEGIN (généré — ne pas éditer à la main) -->
- [feedback] Front end is vanilla TypeScript DOM — never React
- [project] The HTTP client and token store live in Rust, never in the front end
<!-- MEMVAULT:END -->

Everything outside that region belongs to you and is never touched. Rewriting is idempotent: the block is replaced, not appended, so it cannot grow every launch. Turning Path B off clears the block instead of leaving a stale one behind.

One migration detail: Antigravity reads both GEMINI.md and AGENTS.md. If a project still has a GEMINI.md carrying an old generated block, OFM strips that block only so a frozen copy of yesterday’s memory cannot compete with today’s AGENTS.md. The rest of your GEMINI.md is left alone.

Which one should I enable?

Both, when the CLI supports both. Path B guarantees a baseline briefing on every launch; Path A lets a curious agent dig further. On a CLI that supports neither, memory is still fully usable by you through History search — you just paste what matters into the prompt.