Show HN: A Lightweight, Stateless Database for Agent Memory

By Anup Talwalkar | Polign Blog | August 24, 2026

I have spent a significant amount of time contemplating the nature of memory for AI agents. Specifically, I've been focused on two primary challenges:

1. How to ensure memory is reliable and deterministic.
2. Where that memory should reside when the agent is deployed on hardware with strict constraints.

My research eventually merged these two concerns into a single architectural solution.

---

🧠 The Need for Deterministic Memory

When working with Large Language Models (LLMs), I noticed a recurring pattern: models often struggle with specific behaviors, occasionally missing details or simply forgetting them.

The "Memory Drift" Problem

I encountered several frustrating scenarios:

• Fact Regression: I would correct a specific piece of information, only for the agent to quote the outdated original version a week later.
• Conflicting Recall: After updating a preference, the retrieval system would return both the old and new versions, forcing the model to guess which one was current.

Currently, the industry standard is to force the LLM to resolve these conflicts by re-reading historical text. This approach is inefficient:

• Token Cost: It consumes precious tokens.
• Accuracy Loss: It relies on semantic retrieval, which can be imprecise.

The Solution: Typed Memory

Instead of letting the model "figure it out," we can use a schema with defined types and supersession rules. This transforms a cognitive burden into a database query.

By moving these decisions into the schema, the model simply extracts a fact, and the database determines its actual meaning and validity.

---

☁️ Edge-First, Stateless Infrastructure

My experience at Google Cloud Storage revealed the massive amount of infrastructure required for basic semantic storage. The operational overhead scales poorly as the corpus grows.

"Hot vector indices—requiring RAM or SSDs for availability and replication—are prohibitively expensive for users who only perform infrequent, 'cold' queries."

Most existing designs assume a managed API or a heavy search cluster. However, since embedding models now run efficiently on CPUs, I envisioned a different path.

Introducing polign_db

I built polign_db as a typed database utilizing a hybrid Vector + BM25 engine that lives directly in an object store.

Key Technical Properties:

• Statelessness: The server holds no durable state. If a process crashes or a machine restarts, the memory remains intact in the object store.
• Efficiency: It is designed for "cold-first" access, ensuring query costs do not scale linearly with the size of the corpus.

Performance Metrics

The efficiency of this approach is evident in the demo:

• Scale: 12.5 million passages served from S3.
• Footprint: Server idles at $\approx 37 \text{ MiB RSS}$.
• Hardware: The entire stack (embedder, web app, and DB) fits on a 2 GB ARM machine.

$\text{Total Memory} \approx \text{Embedding Generation} + \text{Query Concurrency} + \text{Minimal DB Overhead}$

---

🛠️ Running the Agent Memory Demo

The Agent Memory Demo on GitHub provides a CLI that utilizes polign_db to show how structured memory enables better agent decision-making.

Setup Checklist

• Install Polign Server:

  curl -fsSL https://get.polign.com | sh
  

• Install Go: (Required to run the demo via go run)
• Configure API Keys: Export your keys as ANTHROPIC_API_KEY or OPENAI_API_KEY.

Execution

Point the demo to a local directory:

./run-demo.sh fs:./demo-bucket

Note: Claude is the default. To use GPT-5, use: ./run-demo.sh fs:./demo-bucket -model gpt-5

Example Interactions

1. Storing a Preference User: "I use Vim as my editor." Internal Action: remember_preference({"subject":"user","predicate":"prefers_editor","value":"vim"}) Result: {"stored":{"id":"m-...","value":"vim","status":"active",...}}

2. Structured Filtering User: "Is my step goal above 8000?" Internal Action: recall({"subject":"user","predicate":"daily_step_goal","value_min":8000}) Result: {"count":1,"records":[{"value":9000,...}]}

Crucially, the comparison ($9000 > 8000$) happens inside the database. The LLM never has to manually parse a paragraph to perform basic math.

---

🏗️ The Future: The Local Agent Stack

I anticipate a shift toward a "boring" stack of small, efficient components:

As local models evolve, the entire agent can migrate to the device. In this world, memory is no longer a subscription service or an afterthought—it is a local utility.

📩 Get in Touch

While the demo is open source, the core polign_db remains closed source. However, the downloads and demo are completely ungated.

If you're interested, leave your email on the signup page, and I'll get back to you (usually within a few hours).