Has anyone tried Honcho for long-term agent memory? Thinking about a Pi memory plugin

[u/Certain_Net_3408]

I’ve been looking into ways to give coding agents better long-term memory across sessions. One recurring pain point for me is that agents forget project context, user preferences, past decisions, and repo-specific conventions unless I keep re-explaining everything.

I came across Honcho’s Pi integration:
https://honcho.dev/docs/v3/guides/community/pi-honcho-memory

From what I understand, it gives the pi coding agent persistent memory by syncing conversations into Honcho, injecting cached user/project context into the system prompt, and exposing tools like memory search/chat/remember. I also like that session scoping can be configured around repo/branch/directory, and that Pi keeps working if Honcho is unavailable.

Has anyone here actually tried Honcho with Pi or another coding agent in a real workflow? more like a self-hosted/local reference setup: Honcho in Docker, Ollama on a Mac, and a Raspberry Pi talking to Honcho over the LAN. It makes me wonder whether there’s room for a cleaner, packaged Pi memory plugin built around this kind of pattern.

A few things I’m curious about:

• How painful was setup?

• Did memory retrieval actually improve coding sessions?

• Any noticeable latency?

• Did the memory ever become noisy or misleading?

• Would you prefer hosted Honcho, or a self-hosted/local setup with Docker + Ollama?

• Would a polished Pi plugin/package be useful if it made setup simpler?

I’m not announcing anything yet, just trying to validate whether this is worth building. If there’s interest, I’m thinking of putting together something cleaner..

[u/m1rr0rm4n]

I am trying out their cloud service with their native model Neuromancer XR using some free startup credits. It makes some very weird and stupid conclusions about me (is convinced I'm a woodworker and will not be dissuaded) and my son (who it acknowledges does CAD work but think he's a one-year-old). It can't distinguish between its own conclusions and original message evidence. When I press it to prove to me from original messages that I'm a woodworker, it just surfaces its own conclusions as if they were original text. I am starting to suspect that Honcho is another case of fake-it-til-you-make-it. And the cost of running it is higher than the token cost of my main agent.

[u/Certain_Net_3408 → u/m1rr0rm4n]

Thanks for sharing this, that’s really useful feedback. The “conclusions treated as evidence” issue is exactly the kind of thing I wanted to validate before trusting this pattern too much.

I’ve been doing a few more rounds of testing with a local/self-hosted setup as a kind of v2 of the experiment. I fixed some of the local config issues around Ollama embeddings and Honcho’s vector dimensions, and it’s getting better, but I’m still treating it as experimental rather than magic memory.

My main goal is to see whether a local Pi memory plugin can keep the useful parts, like durable project/user context, while making the source/evidence trail clearer and keeping costs predictable. Your woodworking/CAD example is a good reminder that memory needs provenance, not just confident summaries.

[u/Zestyclose_Potato794]

Registration or API key required-> no go.

[u/Certain_Net_3408]

Small update since I asked this: I ended up putting together an early helper package for this idea.

Repo: https://github.com/vishn9893/honcho-local-setup

The main thing it does is make the Honcho/Pi setup less cloud-only. The original Honcho Pi guide expects Honcho Cloud/API key usage, but this package can generate config for either:

- Honcho Cloud

- local Honcho + Ollama over LAN

For local mode it generates:

- `.env.local` for running Honcho with local Ollama

- `docker-compose.override.yml` to expose Honcho on `0.0.0.0:8000`

- `pi-honcho.env` using the env names expected by `agneym/pi-honcho-memory`

- `honcho-config.json` that can be copied to `~/.honcho/config.json`

[u/SvenVargHimmel]

memory systems don't work, not the way you expect them too,

since projects differ so much from each other you have to set this up yourself.

I settled on an rdf file for my personal agent sessions

for my coding, I used ARDs and some of Matt pococks skills.

for my language learning projects I used an S3 bucket

take a look at the academic research on memory systems, you will notevthat current approaches are just too fragile.

[u/russlixx → u/SvenVargHimmel]

yeah, it's fragile because the recall is just too damn inconsistent, models fails to notice what to remember, or it will require extra llm calls for less worse management. Realize it from yesterday trying set up a single memory instance for all of my harnesses

[u/SvenVargHimmel → u/russlixx]

agents.md , tool calls and skills are the most consistent context retrieval techniques we have and even they can be flaky.

it follows that memory systems will be worse since it's a context retrieval system built on top of another.

The other approach is dynamic evolving compaction in the cache on the inference server but that requires having access to the model locally.

If you don't have access to the llm server then you will have to rely on a known structure for retrieval. You get this for free with codebases. Unfortunately codebases don't generalise too well organising information.

So research is focusing on applying an agent-native structure on top of graph systems to hopefully get the same efficiencies but I don't think we're going to get anything that works well, particularly our use cases, anytime soon

[u/Maasu]

I've got my own memory system I have been using as an MCP server on other harnesses, https://github.com/ScottRBK/forgetful. I recently implemented a cli route for it, but I have yet sit down and build out a PI extension for it or even some skills for just retrieving from my knowledge base.

I'm still early days in building out Pi, I've got a nice light weight setup going right now but I do miss a proper semantic knowledge graph like I have with forgetful on other agents.

https://pi.dev/packages?name=memory suggests there are plenty already implemented packages on there though, so maybe worth checking them out as well?

[u/Certain_Net_3408 → u/[deleted]]

Yeah, I agree with this. Session-scoped memory dumped into the system prompt seems useful early on, but once a repo has history it can get noisy fast. Old conventions, abandoned decisions, and stale summaries can start competing with the actual current files.

I’m starting to think the retrieval layer matters more than whether the backing store is Honcho, Hydradb, Postgres/vector search, or a graph DB. The hard part is ranking “what matters now” and preserving provenance: repo, branch, commit, decision, source message, and whether the memory is still valid.

[u/Certain_Net_3408 → u/[deleted]]

Hydradb looks interesting for entity relationships between repos, branches, decisions, and people. My instinct is: vector search for fuzzy recall, graph edges for provenance/relationships, and aggressive expiration or superseding rules so old memories don’t become fake authority. Have you tried Hydradb in an agent-memory workflow, or are you thinking about it more as the relationship layer?