DEV Community: Shiv Shankar

Architecting Deterministic Rollbacks for AI Agents

Shiv Shankar — Tue, 04 Aug 2026 13:09:11 +0000

Architecting Deterministic Rollbacks for AI Agents

Debugging long-running AI agents in production is exceptionally difficult when you cannot restore their exact memory state from a specific point in the past.

Standard RAG (Retrieval-Augmented Generation) architectures store flat vectors. When facts change, developers either overwrite the old vector (losing history) or keep both (causing context drift and LLM hallucination).

The structural fix is implementing a bi-temporal schema. Every observation is stored with a valid_from and valid_to timestamp. When a fact is superseded, you update valid_to on the old record.

This guarantees deterministic rollbacks. To debug what the agent knew three days ago (Time T), you query:

WHERE valid_from <= T AND (valid_to IS NULL OR valid_to > T)

We implemented this natively in the open-source Smriti engine to enforce strict state transitions and eliminate context corruption.

Why AI Agents Need Database Triggers, Not Just Prompts

Shiv Shankar — Sun, 02 Aug 2026 12:05:40 +0000

Why AI Agents Need Database Triggers, Not Just Prompts

When a fact changes, prompting the LLM to 'forget' it is unreliable. Instead, use database triggers to automatically close temporal boundaries (valid_to = NOW()) on superseded facts. Let the DB handle state coherence.

The 'Agentic' Trend is Masking a Deep Infrastructure Problem

Shiv Shankar — Sun, 02 Aug 2026 12:05:36 +0000

The 'Agentic' Trend is Masking a Deep Infrastructure Problem

Most frameworks treat agents as black boxes. But if you look closely, the state management layer is usually just a flat RAG implementation. This causes catastrophic context drift in long-term tasks. We need bi-temporal architectures at the storage layer.

LLMs Are Stateless. Here Is What That Actually Means for Agent Memory.

Shiv Shankar — Thu, 30 Jul 2026 13:08:59 +0000

LLMs Are Stateless. Here Is What That Actually Means for Agent Memory.

There is a sentence that most AI agent tutorials skip over, and it explains
why building reliable long-running agents is so hard:

Between API calls, the model knows nothing.

Every "memory feature" you have ever seen — ChatGPT's memory, Claude's Projects,
LangMem, Mem0 — is a human-written system that prepares text and injects it into
the context window before calling the model. The model itself has no persistent state.

The implication people miss

If the LLM is stateless, then the intelligence of a long-running agent lives entirely
in the harness that manages what gets injected and what gets discarded.

This is not a limitation. It is a design principle.

The research community has started treating it explicitly this way:

MemGPT (2023) introduced the "LLM as OS" analogy: the model is a CPU,
external memory is disk, and the harness manages what pages are in RAM at query time.
StateFlow (2024) goes further: the agent is a Finite State Machine.
The LLM is only invoked at state transitions, not held responsible for state itself.
ClawVM (2026) formalises this as a virtual memory layer: the harness enforces
deterministic, validated writebacks at every lifecycle boundary.
The LLM outputs raw thoughts; the harness decides what is committed.

The consequence for memory design

If the LLM is purely a processing unit, then the quality of your agent's memory
is entirely the quality of your harness — the system that decides what facts to
store, how long they are valid, and when they should be superseded.

A harness that stores flat embeddings and retrieves by similarity gives you a
mediocre agent. A harness that stores temporal assertions and resolves conflicts
deterministically gives you a reliable one.

What "temporal assertion" means in practice

A temporal assertion is a fact with a lifespan:

subject:   user_project
predicate: uses_language  
object:    Python
valid_from: 2025-01-10
valid_to:   2025-06-15   ← closed when user switched to TypeScript

The harness stores this, not the LLM. The LLM never sees the old fact again
once valid_to is set. Active state is WHERE valid_to IS NULL.

This is the model behind Smriti — an open-source
temporal memory engine built precisely to be a reliable harness for stateless LLMs.

The LLM is not the agent. The harness is the agent. Build the harness well.

MIT license. PostgreSQL-backed. Open source.

The Hidden Bug in Every AI Agent Memory System: Temporal Drift

Shiv Shankar — Thu, 30 Jul 2026 13:08:28 +0000

The Hidden Bug in Every AI Agent Memory System: Temporal Drift

Most AI agent memory systems have a silent bug. It doesn't show up in demos.
It only surfaces in production, after weeks of running.

The bug is called temporal drift — and it is the reason your agent confidently
tells a user something that stopped being true three weeks ago.

How it happens

You store a fact: "User prefers Python over TypeScript."

Three weeks later the user switches to a TypeScript-first team.
You store a new fact: "User is now working in a TypeScript monorepo."

Both facts live in your vector database. Both have similar embeddings to queries
about the user's tech preferences. Your similarity search retrieves both.

Now your agent has two contradictory beliefs — and no way to know which one is current.

Why vector similarity cannot fix this

Cosine similarity measures semantic closeness, not temporal validity.
A fact from two years ago and a fact from this morning score equally if they
are semantically related to the query. There is no "time" in the embedding space.

You can try to inject timestamps into your prompt and ask the LLM to reason about
which fact is newer. That works in demos. In production, it is slow, non-deterministic,
and fails the moment two facts have similar timestamps.

The structural fix: temporal assertions

Instead of storing facts as permanent records, treat each fact as a temporal interval:

valid_from: when this fact became true
valid_to: when this fact stopped being true (NULL = still active)

When a new fact supersedes an old one, you write a valid_to timestamp on the old record
and insert the new one. You never delete. You never update in place.

Active memory is then trivially:

SELECT * FROM memory_events
WHERE agent_id = $1
  AND subject = $2
  AND valid_to IS NULL;

Historical state at any past moment T is:

SELECT * FROM memory_events
WHERE agent_id = $1
  AND valid_from <= T
  AND (valid_to IS NULL OR valid_to > T);

No LLM calls. No reasoning under uncertainty. Pure index arithmetic.

This is what we built with Smriti

Smriti is an open-source bi-temporal memory engine
that does exactly this. It extracts Subject-Verb-Object facts from agent interactions,
assigns them validity windows, and handles supersession automatically.

The result: your agent's memory is always temporally coherent.
No stale facts. No conflicting beliefs. No hallucinations from outdated context.

If you are building an agent that runs for more than a single session,
this is the architectural layer you are probably missing.

Open source. MIT license. Built on PostgreSQL.

Why Vector Databases Fail at Agent Memory (And How We Fixed It)

Shiv Shankar — Wed, 29 Jul 2026 16:32:33 +0000

Why Vector Databases Fail at Agent Memory (And How We Fixed It)

If you are building an AI agent that runs over long periods (days or weeks), you've likely hit the "Context Window Wall." The standard solution is to take all your chat history, embed it, and shove it into a Vector Database.

But here is the fatal flaw with flat vector retrieval: It doesn't understand time.

If a user says "I live in New York" on Monday, and "I just moved to London" on Friday, a vector database returns both facts. Your agent gets confused and hallucinated.

The Bi-Temporal Fix

In traditional systems engineering, we fix this with a dual-calendar model. Instead of storing flat documents, you extract the state into Subject-Verb-Object (SVO) events and tag them with valid_from and valid_to. When a contradictory fact arrives, you simply close the valid_to bound of the old fact.

To fetch active memory, your agent just queries: WHERE valid_to IS NULL.

Introducing Smriti

We got tired of writing this complex supersession logic, so we built Smriti. It's a completely open-source, Postgres-backed temporal memory engine for AI agents. It handles the SVO extraction and invalidation asynchronously, so your agent's reasoning loop is never blocked.

Check out the repo and let us know what you think!

Why Flat Vector Retrieval Fails on Long-Term Agent Memory (And How Bi-Temporal SVO Modeling Fixes It)

Shiv Shankar — Tue, 28 Jul 2026 10:13:32 +0000

When building autonomous AI agents, developers often start with a flat vector database (like ChromaDB or Pinecone) to store conversation history. However, as agent sessions scale, flat vector search faces a fundamental limitation: it cannot encode time.

The Core Problem: Flat Vectors Don't Know "When"

If a user says "I live in New York" on Monday, and then "I moved to San Francisco" on Friday, a standard vector search for "Where does the user live?" will retrieve both statements with high cosine similarity. The agent receives conflicting facts and hallucinates.

The Solution: Bi-Temporal Dual-Calendar Memory (Smriti)

To solve this, Smriti uses a bi-temporal architecture in PostgreSQL:

SVO Event Extraction: Turns are parsed into Subject-Verb-Object (SVO) assertions with explicit valid_from and valid_to timestamps.
Zero-LLM Fact Supersession: When a new fact arrives, an in-process statistical engine invalidates the prior valid_to timestamp without needing slow, expensive LLM reflection passes.
Point-in-Time Queries: Queries evaluate valid_to IS NULL for active truths, keeping the context window 100% clean.

Check out the live API and benchmarks at smriti-kaal.vercel.app.