DEV Community

Jamse Bao
Jamse Bao

Posted on

I Spent a Coding Break Making Engram Remember Things, Then Debugged the MCP Boundary

#go #cli #sqlite #mcp

I tested Gentleman-Programming/engram during a short coding break because persistent memory sounds useful until every coding agent starts carrying yesterday’s assumptions into today’s debugging session.

The architecture is refreshingly concrete: a Go binary, SQLite with FTS5 for search, an MCP server, an HTTP API, a CLI, and a TUI. No elaborate hosted dependency is required. That makes local inspection easy, and I could see where memories were stored instead of treating retrieval as magic.

The first friction point was not SQLite or FTS5. It was the MCP process boundary. My client launched the server, but the connection failed with a generic “server exited” message. Running the same command manually showed the real problem: the client was resolving engram differently from my shell environment. The binary worked interactively, but the MCP host did not inherit my PATH.

The fix was boring and reliable: build once, use an absolute path, and keep the server configuration explicit.

git clone https://github.com/Gentleman-Programming/engram.git
cd engram
go build -o "$HOME/.local/bin/engram" .
"$HOME/.local/bin/engram" --help
Enter fullscreen mode Exit fullscreen mode

Then point the MCP client at the absolute binary path rather than relying on shell startup files:

{
  "mcpServers": {
    "engram": {
      "command": "/home/me/.local/bin/engram",
      "args": ["mcp"]
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

The second gotcha is conceptual: persistent memory is not automatically useful memory. If an agent records every intermediate thought, FTS5 can retrieve technically relevant noise. I would keep durable entries focused on decisions, repository constraints, failed fixes, and verified commands—not raw chat transcripts.

Engram is worth examining if you want local, inspectable memory with multiple integration surfaces. Watch the MCP environment, binary paths, and database location before blaming the retrieval layer. The hard part is not making memory persistent; it is keeping the memory precise enough that the agent does not confidently resurrect stale debugging advice.

Top comments (0)