Unabyss
MCP-native self-updating context layer for your AI
2.4K followers
MCP-native self-updating context layer for your AI
2.4K followers
Set it up once and never re-explain yourself to AI again. Connect the apps you use daily - Unabyss will extract, structure, and update your context automatically. Share it with any AI tool via MCP, with granular control over what each tool can see.
This is the 2nd launch from Unabyss. View more
Unabyss for Claude
Launched this week
Claude doesn't know what happens in GPT. Neither one really knows who you are or what your company does. Now they can.
Unabyss gives Claude memories from your other AI agents and everyday apps: email, Drive, GitHub, Notion, meeting recorders, and 20+ more. It saves new memories too, so GPT and Cursor stay in sync with the exact same context - sharper than wiring each tool into Claude one by one.
Finally, a real memory that follows you. Private. Portable.
Free Options
Launch Team / Built With
Unabyss
Hey PH 👋 Philip here, co-founder of Unabyss.
Our first launch, back in May, ended up winning #1 product of the day - still can't quite believe that one. Thank you!
Since then, we listened to your feedback & rebuilt the whole thing around one idea: your context should live where you actually work. So we moved Unabyss into Claude.
What's new since May - and why we're relaunching:
Claude-first, MCP-first. No browser needed anymore. Connect the MCP once, and everything happens inside Claude.
The part we're most excited about: save context from any Claude chat into Unabyss - and reuse it in Cursor, GPT, or any other agent. What you work out in one place carries over everywhere. Memory that follows you, instead of resetting every session.
Rebuilt the MCP from scratch, now loaded with 60+ skills - Claude just works with your context. No setup, no copying files between tools.
15+ new integrations along the way: Obsidian, HubSpot, Notion, Asana, GitLab, and more.
Who it's for: builders wiring up AI tools, founders juggling context across a dozen apps, consultants who live in other people's stacks. Anyone tired of re-briefing their AI every morning.
Last time, we shipped a context layer you configured in an app. This is context that lives in Claude and travels with you.
We're around all day - try it at unabyss.com and tell us how you'd use portable memory, and what's missing. Tear it apart!
Yours,
Philip & the Unabyss team
@philip_kubinski the line i'd underline in the pin is 'save context from any claude chat'. i keep md context files across four repos and the same fact lives in all four — nothing tells the other three when one changes. and that's the tidy layer: yesterday i pulled a price into a single constant, and the stylesheet next to it was still describing the old one in a comment. storing the file somewhere better wouldn't fix that. the file being a byproduct instead of a chore might.
Unabyss
@webappski this is exactly it. the same fact living in four files with nothing to reconcile them is the whole problem - and your stylesheet-comment example is painfully familiar.
the moment context is a file you maintain, it drifts, because keeping four copies honest is a chore nobody does.
"byproduct instead of a chore" is a better line than anything in our pin, honestly. that's the bet: context you use stays current because using it updates it, instead of context you have to remember to go edit.
the price you pulled into a constant yesterday - that's a decision, and it should propagate to wherever that price is described, not sit in one repo waiting for you to notice the other three.
curious where it breaks for you though: with md files across repos you've at least got git history and diffs. what would you actually need to trust a shared layer over four files you can see? that's the honest gap we're still working on.
@philip_kubinski This looks like the right direction. Portable memory is much more useful when it lives inside the actual tools people already use .
One question: how do you handle memory conflicts when different tools have slightly different or outdated context? For example if Claude saves one version of a project detail but Cursor or Notion has a newer one, does Unabyss rank, merge, or ask the user to resolve it?
I live in Claude Code all day and maintain CLAUDE.md files across client projects, so the line about a context file being frozen the moment you write it hit home. Mine rot quietly until something breaks. Spent a while on your landing and FAQ before commenting, the comparison against built-in memory and plain context files is the clearest pitch I have seen for this category, and tagging by topic, sensitivity and source is the part that actually matters.
Two honest questions before I plug it into client work. First, when a wrong fact gets extracted from an old Slack thread, where do I see and fix it before it follows me into every tool? A reviewable, editable memory list would be the make or break feature for me. Second, for the agency use case, how confident are the sensitivity tags in practice? One client detail leaking into another client's session over MCP would end the experiment instantly.
Upvoted, and the Pro plan pricing next to a Claude Max subscription is smartly placed.
Unabyss
@abdullah_javaid3 appreciate your feedback!
1. Wrong facts -> we have conflict resolution in place, so incorrect information won't be retrieved from memory. Facts are cross-checked against other, more recent memories before they're retrieved.
2. Source tagging is bulletproof. Permissions for sensitive/confidential data are handled by the agent, so I can imagine edge cases where things don't work exactly as intended. Agency use-case is very specific and we're launching the agency context architecture soon. Memory silos will be fully isolated, making this 100% secure. Until then, I'd recommend using source-level (connection-level) permissions.
Happy to update you when 2) is live!
@marcin_uchacz1 thanks Marcin, that helps. The recency weighted cross check is a sensible way to handle stale facts, and I saw Philip mention Context View landing Monday, which covers the reviewable memory list I was asking for. Good timing.
On the agency side, I noticed a few of us in this thread are circling the same worry, so the isolated silos launch will matter to more people than just me. Please do tag me when it is live. I will put two real client projects on it that same week and report back honestly.
Unabyss
@abdullah_javaid3 I'll make sure to do so!
Unabyss
@abdullah_javaid3 About the wrong facts and conflicts, we have the conflict resolution engine that works in the background. But if it misses something, you can always adjust it in any agent the Unabyss is connected to or in our in-app context chat. Fixed in one place - fixes it everywhere.
Our permission layer is overprotective. So it is more likely you will get less confidential data than it will return something that it should not.
If you could find time to share your feedback from using Unabyss, it would be great - we ship every day, so if something does not work perfectly, it should be fixed in a few days ;).
@dominik_bartosik appreciated, Dominik. Fix in one place fixes everywhere is the behavior I was hoping for, and overprotective is the right default for a permission layer. False negatives are annoying, false positives are fatal. I will give it a proper run on my own workflow first, before any client data goes near it, and post what I find in this thread. Shipping every day makes that feedback feel worth writing.
Unabyss
@abdullah_javaid3 thanks a lot! Can't wait to hear more form you ;)
Congrats on the launch! The retrieval-time conflict resolution looks to be the crucial part? A lot of memory layers just dump everything into context and let the model referee - but you look to be on the right path. QQ - recency as the tiebreaker assumes newer means truer, but a stable preference from 3 months back usually beats something I typed once yesterday in a bad mood right? How do you guys tell a durable fact from a throwaway one when the two collide?
Unabyss
@artstavenka1 thanks! We have a complex conflict resolution engine. When some memories conflict, we don't rely only on the date but also on the source, repetition, who the author is, etc. If automatic resolution raises concerns, we are adding a note explaining why this data changed and when.
I run a hand-rolled version of this for a fleet of Claude agents — plain files, one fact per file — and the failure mode that taught me the most wasn't retrieval, it was propagation: one agent writes a fact that's slightly wrong or goes stale, and every other agent confidently inherits it. So my question is about contradictions: when a fresh observation from Gmail disagrees with an old memory that came from Notion, does the old one get overwritten, versioned, or decayed? And can I audit which app wrote a given memory? Provenance is the part I'd actually pay for.
Unabyss
@mystoryland Hi Olga, in Unabyss, you can see what the source origin is. In terms of conflicts, we have a resolution engine that checks incoming memories against existing data and evaluates them based on date, origin, author, and other factors. Most of the time, it handles it well, but if it gets unsure, then it will leave a note next to the change, explaining why and when it happened.
The hard part with shared memory is not storage, it is correction. If a bad fact gets extracted from Slack or an old doc, teams need to see source, freshness, confidence, and the exact downstream places that may now be wrong. That audit trail is what makes portable context usable for real work.
Unabyss
@krekeltronics for situations like this, we have a conflict-resolution engine that runs in the background. But if it misses something, you can correct the context in any agent the Unabyss is connected to or in our in-app chat. It needs to be corrected once, then it will be right everywhere.
Your pitch sounds compelling, but what's the actual technical moat compared to existing MCP servers, RAG pipelines, and personal knowledge systems? For example, I can already connect Claude/GPT to Gmail, Google Drive, GitHub, Notion, Slack, and meeting transcripts using OpenMemory, Mem0, Zep, Graphlit, LangChain/LlamaIndex, or even custom MCP servers. Beyond packaging and UX, what is genuinely difficult to replicate? Why couldn't a competent engineer build an equivalent system in 7–14 days using existing APIs and open-source infrastructure?
How do you resolve conflicting memories across different sources?
How do you decide what deserves to become a long-term memory versus transient context?
Is your advantage primarily data ingestion, memory consolidation, retrieval quality, or simply convenience?
One more question: doesn't your business model create a "double payment" problem? Users already pay subscriptions for GPT, Claude, or Cursor. If Unabyss sits in the middle and consumes additional tokens to build and maintain shared memory, doesn't that mean users end up paying twice for essentially the same AI stack? How do you address that concern?
Unabyss
@piotr_wasaznik a short answer is: you need a solid team of top-notch engineers to build and maintain a memory system, plus implement efficient retrieval.
And that's not even the hardest part. The real challenge is parsing and structuring the data, not just pulling it. You can't simply dump your entire GDrive into a RAG pipeline (or any memory system) and expect good results without proper parsing.
But let's break it down.
MCP servers
-> a single MCP server isn't a memory system. It's just a way to access data.
-> agents struggle with cognitively demanding (summaries, analysis, reports, brainstorms, decision-making) when they're limited to a single MCP (single source) because they lack context from the rest of your stack. Imagine analyzing an ad campaign without understanding the user journey after the click, your ICP, or your value proposition - surely you're going to draw wrong conclusions.
-> cross-source reasoning is also extremely expensive. Most agents pull far too much data, still miss the relevant context, and end up reasoning over noisy inputs. (re double payment, too)
RAG
-> realistically, 99% of people can't set up a production-quality RAG.
-> even when implemented correctly, RAG alone doesn't work for context retrieval in most real-world workflows. (we tested it early on, and it just fails)
Memory systems
-> setup requires senior engineers.
-> BUT once you get into conflict resolution, deduplication, ranking, and optimization, it starts looking less like a weekend project and more like a PhD thesis.
Double-payment
-> we use LLMs once to ingest and structure data into memory.
-> without a memory layer, your agent has to repeatedly process the same raw data every time you ask a question. In practice, can get 10× or 100x more expensive if you do it often.
So our core advantage is ingestion breadth × consolidation × retrieval precision. Essentially, means democratizing access to high-quality AI memory for everyday use cases.
We're making something that normally requires an elite engineering team available to everyone :)
Can you say more about the 60+ skills? Do they work only with Unabyss or standalone?
Unabyss
@przemek_budny great question!
You can find all of them here -> https://unabyss.com/skills. It's a mix of skills developed in-house & forks of most starred skills.
You use them along with Unabyss -> it delivers the context needed to deliver the output. E.g. if you use skill "positoning", Unabyss will feed the AI agent with all the data associated with your product, market, competitors, marketing, and more.
Let me know which skill you've tried out! :)
Unabyss
@przemek_budny skills are solely designed to leverage your context provided via Unabyss, so you need only Unabyss to take advantage of them ;).