Agent memory without a vector database

Most guides assume that giving an AI agent memory means standing up a vector database and an embedding pipeline. For a large share of real agent work, it doesn't. Here is when you actually need a vector database, when you don't, and what to use when you don't.

The problem: memory has become heavier than the job

The common path for adding memory to an agent looks like this. Pick a vector database. Stand it up or sign up for the managed version. Choose an embedding model. Write the pipeline that chunks text, generates embeddings, and upserts them. Tune the retrieval: top-k, similarity thresholds, re-ranking. Pay for the database, the embedding calls, and the time spent maintaining all of it.

That is a reasonable amount of work, and for some agents it is worth it. But a lot of developers reach for this stack by default, then discover their agent was only ever doing this:

• Remembering a user's preferences between sessions.
• Storing the result of a step so a later step can use it.
• Keeping a running state that outlives a single run.
• Sharing a small pool of facts across a few cooperating agents.

None of those need semantic similarity search. They need a place to put a value under a key and get it back later. Reaching for a vector database to do that is like installing a search engine to look up a phone number you already know the name for.

When you genuinely need a vector database

To be fair to the vector-database approach, here is where it earns its place. Use one when your agent has to answer questions like "find me the passages most similar in meaning to this query" over a corpus you cannot index by exact keys.

• Retrieval-augmented generation over a large document set, where the agent must surface relevant chunks by meaning, not by exact match.
• Semantic search across thousands of freeform notes where the user's query words won't match the stored words.
• Deduplicating or clustering large volumes of unstructured text by similarity.

If that is your problem, a vector database is the right tool, and dedicated memory platforms that build on vectors and graphs, such as Mem0, Zep, and Letta, are worth evaluating. We keep honest, side-by-side comparisons of those on their own pages, linked at the bottom.

When you don't

If your agent's memory is structured, meaning you know what you stored and roughly how you'll ask for it, you can skip the entire vector stack. Structured agent memory usually looks like named values, scoped to an agent or a shared workspace, retrieved by key or by a straightforward text search over keys and values.

For that shape of memory, a plain HTTP API is faster to adopt, cheaper to run, and has nothing to maintain. There is no embedding model to choose, no index to tune, and no separate database to keep alive.

The simpler alternative

AgentRAM is a memory API built for the structured case. One HTTP call stores a memory. Another retrieves it. Memories are scoped by agent, and multiple agents can share one namespace, which makes multi-agent setups straightforward without extra coordination code. There is no vector database, no embedding pipeline, and no graph to configure.

Storing a memory is one request:

curl -X POST https://api.agentram.dev/memory \
  -H "x-api-key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"agent_id":"support-bot","key":"user_language","value":"French"}'

Reading it back is another:

curl "https://api.agentram.dev/memory?agent_id=support-bot&key=user_language" \
  -H "x-api-key: YOUR_KEY"

Pricing is per operation. One store or one retrieve costs one credit. New accounts start with 100 free credits and no card. If your agent's memory needs grow into true semantic search later, you can add a vector layer then, for the part that needs it, without having paid for it before you did.