I wanted AI agents to have memory. Not session memory: persistent, semantic memory they could query like a tool. What started as a local experiment turned into a cloud-hosted service that agents can pay to use.
The Problem With Stateless Agents
By default, AI agents start cold every time. No memory of past queries, no context carried forward, no awareness of what's already been searched. That's fine for one-off tasks. It breaks down fast when you're running agents at any kind of scale.
The fix I reached for was a vector database. Instead of storing raw text, it stores meaning: each piece of content gets converted into a numerical representation that captures its semantics. Similarity search then finds related content even when the exact words don't match. It's the right shape for agent memory.
Starting Local, Then Outgrowing It
I started with Qdrant running locally in Docker: open-source, fast, well-documented. A small embedding model converts text into vectors. A lightweight MCP (Model Context Protocol) server sits on top, exposing search as a tool that AI agents can call directly from their context.
It worked. But local means offline. The moment the machine sleeps, the service dies. Anything running on a schedule or queried from outside my network was a non-starter.
Time to move it to the cloud.
The Hetzner Setup
I landed on a Hetzner cloud server: 4 vCPUs, 8GB RAM, 160GB local disk for $11.99/month. Solid headroom for Qdrant, the embedding service, and the MCP layer running in parallel without fighting for resources.
| Component | Role |
|---|---|
| Qdrant | Vector database: stores and searches embeddings |
| Embedding model | Converts raw text into 768-dim vectors |
| FastMCP | Wraps search as callable MCP tools |
| Caddy | Reverse proxy with automatic HTTPS |
| x402 middleware | Payment gating per query |
Setup was clean: Ubuntu, Docker for Qdrant, a systemd service for the MCP layer, Caddy handling TLS out front. Once it was live and stable, the project's character shifted: a 24/7 service needs a reason to exist 24/7.
Gating It With Micropayments
This is where it got interesting. The x402 protocol is an emerging standard for HTTP-native micropayments. The flow is simple: a client hits an endpoint, gets a 402 Payment Required response with a payment request, settles it, and unlocks access. No accounts. No sessions. No human in the loop.
I added a lightweight x402 middleware layer in front of the MCP endpoints. Unverified requests bounce. Verified ones pass through to the vector search. Payments are fractions of a cent per query, designed for agents operating autonomously at volume, not humans paying manually.
That shift matters. An MCP server that agents can pay to query is a different thing from one that just serves you locally. It's a service. It can be discovered and consumed by any agent that needs what it holds.
What I Learned
Embeddings are the hard part. Qdrant is trivial to run. Getting consistent embeddings (same model, same preprocessing, every time) is where precision lives. Query-time and index-time embeddings need to match exactly, or recall tanks.
x402 is early but real. The tooling has rough edges and the spec is still moving. But the core mechanic works, and the mental model is clean. If you're building for agent-to-agent economies, this is the payment layer worth understanding now.
Infrastructure changes the project. Local iteration is fast and forgiving. Cloud changes how you think: uptime, latency, what it would take to serve someone else. That shift made the whole thing more serious, and more useful.
The agents need more than models. They need persistent context, reliable tooling, and payment rails that work without a human watching. A vector store exposed as a paid MCP service is one piece of that stack. I'm still building the rest.