pumaDB
a small hosted memory layer for AI agents
172 followers
a small hosted memory layer for AI agents
172 followers
Most AI agent workflows lose useful context between sessions, tools, and chats. The usual fixes are either too manual, like copying notes into docs, or too heavy, like setting up a database, vector store, or custom RAG stack. pumaDB gives agents a simple shared place to save and reuse notes, facts, preferences, project context, transcripts, task state, and other useful memory. No database setup, vector DB, or infrastructure to manage
pumaDB
The transcripts example resonates. I've got the same problem with a different domain. Iterative LLM workflows where each session starts cold means re-feeding context that should persist.
For "what would agents remember automatically": the thing I'd actually pay for is automatic capture of failed attempts and why they failed. Most memory tools focus on remembering successful artifacts. The harder and more valuable thing is remembering the dead ends so the agent doesn't try the same broken approach next session.
MCP-first feels right for the dev audience. Curious if you're planning to expose the memory as a queryable index later or keeping it strictly key/notes.
pumaDB
@joshua_santiago2
appreciate the comments and thoughts. hmm, thats an interesting point on failed attemts. i can imagine there might be something clever that is hooks based that could just straight link into pumaDB....could be interesting.
On queryable index vs key/notes: the current bias is to keep pumaDB explicit and structured first, rather than turning it into another “embed everything and hope retrieval works” system.
That said, I do think search/query matters as the memory grows and I'm sure as we figure out most popular use cases for people that will drive the decisions, in the short term though I just want the core memory to stay readable and inspectable, not become an opaque vector blob.
Nice launch. The memory I’d trust most is not just facts, but attempts: what the agent tried, why it failed, and which tool or write it was allowed to use next.
If a memory is wrong or stale, does pumaDB show who or what wrote it and let builders expire or correct it?
pumaDB
@blah_mad this has been more about storing artefacts in memory but you do share an interesting use case which i might explore (as its been mentioned a few times now).
On stale/wrong memory: pumaDB rows are inspectable and editable, and updates/deletes keep previous versions for recovery. So builders can review, correct, or restore memory rather than treating it as an invisible model-owned blob.
The “who/what wrote this and when should it expire?” side is something I’m thinking about more as usage grows. I think provenance and lifecycle matter a lot if agent memory is going to be trusted, especially for coding and workflow automation.
That makes sense. Inspectable rows plus version recovery already covers a lot.
The bit I’d probably make first-class next is provenance per memory: source agent or tool, run id, when it should expire, and whether it is safe to reuse automatically. Are you thinking row-level provenance, or more of a workspace history first?
pumaDB
@blah_mad I think row-level provenance is probably the more useful primitive, as users are likely using this as an agent first google drive replacement, so individual documents get updated you could see versions like you would in docs/notion.
workspace/run history as supporting context could be interesting to explore further but the tricky part is keeping it simple. I don’t want pumaDB to turn into a heavy governance system unless customers are really asking for it but at that point you are probably evaluating more robust db infra anyway
Yeah, I’d keep that boundary. Optional row metadata feels like enough for now: source, last writer, version, expiry hint, maybe a short “safe to reuse” flag.
If teams later ask for policy, they’ll probably want it outside the memory table anyway.
I have seen teams, including my own, avoid memory because setting up a database or vector store feels too heavy for early workflows. How do you decide what should be saved as memory and what should stay out? Can developers inspect and clean up memory when an agent saves something wrong or outdated?
pumaDB
@margharitha Yeah, nice, thats exactly what has happened to me too.
So far from me and users, it’s mostly stuff that otherwise ends up in Google Drive, a spreadsheet, a doc, Notion, or some “maybe this should be a database but it’s probably not worth setting one up” place. It could be document style artefacts or very light data tables (sub 1000 rows). Users who are building demo apps and want a live backend to show their boss but don't want to set up supabase.
The important bit for me is that it needs to be globally scoped. Not trapped inside one chat thread or one tool.
So if an agent saves a useful note, transcript, decision, preference, or bit of project context, I want Claude, ChatGPT, Codex, Conductor, or whatever comes next to be able to use it too.
And yes, developers can inspect and clean up memory. pumaDB is deliberately not an invisible memory blob. It’s stored in readable tables, so you can review, edit, delete, or correct what agents save.
@stusim That's super cool. There is definitely a lot of natural language context that is getting lost across conversations between these tools. Excited to see where pumaDB goes :)
pumaDB
@naresh_chandanbatve @grey_seymour thanks so much for helping out Grey, totally nailed it.
pumaDB
@naresh_chandanbatve
Yes, that’s the goal.
pumaDB is MCP-first, so you can connect it to tools that support MCP/custom connectors.
For Claude, you can add it as a custom connector.
For ChatGPT, you can connect it through the custom app / connector flow where available.
Once connected, the agent can read and write to the same pumaDB memory from inside the chat interface. So you can save something in Claude, then later ask ChatGPT to use that same saved context, assuming both are connected to the same pumaDB account.
https://pumadb.ai/install is a link you can give to your ai tool to help if need but the setup is basically: paste the hosted MCP URL, verify access, and then the memory tools become available inside the chat.
I really like the pitch for this. I too have run into this problem, and not everyone has the time, energy, and willpower to research all of the different skills and scaffolding and harness options to make your own ideal memory layer. Speeding up that whole process, to me, is a very empowering thing to give to people.
pumaDB
@gmedlin Appreciate that Garett. That’s very much the idea.
There are definitely ways to build your own memory layer if you have the time and energy: vector DB, custom schema, markdown/wiki setup, MCP server, syncing, cleanup, etc.
But for a lot of people, that’s just too much scaffolding before they can even start using agents properly.
The goal with pumaDB is to make the simple version easy: connect it, save useful context, and let your agents use it later.
You can always build something more custom once you know exactly what you need, but I think there’s a big gap for “I just want my agents to remember useful stuff without turning this into an infrastructure project.”