Built a tool for myself and now I'm not sure what category it belongs in
I've been using KeepDB internally for months and recently started opening it up to other people.
It started because I had customer feedback from my apps, waitlist signups, notes, research, prompts, docs, and agent memory scattered across different places. Some of it belonged in a database, some in documents, and some was just context I wanted my agents to remember.
So I ended up building something that sits somewhere in the middle. Agents can save and search memories, but I can also use the same data through an API like a simple database. Everything is organized into folders so feedback doesn't get mixed with research, docs, prompts, or agent memory.
The funny thing is that most of the work wasn't storage. It was retrieval. Saving information is easy. Finding the right thing months later is hard.
I'm still trying to figure out where this fits. It's not trying to replace Postgres. It's not a traditional knowledge base. It's also not just memory for a single AI agent.
Curious what you're using today for feedback, notes, prompts, docs, and agent memory if you're building AI products.
The category confusion is a positioning trap, not a product problem. Trying to name a brand-new category this early forces you to educate the market before you can sell to it, and that is the most expensive path there is. So do not position by what it is (a flexible layer between a database and a knowledge base). Position by the one job a specific buyer already hires something for and has budget to solve. Right now agent memory is the hottest of those, people are actively searching for it and have money to spend. Lead with that even though your tool does more. You can widen the story later once paying users pull you toward it. And your own line gives away the wedge: the work was retrieval, not storage. Finding the right thing months later is the painkiller, saving it is the vitamin. Sell the painkiller. If you had to win one buyer this quarter, is it devs building agents or operators drowning in scattered docs? Pick one and the category names itself.
The "agent memory" framing is interesting right now specifically because it's a category people are actively searching for and not finding a clear answer to. API database and feedback store are understood categories with established alternatives. Agent memory isn't — which means you could own the framing before it gets crowded.
The retrieval angle you mentioned is probably the wedge regardless of which category you lead with. Storage is a commodity. Finding the right thing 3 months later when you can't remember what you called it — that's an actual unsolved problem that people complain about. If KeepDB solves retrieval better than a pile of Notion pages or a folder of markdown files, that's the headline, and the category follows from who feels that pain most acutely.
One question worth sitting with: who's going to feel that pain at 2am and Google something because of it? That person's search query is your category.
The category question usually doesn't get answered by thinking harder about what the thing is. It gets answered by which framing strangers click.
You already named the three jobs it could be: agent memory, a simple API database, and an organized store for feedback/notes/docs. That's not one product for one buyer. It's three different landing pages for three different people.
What I'd do: stand up two or three dead-simple pages, each leading with ONE of those jobs as the headline and a priced CTA. Same tool underneath, different promise on top. Send a little cold traffic to each and watch which one gets clicks from people who don't already know you. The winning headline is your category, and the people who clicked are who you build for. Cheaper than guessing and you get a real answer in a week.
One trap: don't read signal off your existing users or this thread. They like you already, so they'll be generous about all three framings. You want the cold click, someone with no relationship to you choosing to act.
On your actual question, I split that stuff by job too: feedback and captures in a real table I can query, looser notes and prompts somewhere searchable. The pain you named, retrieval beating storage, is the real wedge. If KeepDB nails "find the right thing months later" better than a folder of docs, lead with that pain, not the storage.
That's an interesting way to think about it.
The part that resonates most is the retrieval point. The more people reply, the more I'm realizing I spend very little time talking about storage and a lot of time talking about finding things later.
The 3-job point is something I've been thinking about as well. Although I wonder whether those are actually different products or just different types of information being stored. Customer feedback, notes, docs, prompts, and agent memory all feel very different on the surface, but the underlying job might just be "store context and retrieve it when needed."
Either way, I think you're right that real signal probably comes from cold users rather than me trying to reason my way into a category.
It sounds like an context manager. You're holding onto data from multiple sources (docs, notes, db, etc.), you're organizing them, and getting the data when needed.
Genuine question: for someone not yet building multi-agent systems, how does this compare to just using Notion with an API connector?
I get the value for agents that need to read/write programmatically, but I'm trying to understand where the line is between "Notion is enough" and "you actually need KeepDB".
Fair question. If someone only wants a document editor, I'd probably recommend Notion. I actually use KeepDB quite a bit outside of agent workflows. For example, I use it as a notes app through the API, to collect customer feedback, store form submissions, save emails, and as a quick database for project data that doesn't really justify creating tables and schemas. Agents are one use case, but a lot of the value for me comes from having a single searchable place for information coming from different sources.
What stood out to me isn't where KeepDB fits today.
It's whether the category question is even the right question to solve first.
The tricky part is that the same product can look like several different things depending on which usage pattern ends up mattering most.
That's what makes this kind of decision difficult early on.
Not because the product is unclear.
Because several interpretations can feel equally valid before enough evidence exists to separate them.
I think that's a fair point.
A lot of the confusion probably comes from the fact that KeepDB started as an internal tool, so I built features around my own workflows rather than around a specific category.
Today I use it for agent memory, but also for things like customer feedback, form submissions, emails, notes, research, and other project data. Some people might see that as a context manager, others as a lightweight database, and others as a memory system.
My guess is the answer won't come from me deciding what category it belongs to. It'll come from seeing what people consistently use it for over the next few months.
Right now I'm mostly trying to learn which usage pattern ends up being the most valuable in practice.
The part I'd be hesitant to assume is that usage patterns automatically reveal the right interpretation.
Sometimes the same pattern can support several very different conclusions.
If you're curious, drop your email and I'll send over the tighter version.
That's a good point.
Honestly, if you're interested, I'd be happy to just give you free access to KeepDB and see how you naturally end up using it. No expectations or specific use case in mind.
You can use it however you want agent memory, notes, feedback collection, docs, research, workflows, or something I haven't even thought of yet.
Sometimes watching what people actually do with a product is more useful than debating what category it belongs to.
If you're interested, just drop me an email and I'll send over an invite.
I appreciate the offer.
The reason I stopped short isn't because I think more usage data would necessarily resolve the question.
It's because I think the harder part is deciding what conclusion deserves confidence once that data starts arriving.
I'd be careful with that.
If you'd like the tighter version, feel free to email me directly.
I'd love to read the tighter version. I couldn't find a contact method on your profile. Feel free to shoot me an email at [email protected] if that's easier.
Sent you a note by email.
I think the interpretation question matters more than the category discussion right now.