Founding question

If time is not a line, but a space that can branch, evolve, and overlay — how should we remember it?

TimeSpaceDB is one answer: a database that remembers time as state-space.

Branching and time-travel
for AI agent memory.

A small database that treats forking and history replay as first-class storage operations. Built for AI agents that need to branch a decision, replay any past state, or audit what they actually saw — without rebuilding those primitives at the application layer.

Get in touch
Early access · Working with select design partners

The problem

Most agent memory tools today treat branching, replay, and audit as application-level concerns — bolt them on top of a regular database with checkpoints, copies, and a hand-rolled event log.

That works until your agent needs to fork a thousand times to explore reasoning paths, or your auditor asks to see the exact memory state at a specific point in time three months ago, or you want to diff two branches of an agent's memory the way you'd diff two git branches.

At that point, the application layer starts to creak. State blows up. Replay becomes approximate. History gets lossy.

TimeSpaceDB pushes those primitives down into the storage layer, where they belong.

What it does

Four design choices, all visible at the API level. Implementation is intentionally kept private while the system stabilizes.

Branch

Forking is a pointer, not a copy

Creating a branch off any past state costs the same whether the state is a kilobyte or a hundred gigabytes. Agents can fork freely to explore counterfactuals or A/B reasoning paths.

Time-travel

Query any past state with the same speed as the present

Replay an agent's memory at any historical point. Audit decisions, debug failures, reconstruct what the model actually saw. No retention cliff, no archived-versus-live asymmetry.

Append-only

Nothing is ever overwritten

The storage substrate is append-only by design. Audit trail and reconstructability come for free — not as an opt-in feature layered on top.

Runtime

Built in C, accessed via API

Runs as a long-lived service. Clients integrate through a language-agnostic API — no library to embed, no garbage collector to tune, no runtime to install. Small binary, predictable resource footprint.

Built for

Workloads where branching, replay, and audit are not afterthoughts.

AI agent developers

Forking agent state to explore alternative reasoning paths. Replaying agent memory to debug a failure. Diffing two branches of agent memory to understand what changed.

ML lineage & governance

Reproducing the exact model context at any prior point. Building auditable chains of decisions for regulatory review. Tracking how prompts, embeddings, and tool outputs evolved over time.

Regulated workloads

Hash-chained, append-only audit logs for compliance regimes that require reconstructable system behavior — without retrofitting immutability onto an application-level log.

Builders who care about systems

People who'd rather have a small, sharp primitive than a sprawling framework. Who think in terms of invariants, not abstractions. Who want clear semantics and a predictable data model before they trust an API.

Design philosophy

TimeSpaceDB is a small project, deliberately. The goal isn't to replace your data platform — it's to be a sharp tool that does one set of operations well.

The bet is that agent memory, ML lineage, and audit-shaped workloads share a common substrate: append-only storage with cheap branching and queryable history. Once you have that substrate, a lot of application-level complexity falls away.

The implementation lives in C because the workload is latency-sensitive and the primitives are simple enough that the language doesn't get in the way.

Evidence & benchmarks

A detailed performance report is available. It covers retrieval quality measured head-to-head against Qdrant on the BEIR benchmark, answer faithfulness scored by two independent judges from different model families (Anthropic Claude Opus 4.7 and Google Gemini 3.5 Flash) in a 2×2 generator-by-judge cross-vendor matrix, audit-chain latency at production scale, and a paper-tied reproducibility demonstration.

The report is intentionally written to disclose what the numbers do and do not show, the measurement setup, and the known limitations — so you can decide for yourself whether the system fits your workload.

Read the full report →

Status

Current phase

Working with design partners

TimeSpaceDB is not yet open for general use. The core is stable; agent-specific APIs are being shaped with a small number of design partners running real workloads.

If you're building something where branching, replay, or audit is a first-order concern — and you'd be willing to feed back what works and what doesn't — get in touch.

→ support@lanlanking.com

About

TimeSpaceDB is an independent engineering project. It started from frustration with how most systems treat history — as an afterthought, a log file, something you compact and forget.

The deeper conviction is that storage layers that keep history cheaply and let you branch off it freely unlock a different class of applications. Agent memory is the first one. Others will follow.