How I built AgentRAM: a memory API for AI agents without a vector DB

I'm a solo developer in Accra, Ghana, and I just shipped my first real product. It's called AgentRAM (agentram.dev), and it's a memory API for AI agents. This is the build story and the stack.

The problem I kept seeing

Over the last year, AI agents have gone from research toys to actual things people ship. But every agent that needs to remember anything across sessions runs into the same wall: where does the memory go?

The existing answers all felt heavy for what they were doing:

• Mem0, Zep, Letta want you to set up embedding pipelines and vector databases. Powerful for RAG-style semantic search, but overkill if you just need "remember that user X likes dark mode."
• OpenAI's Assistants API memory is locked to their platform and billed per-token, which means costs are unpredictable as conversation length grows.
• Rolling your own with Postgres or Redis works, but it's a real chunk of infrastructure to maintain for each agent project, including auth, multi-tenancy, TTLs, and an HTTP layer.

I wanted something that handled the 70% case ("remember this fact about this agent") without the 100% solution's setup cost. So I built it.

What AgentRAM actually does

One HTTP call to store. One to retrieve. Scoped by agent ID, with optional TTLs and shared namespaces.

# Store a memory
curl -X POST https://api.agentram.dev/memory \
  -H "x-api-key: YOUR_KEY" \
  -d '{"agent_id":"my-agent","key":"user_pref","value":"dark mode"}'

# Retrieve it
curl "https://api.agentram.dev/memory?agent_id=my-agent&key=user_pref"
# {"value":"dark mode"}

That's the whole interaction model. No embeddings, no vector similarity, no semantic chunking, no token accounting. Just durable key-value memory scoped per agent.

Other endpoints fill in the practical needs: list all memories for an agent, full-text search across them, shared namespaces so multiple agents can read from a common pool, and atomic credit-based usage tracking so cost is predictable.

Why not just Redis or Postgres?

This is the question I keep wrestling with, so let me be honest about it.

If you're already running infrastructure for your product, you should absolutely just add a memory table to your existing database. AgentRAM isn't for you.

But for everyone else, and there are a lot of "everyone else" right now in the vibe-coding and agent-prototyping era, AgentRAM removes some real friction:

• No new infra to provision
• No auth layer to write for your agents
• No HTTP wrapper to build around your DB
• No multi-tenant logic to get right
• Built-in TTLs, search, and shared namespaces
• Predictable per-operation pricing (no per-token surprises)

It's a Twilio-style argument: yes, you could roll your own SMS gateway, but for most people, paying per-message is cheaper than the time cost.

The stack

Nothing exotic, all standard boring tech:

• API: Node.js with Express, deployed on Railway. Auto-deploys from GitHub.
• Database: Supabase (Postgres), with atomic credit-update logic so concurrent payments and reads don't race.
• Payments: Paystack. I'm in Ghana, Stripe doesn't operate here yet, but Stripe acquired Paystack in 2020. Paystack handles cards globally plus mobile money and Apple Pay, so coverage is actually broader than Stripe-alone for some users.
• Email: Resend, with Cloudflare Email Routing for inbound on [e-mail].
• DNS: Cloudflare, with WAF and rate limiting.
• Frontend: Static HTML on Netlify, with Cabinet Grotesk self-hosted. No framework, no build step, just hand-written HTML and CSS.

The whole thing is six HTML pages, one Node server, one Supabase project. It's not a lot. That's intentional.

The pricing model: credits, not subscriptions

After agonising over this, I went with credit-based pricing instead of a monthly subscription.

• 100 free credits on signup, no card required
• 1 credit per operation (read, write, delete, search all count as one)
• Top-ups: $5 for 50,000 ops, $15 for 200,000 ops, $40 for 600,000 ops
• Founding member tier: $249 one-time for 500,000 ops plus 20% off all future top-ups, for as long as the account is active

Why credits over subscriptions:

1. Aligns with how AI agent usage actually varies (bursty, unpredictable)
2. No "wasted" subscription months for users who weren't building that month
3. No churn anxiety on my side
4. The unit price is easy to reason about: 1¢ per 100 operations at the Starter tier

The downside is it's slightly weirder to project revenue against. But I'd rather have a model my users actually feel good about.

The "did it actually work" moment

I shipped this today. The full deployment took about a day, including:

• Pushing the API to Railway
• Pointing api.agentram.dev at Railway via Cloudflare CNAME
• Deploying the static site to Netlify
• Pointing agentram.dev at Netlify via Cloudflare CNAME
• Verifying Let's Encrypt SSL provisioned on both domains

Then I made my first real $5 test charge to my own account. Watched the credit count tick from 100 to 50,100. Confirmation email landed. The whole pipeline worked end to end.

That's the moment that justifies all the work that came before.

What I'm building next

The build is done. Now the harder thing: distribution. Things I'm planning over the next few weeks:

• MCP server wrapper. Anthropic's Model Context Protocol is becoming the standard for how AI tools discover and use external services. An MCP server for AgentRAM means Claude Desktop and Cline users can add persistent memory with one config line.
• LangChain memory backend. Implement BaseMemory so AgentRAM works as a drop-in memory layer for any LangChain agent.
• LlamaIndex memory module and AutoGen / CrewAI integrations for the same reason.
• Official SDKs for Python and TypeScript so the curl examples become idiomatic library calls.

What I'd love feedback on

Genuinely, not as a marketing-friendly closer. If you've built agents that need memory, I want to know:

• Does the API surface feel complete enough, or is something missing?
• What would make you pick this over rolling your own with Postgres?
• Which integration would actually move the needle for you?
• What would make you suspicious of this as a solo dev's project?

agentram.dev if you want to poke at it. 100 free credits if you want to try the API. Comments welcome here, or email me directly at [e-mail].

Comments

[mamoru kubokawa]

Shipped-the-same-day post that ends with specific questions is the right shape for build-in-public, so I'll give you specific answers.

On API surface (what's missing): the gap I'd flag — and I bet you hear it from anyone running agents in production — is a memory-lifecycle state. Your model is store → retrieve → delete, which handles "this fact exists" cleanly. The failure mode I keep hitting is stale facts: a memory that was true 2 months ago and is no longer the move, but the agent re-applies it because it's still in the store. A supersedes/superseded_by link, or a state: {live, retired} field, would let agents know which memories are still load-bearing vs. historical. It's not a vector concern, it's a temporal one, so it fits your KV-without-embeddings philosophy without dragging in semantic-search machinery.

On "why pick this over Postgres": the strongest single answer is shared namespaces across multiple agents. Rolling your own Postgres is fine until you have two agents that need to read each other's writes — at that point you're building auth, tenant scoping, and a permission model that AgentRAM hands you for free. That's the case worth leading with on the landing page; durability and TTLs are commodity comparisons.

On integration priority: MCP first, by a lot. Claude / Cline / Cursor users are the densest pool of people currently building agents who'd recognize "persistent memory" as the missing piece, and MCP is the lowest-friction install. LangChain after. CrewAI / AutoGen later — smaller, more research-flavored.

On what would make me suspicious: honestly nothing in the stack — solo dev / Paystack / boring tech / Supabase reads as serious, not sketchy. The bar I'd raise is a one-line uptime commitment (or a "last 30 days" status page) and a documented data-export path, in case you get hit by a bus. Both are cheap, and they convert "is this a real service" to "yes" for the buyer who's already convinced on price.

Founding-member $249 lifetime is a sharp acquisition wedge — what's the response rate on it relative to top-ups so far?

[Sean Markwei]

Mamoru, this is the comment I was hoping for. Going section by section because each is actionable.

On the lifecycle state. You've named something I've been bumping against without putting words to it. Right now if a user says "actually I prefer Python now, not JavaScript," the right move is delete-then-store, and the original "prefers JS" memory disappears entirely. That's wrong: I lose the agent's ability to reason about what was true historically. Between the two shapes you suggested:

• superseded_by link feels right when there's a clear successor (the JS to Python case)
• state: {live, retired} feels right when something gets retired without a successor (user stopped using Slack at all, no replacement)

I think the answer is probably both, with state as the default field and superseded_by as an optional pointer for the link case. v1.1 work, going on the list. Curious how you're handling it in practice right now: sentinel values in the value field, separate tables, something else?

On positioning around shared namespaces. You're right and the landing page is wrong. "Durability + TTLs" is what every memory product says. Multi-agent shared writes with built-in auth and tenant scoping isn't, and it's a real argument against rolling your own with Postgres. Revising the hero copy this week.

On MCP-first. That's exactly the order. I'm finishing the MCP server in the next day or two. Open question for you: are you mostly running Cline, Claude Desktop, or Cursor? If you'd want to be one of the first people to test it against a real agent setup, I'd rather get feedback from someone who's already thought this carefully about memory than ship blind and find issues in week three.

On the trust gap (uptime + data export). Both fair, both cheap, both going in. Specifically:

• A public status page (UptimeRobot or equivalent) and a documented incident history on agentram.dev within the next two weeks
• A GET /export?agent_id=... endpoint returning all memories as JSON, plus a CLI snippet in the docs that wraps it. Same fortnight.

These aren't a real SLA, but they at least signal "I treat this as a service, not a hobby project that might disappear."

On Founding Member uptake. Honest answer: zero so far. I'm 24 hours post-launch, your comment is the first real-conversation interaction, and I haven't done any outbound for the tier yet. So the truthful response is "no data, ask me again in 30 days." If it matters to your evaluation: I'm not chasing volume on that tier, I want it concentrated among people who'd be useful to think with as the product evolves. The $249 is meant to feel non-trivial for exactly that reason.

Thanks for the depth. If you want extra credits beyond the signup 100 to actually stress-test the API, email me at [e-mail] and I'll comp something useful.