{"slug": "how-i-built-agentram-a-memory-api-for-ai-agents-without-a-vector-db", "title": "How I built AgentRAM: a memory API for AI agents without a vector DB", "summary": "A solo developer in Accra, Ghana, has launched AgentRAM, a memory API for AI agents that eliminates the need for vector databases or embedding pipelines. The service provides durable key-value memory storage through simple HTTP calls, scoped by agent ID with optional TTLs and shared namespaces, targeting the common use case of remembering facts about agents without the overhead of full RAG infrastructure. Built on Node.js, Supabase, and Paystack, AgentRAM uses a credit-based pricing model starting at 100 free credits with no card required.", "body_md": "I'm a solo developer in Accra, Ghana, and I just shipped my first real product. It's called AgentRAM ([agentram.dev](https://agentram.dev)), and it's a memory API for AI agents. This is the build story and the stack.\n\n##\nThe problem I kept seeing\n\nOver 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?\n\nThe existing answers all felt heavy for what they were doing:\n\n-\n**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.\"\n-\n**OpenAI's Assistants API memory** is locked to their platform and billed per-token, which means costs are unpredictable as conversation length grows.\n-\n**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.\n\nI wanted something that handled the 70% case (\"remember this fact about this agent\") without the 100% solution's setup cost. So I built it.\n\n##\nWhat AgentRAM actually does\n\nOne HTTP call to store. One to retrieve. Scoped by agent ID, with optional TTLs and shared namespaces.\n\nThat's the whole interaction model. No embeddings, no vector similarity, no semantic chunking, no token accounting. Just durable key-value memory scoped per agent.\n\nOther 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.\n\n##\nWhy not just Redis or Postgres?\n\nThis is the question I keep wrestling with, so let me be honest about it.\n\nIf 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.\n\nBut 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:\n\n- No new infra to provision\n- No auth layer to write for your agents\n- No HTTP wrapper to build around your DB\n- No multi-tenant logic to get right\n- Built-in TTLs, search, and shared namespaces\n- Predictable per-operation pricing (no per-token surprises)\n\nIt'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.\n\n##\nThe stack\n\nNothing exotic, all standard boring tech:\n\n-\n**API:** Node.js with Express, deployed on Railway. Auto-deploys from GitHub.\n-\n**Database:** Supabase (Postgres), with atomic credit-update logic so concurrent payments and reads don't race.\n-\n**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.\n-\n**Email:** Resend, with Cloudflare Email Routing for inbound on [hello@agentram.dev](mailto:hello@agentram.dev).\n-\n**DNS:** Cloudflare, with WAF and rate limiting.\n-\n**Frontend:** Static HTML on Netlify, with Cabinet Grotesk self-hosted. No framework, no build step, just hand-written HTML and CSS.\n\nThe whole thing is six HTML pages, one Node server, one Supabase project. It's not a lot. That's intentional.\n\n##\nThe pricing model: credits, not subscriptions\n\nAfter agonising over this, I went with credit-based pricing instead of a monthly subscription.\n\n- 100 free credits on signup, no card required\n- 1 credit per operation (read, write, delete, search all count as one)\n- Top-ups: $5 for 50,000 ops, $15 for 200,000 ops, $40 for 600,000 ops\n- 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\n\nWhy credits over subscriptions:\n\n- Aligns with how AI agent usage actually varies (bursty, unpredictable)\n- No \"wasted\" subscription months for users who weren't building that month\n- No churn anxiety on my side\n- The unit price is easy to reason about: 1¢ per 100 operations at the Starter tier\n\nThe downside is it's slightly weirder to project revenue against. But I'd rather have a model my users actually feel good about.\n\n##\nThe \"did it actually work\" moment\n\nI shipped this today. The full deployment took about a day, including:\n\n- Pushing the API to Railway\n- Pointing api.agentram.dev at Railway via Cloudflare CNAME\n- Deploying the static site to Netlify\n- Pointing agentram.dev at Netlify via Cloudflare CNAME\n- Verifying Let's Encrypt SSL provisioned on both domains\n\nThen 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.\n\nThat's the moment that justifies all the work that came before.\n\n##\nWhat I'm building next\n\nThe build is done. Now the harder thing: distribution. Things I'm planning over the next few weeks:\n\n-\n**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.\n-\n**LangChain memory backend.** Implement `BaseMemory`\n\nso AgentRAM works as a drop-in memory layer for any LangChain agent.\n-\n**LlamaIndex memory module** and **AutoGen / CrewAI integrations** for the same reason.\n-\n**Official SDKs** for Python and TypeScript so the curl examples become idiomatic library calls.\n\n##\nWhat I'd love feedback on\n\nGenuinely, not as a marketing-friendly closer. If you've built agents that need memory, I want to know:\n\n- Does the API surface feel complete enough, or is something missing?\n- What would make you pick this over rolling your own with Postgres?\n- Which integration would actually move the needle for you?\n- What would make you suspicious of this as a solo dev's project?\n\n[agentram.dev](https://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 [hello@agentram.dev](mailto:hello@agentram.dev).", "url": "https://wpnews.pro/news/how-i-built-agentram-a-memory-api-for-ai-agents-without-a-vector-db", "canonical_source": "https://dev.to/seanmarkwei/how-i-built-agentram-a-memory-api-for-ai-agents-without-a-vector-db-281", "published_at": "2026-05-28 18:18:36+00:00", "updated_at": "2026-05-28 18:26:50.061155+00:00", "lang": "en", "topics": ["ai-agents", "ai-products", "ai-tools", "ai-infrastructure", "ai-startups"], "entities": ["AgentRAM", "Mem0", "Zep", "Letta", "OpenAI", "Postgres", "Redis", "Accra"], "alternates": {"html": "https://wpnews.pro/news/how-i-built-agentram-a-memory-api-for-ai-agents-without-a-vector-db", "markdown": "https://wpnews.pro/news/how-i-built-agentram-a-memory-api-for-ai-agents-without-a-vector-db.md", "text": "https://wpnews.pro/news/how-i-built-agentram-a-memory-api-for-ai-agents-without-a-vector-db.txt", "jsonld": "https://wpnews.pro/news/how-i-built-agentram-a-memory-api-for-ai-agents-without-a-vector-db.jsonld"}}