Show HN: Hopsule – Persistent memory and decision layer for AI development
10 comments
This is a real problem. Hopsule looks interesting.
IIUC, the core of your approach is that decisions get locked as immutable constraints and then served to agents via MCP when they query for context — is that right? Is there anything you can do to ensure that the MCP actually gets called?
I've been experimenting with an approach that triggers a set of checks on the Claude Code stop hook for lightweight, deterministic checks, then does a quick AI-powered review as a pre-commit hook, with a mechanism in place to ensure that appropriate elements of context from repo docs get loaded into context during the review.
One thing I've had to put a good bit of work into is orchestrating what happens when the existing rules don't cover some particular case. How do you think about that?
IIUC, the core of your approach is that decisions get locked as immutable constraints and then served to agents via MCP when they query for context — is that right? Is there anything you can do to ensure that the MCP actually gets called?
I've been experimenting with an approach that triggers a set of checks on the Claude Code stop hook for lightweight, deterministic checks, then does a quick AI-powered review as a pre-commit hook, with a mechanism in place to ensure that appropriate elements of context from repo docs get loaded into context during the review.
One thing I've had to put a good bit of work into is orchestrating what happens when the existing rules don't cover some particular case. How do you think about that?
Thanks!
You hit the nail on the head with the core approach. But to answer your first question: you can't 100% guarantee the AI will call the MCP. That's exactly why we don't rely on it alone.
If the AI skips context, our fail-safes kick in: we track compliance to existing decisions using their IDs directly on file save via our IDE extension, and through our GitHub App on PRs.
Regarding your second point on edge cases: when existing rules don't cover a situation, or a PR introduces a new pattern, we extract those changes as DRAFT decisions and leave them for human approval. AI proposes, humans decide.
We keep enforcement entirely advisory-only. It warns you, but it never blocks a merge. Advisory-only isn't a compromise; it's the point. We want to make architectural drift visible, not act as a stricter linter.
Down the road, if the project grows the way we want, we think the ultimate way to handle this context orchestration might be building our own IDE.
Hopsule has been a genuinely useful tool for me. What I like most is how it helps AI work within my existing workflow and architectural decisions instead of disrupting them. The fact that it takes the existing structure into account and acts accordingly reduces unnecessary corrections and makes the whole process much easier. I already find it very practical and useful, and I believe it will become an even stronger product as it continues to evolve.
Thanks!
Hopsule is a very useful tool that has already proven its value in my workflow. I particularly appreciate its practicality and how it simplifies complex tasks. With further improvements and development, I believe it can become even more effective and powerful. At this stage, I can confidently say that I prefer using Hopsule in the projects I am currently developing, and I look forward to seeing how it evolves in the future.
Thanks!
This is really interesting. Have you thought of making something similar for non-coders? I imagine that it shouldn't be too different as the same problem occurs in all sufficiently long chats with an LLM.
But, if this acts as a KB as I seem to understand it does from a cursory look, this could be a much bigger tool for a much larger audience.
Thoughts?
But, if this acts as a KB as I seem to understand it does from a cursory look, this could be a much bigger tool for a much larger audience.
Thoughts?
Thanks! The problem isn’t AI chat, it’s tracking what the AI actually does to files.
Since we rely on MCP, starting with environments like GitHub and IDEs makes this tractable.
If we can own more of that surface (i.e. build our own tool), expanding beyond devs is definitely on the roadmap.
Since we rely on MCP, starting with environments like GitHub and IDEs makes this tractable.
If we can own more of that surface (i.e. build our own tool), expanding beyond devs is definitely on the roadmap.
It looks fairly useful for development! Quick questions what's the difference between you guys and any persistent development memory tools like https://github.com/thedotmack/claude-mem ?
Thanks! claude-mem captures what the AI did locally and replays it next session, great for solo continuity. Hopsule works at the organizational level: shared memories, structured decisions with lifecycle and enforcement, synced across your team via MCP, IDE extension, or CLI. Different layers, can coexist.
If you use AI coding tools like Cursor, Copilot, or Claude, you’ve probably seen this happen: The AI writes good code - but it ignores your architecture.
It doesn’t know: - why you chose a specific pattern - which conventions your team agreed on - which decisions are already locked in So it falls back to generic patterns, outdated examples, or random GitHub training data. Over time this slowly breaks the consistency of the codebase.
Most teams try to fix this with: - giant Markdown files - wiki pages - long prompts - Slack threads But those aren't machine-readable rules.
So we built Hopsule. Hopsule turns architecture decisions into enforceable context that AI tools must follow.
Example: Your team approves a decision: “All database access must go through the repository layer.” Hopsule records this as a rule and injects it into the AI context before code generation.
No giant prompts. No manual context stuffing. No architecture drift.
Website: https://hopsule.com Docs: https://docs.hopsule.com App: https://app.hopsule.com