From the team behind aidrop.it — one workspace to build, host, and keep changing your code.
Every agent past the prototype stage needs a memory layer, and you have three real options: build one on a vector database, adopt a memory framework, or connect a hosted memory over MCP. The right choice isn't about features on a comparison grid — it's about who maintains the curation, whether the memory is portable across your tools, and whether you can read and audit what's stored. Most teams overestimate "build" and underestimate the maintenance it hides.
A raw vector store is not a memory layer. It's the storage underneath one. The hard part — deciding what to write, merging duplicates, keeping facts current, retrieving the right chunk — is the work you're actually choosing how to own.
What a memory layer actually has to do
A real memory layer does four things, not one: capture knowledge as work happens (write), keep it correct over time (curate), find the right facts on demand (retrieve), and let you inspect and govern it (control). Storage solves only retrieval's bottom half. Skip curation and your memory becomes an append-only log that rots into noise.
Option 1: build on a vector DB
Building gives total control and fits when memory is core IP you must own end to end. The cost is everything above storage: you write the chunking, the dedup-and-merge logic, the ranking, the access controls, and you maintain them as models and needs change. Teams routinely ship the embed-and-search demo in a week, then spend months on the curation that makes memory useful.
Option 2: adopt a memory framework
Frameworks (Mem0, Zep, Letta, and others) give you a memory model out of the box — extraction, summarization, sometimes temporal graphs — so you're not rebuilding primitives. The trade-off is that you still run and host it, and the memory often lives inside that framework's world rather than being shared across every tool you use. Great when memory lives inside one app you control.
Option 3: connect a hosted memory over MCP
If your agents already speak MCP, the lightest path is a hosted memory any client connects to — no infra to run, and the same store serves every tool at once. You own the curation outcome without owning the pipeline.
How to actually decide
Ask three questions. Is the memory shared across multiple tools, or trapped in one app? Who keeps it curated — your engineers, or the layer? Can you read, audit, and roll back what's stored? If memory must span tools and you'd rather not staff its upkeep, buy or connect. If it's single-app core IP, build. The deciding factor is maintenance and portability, not the feature list — and portability is a property you test once, before you need it, rather than one you take on trust. For the underlying concepts, see AI agent memory explained. The same maintenance-vs-portability tradeoff resurfaces once the memory layer has to actually run somewhere — see the deployment gap for AI-built apps.
FAQ
Is a vector database an AI memory layer? No — it's the storage under one. A memory layer adds the write path, curation (merge, dedup, update), retrieval logic, and governance. Standing up a vector DB is the easy 20%; the curation is the 80%.
When should I build my own memory instead of buying? Build when memory is core IP that must live inside one app you fully control and you can staff its ongoing curation. Otherwise a framework or a hosted MCP memory service gets you a maintained, portable layer far faster.
What's the advantage of an MCP-based memory? Portability. Because MCP is an open protocol, one store serves Claude Code, Codex, ChatGPT, and any other client at once, instead of each tool keeping a separate silo you sync by hand.
One workspace to build, host, and keep changing your code
The repository, what the project knows, the rules a change has to follow, and the path to an address — kept together, and reachable by the coding agent your team already uses.