Built
Write on any master
Every master takes writes and tells the others. There is no single leader to wait for or fail over to.
Today the masters share one process on a simulated network. Real machines come with milestone M1.
The database built by agents, for agents
Documents, graph, vector search with rerank, memory and events in one open-source engine. Write on any master, retry safely, remember and forget, and run it on any cloud, on-prem or your laptop.
Write anywhereCopies you chooseDown to Iceberg
Built to run on
- 9console pages, one trail map
- 365Rust tests passing
- 4cloud kits written: AWS, Google Cloud, Azure, Oracle
- 0acknowledged writes lost in the burst test
From the project's own runs, 23 October 2026. Early numbers from a small test machine, not a benchmark. The full story is under Roadmap.
What's different
Not a database with agents bolted on
Most agent stacks glue half a dozen systems together and hope the glue holds. AgentreksDB starts from the agent: how it retries, what it remembers, how its loops run and who it trusts. Here is what that changes, and what it doesn't.
How to read the tagsBuiltworks in the code todayWrittentooling exists, not yet run for realDesignedon paper and modelledPlannedan idea, not started
Six systems and a lot of glue
Six sets of keys, backups and sync jobs. Every arrow is a place for data to go stale.
One camp, one set of keys
Documents, vectors, graph, memory, events and text in one engine. One set of keys, one backup, one place for an agent to look.
Built
Merge by field
Two agents edit different fields of one document and both edits survive. Merge rules are set per collection.
Built
Retry without fear
Writes carry an idempotency key, so a retry stores once. Replies are receipts: how many copies, how many needed, what is waiting.
Built
Memory with a gate
Remember, recall, forget, consolidate. Memories from sources you don't trust wait in quarantine until a reviewer releases them.
Built
Events without a broker
Agents talk through the graph: an inbox with ack and nack, timers, a causal trace and a loop governor that stops runaway loops.
Built
Ask as of any day
Graph links have validity windows and memory recall can time-travel, so an agent can ask what was true then.
Built
Narrow tokens, checkable log
An agent can hand a narrower token to a sub-agent. Every admin action lands in a hash-chained audit log you can verify.
Designed
Strong where it matters
Eventual by default. Pick linearizable per collection for unique names or locks. On the cut-off side of a split, strong collections refuse.
Side by side, job by job
| The job | The usual answer | In AgentreksDB |
|---|---|---|
| Take writes anywhere | One primary takes writes, the rest follow | Every master takes writes; documents merge field by field Built |
| Find by meaning | A separate vector database, plus a rerank call | Keyword, vector and hybrid search with rerank in the same store Built |
| Link facts | A graph database on the side | Edges with properties and validity windows, as-of queries, shortest path, PageRank Built |
| Remember | A memory library over several stores | Remember, recall, forget, consolidate and quarantine, replicated like any data Built |
| React to change | A broker plus glue code | Events in the graph: inbox, timers, causal trace, loop governor Built |
| Search text | A search cluster | Keyword search built in, blendable with vectors Built |
| Analyse history | A nightly export job into a lake | Move settled data to Iceberg on S3 from inside the database Optional build |
| Retry safely | Every client improvises its own retries | Idempotency keys, write receipts, Retry-After on every refusal Built |
| Trust an agent | Checks scattered through app code | Narrow tokens, quotas, source trust, quarantine, hash-chained audit Built |
What isn't new
Multi-master writes, hinted handoff, vector search, graphs and Iceberg all have precedent. We won't call this the first or the fastest. The difference is the combination: one engine whose interface, memory and events are made for agents, with the trade-offs written down. Speed claims wait for a benchmark anyone can rerun.
Capabilities
Everything an agent keeps, in one engine
Documents, links, meaning, memory, events and history live in one open-source engine written in Rust, so you don't run six systems and keep them in sync. Each card says how real it is today.
JSON documents
Store anything an agent produces as JSON in a compact binary format, with a write-ahead log and crash recovery.
Copies and placement
At least two copies, up to one per master. Pin data to the masters you name. Hinted handoff and repair catch up masters that were away.
Graph with history
Edges with properties and validity windows. Explore as of a date, find shortest paths, run PageRank.
Search that blends
Keyword, vector or hybrid, then rerank, with metadata filters and an explanation of each score.
Agent memory
Remember, recall with time travel, forget and consolidate. Review quarantined memories, then release them.
Events and inbox
Publish and subscribe, an inbox with ack, nack and approve, timers, a causal trace and a loop governor.
Safe for retries
Idempotency keys on writes, receipts that show copies stored and needed, and Retry-After on every refusal.
Trust built in
Tokens an agent can narrow for sub-agents, per-agent quotas, source trust and a hash-chained audit log.
A console with a map
Nine pages and three themes, every API reachable from the screen, served by the database binary itself.
Run-anywhere kit
Dockerfile, Helm chart, OpenTofu modules for four clouds and CI/CD. Machines of any size are weighted by what they can carry.
Iceberg + S3
Move settled data to Apache Iceberg tables on S3 for analytics and archive, in an open table format.
Swap any part
Open source by design. The plan is a plugin API so the vector index, graph engine or merge rules can be your own.
The console
Nine camps on one trail map
The database serves its own console, and every page is a camp on the trek. Click a camp and the trek robot walks you there. The same screens work for people and for agents with a narrow token.
Overview
Try it · replication Built
Write at any camp. Keep copies where you choose.
Every master takes writes and talks to the others. Keep at least two copies, add more up to one per master, or pin data to the masters you name. Click a camp to write a document there, then take camps offline to see what survives.
Copies
Two is the minimum. The most you can set is one copy per master.
Masters
Pin two or more masters to choose exactly where data lives. With none pinned, AgentreksDB picks the nearest ones.
Click any camp to write a document there.
This page simulates the idea in your browser. The real engine applies the same rules today with every master in one process; separate machines come with milestone M1 (see Roadmap).
Query models
Documents first. Everything else is built on top.
The same JSON documents power graph links, search, memory and events. There is one copy of the data, and it is replicated like everything else. The snippets are sketches of the idea; the real API is JSON over HTTP.
// Two masters edit the same document at once
await usEast.put("task:42", { status: "done" });
await mumbai.put("task:42", { owner: "agent-7" });
// Both edits survive. Documents merge field by field.
const task = await db.get("task:42");
Two masters, one document, one result
us-east
task:42 sets status to "done"mumbai
task:42 sets owner to "agent-7"Merged field by field on every master
{
"title": "Draft release notes",
"status": "done",
"owner": "agent-7"
}
// Field names come from the API. The path and body are a sketch.
POST /v1/…
Authorization: Bearer <agent token>
Idempotency-Key: 7f3a-21c9
{ "consistency": "quorum", … }
// reply
{ "acks": 2, "need": 2,
"hinted": 1, "replicas": […] }
Three tries, one document
- 429Busy. Retry-After-Ms says when to come back.
- 200Stored. Two of two copies acknowledged.
- 200Same key, same receipt. The reply was lost, so the agent asked again. Nothing is stored twice.
consistency per writeanyonequorumall
// Which sources did agent 7 rely on?
const sources = await db
.graph("work")
.from("agent:7")
.out("worked_on") // tasks
.out("cites") // sources
.limit(10);
Walking links from an agent to its sources · edges carry properties and validity windows
// Find by meaning, then rerank the best matches
const hits = await db.search("help_docs", {
text: "refund policy for annual plans",
topK: 50,
rerank: { keep: 5 },
});
Query: "refund policy for annual plans"
Step 1 · Vector search
await agent.memory.remember("Customer prefers email over calls");
const notes = await agent.memory.recall(
"how should I contact them?"
);
await agent.memory.forget(notes[0].id);
Memory is just documents with a purpose
recall"how should I contact them?"
Customer prefers email over callsbest match
Renewal date is March 3
Asked about single sign-on last week
Replicated on your mastersFound by meaningLinked in the graph
// Time series
// planned: nothing behind this in the API yet
await db.series("tool_calls").append({
agent: "agent-7",
ms: 412,
});
// Full-text
const logs = await db.text("run_logs").match("timeout");
Tool calls per minute · example data · Time series: planned Full-text: built
run 18 · tool call hit a timeout after 30s
run 22 · retry after timeout on search
Run anywhere
Any cloud. Any size of machine. Even your laptop.
Masters can live in one region, many regions, several clouds, or on-prem and cloud together. The deploy kit checks your machines, plans the cluster and writes the files for each platform. Click a logo to see what is in the kit and how far along it is.
Written
Amazon Web Services
Machines of any shape share the load fairly
Each master carries a share of the data in proportion to its weight. A node's weight is the smallest of cores ÷ 4, memory ÷ 16 GiB, storage ÷ 256 GiB and durable writes per second ÷ 1,000, held between 0.125 and 16. A laptop and a big server can sit in the same cluster. Built Takes effect with M1
Example machines with made-up specs, to show the formula. Shares are proportional to weight.
Resilience
Built for a bad day, and honest about it
Agents burst, loop and retry. AgentreksDB expects that. It answers "come back in a moment" instead of falling over, keeps every write it acknowledged, grows in place, and catches up a master that was away.
- 38,449operations in the run
- 0failed, for callers that retried
- 27,040acknowledged writes, every one read back at quorum
- 8,975polite "retry shortly" answers with Retry-After
The price
p50 337 ms, p99 2.0 s, p99.9 5.0 s while overloaded. Nothing was lost and nothing failed, but callers waited. Overload costs latency, never data.
Release binary on 2 cores: 100 requests a second, then 10×, then 30×, with the CPU limit changed mid-run. "No errors" means no lost acknowledged write, no crash and no failed operation for a caller that retries. It is a stress test, not a benchmark.
Built
Away masters catch up
Writes meant for an offline master wait as hints and replay when it returns. Read repair and digest repair mop up the rest.
Built
Drain, don't drop
On shutdown the server stops taking new work, finishes what is in flight and reports not-ready so traffic moves away. Health, ready and metrics ports are built in.
Written
Grows in place
The controller resizes CPU and memory without a restart, grows volumes at 70% full and waits ten minutes before shrinking. Not yet run on a real cluster.
Designed
Slow beats stopped
If a nearby voter fails, strong writes will carry on at the far master's slower speed instead of stopping, and say so. Times are modelled, not measured.
Storage Optional build
Data moves downhill into Iceberg on S3
Fresh data lives on your masters, where agents read and write it. When it settles, move it to Apache Iceberg tables on S3 for analytics and archive. The lakehouse export is an optional build of the engine, with its own page in the console.
- 1Agents write to any master. New data is the warmest data.
- 2Older data moves to Iceberg on S3. You decide what moves and when.
- 3Iceberg is an open table format, so other tools can read it without a copy job.
Apache Iceberg
Data temperatureJust writtenRecentSettledArchived
Events Built
Agents talk through the database, not a broker
Agent systems have been climbing for a while. AgentreksDB is built for the last step: long-running, asynchronous agents in loops that keep improving, working on a graph and talking to each other through it.
- Prompt
- Context
- Agents
- Harness
- Loop
- Graph
- Event-driven graph
The change is the message
- 1Long-running. Agents keep working for hours or days, not one request at a time.
- 2Asynchronous. An agent watches the graph, picks up a change when it is ready and writes its result back.
- 3Continuously improving. Results feed the next pass of the loop, so every round starts from better data.
- 4No broker. Agents talk through AgentreksDB instead of a separate message queue.
Not needed
for agents
for agents
Keep Kafka for the rest of your company
Agents don't need a broker to hear each other. A change in the graph is the message, and an agent's inbox is a page of the database. A bridge to Kafka for your other systems is an idea, not something built. Bridge: planned
What the events layer has todaypublish + subscribeinboxack · nack · approvelayerstimerscausal traceloop governorevent log
Open source Plugin API planned
Change the algorithm, not just the settings
Don't like the vector index? Replace it. The index, the graph engine, the rerank step and the rest can be swapped for your own code. Nothing is sealed.
Vector index
Graph engine
Rerank step
Merge rules
Storage tables
Memory policy
// Bring your own vector index
struct MyIndex { /* your algorithm */ }
impl VectorIndex for MyIndex {
fn insert(&mut self, id: DocId, vector: &[f32]) { /* ... */ }
fn search(&self, query: &[f32], k: usize) -> Vec<Hit> { /* ... */ }
}
let db = Agentreks::open("./data")
.vector_index(MyIndex::new())
.build();
Roadmap
The climb: where we are, and what's in the fog
The engine, the API, the agent features and the console exist. The next camp is the one that matters most: real masters on separate machines. Beyond it, everything is labelled for what it is.
Builtlit campDesignedon paper and modelledPlannedin the fog
0
Built
Base camp: where we are
- Rust engine: binary JSON, clock, field-level merge, write-ahead log with crash recovery
- Multi-master with copies, pins, merge rules, hinted handoff and repair, in one process on a simulated network
- HTTP API with tokens, idempotency keys, receipts and consistency levels
- Search, graph, memory and events
- Console with nine pages and three themes
- Deploy kit for Docker, Kubernetes, four clouds and CI/CD (written)
- 365 Rust tests and 54 console tests pass; the burst test passed
1
Next Designed
M1: real masters
- Masters as separate processes talking over TCP with mutual TLS
- Three connection classes per pair, so repair never starves writes or heartbeats
- Gossip-style membership and failure detection
- Concurrent replication with deadlines
- The test: kill one master during a write burst with no client errors; hints replay and repair converges
- Unlocks real cloud, on-prem and laptop clusters, and weights that take effect
2
Planned
Prove it
- First real runs of the Helm chart, OpenTofu modules and laptop script
- Packet-loss and wide-area tests
- A benchmark harness anyone can rerun, against Cassandra and ScyllaDB on identical hardware, with raw results published
- Speed work: group commit, finer locks, partial decoding, caching, batching
3
Designed
Strong when you need it
- Linearizable collections next to eventual ones
- Choose which masters vote, with a far tie-breaker and followers that check themselves
- A planner that shows latency and failure tolerance before you commit
- Slow beats stopped: strong writes carry on during a failure
4
Designed
Rough weather
- Survivors grow in place while a master is down
- Never restart a voter while degraded; no shrinking until the returned master has caught up
- Waiting on a far master is not counted as load
5
Planned
Summit: everything agents keep
- Time series wired into the API
- A plugin API to swap the vector index, graph engine and merge rules
- Wider benchmarks, and the claims they earn
Said plainly
- All masters share one process today. Separate machines cannot form a cluster until M1.
- Client traffic is plain HTTP unless a proxy ends TLS. Mutual TLS between masters arrives with M1.
- Speed is early: about 54,000 writes a second with operating-system durability, about 4,000 with a flush on every commit, and about 83,000 point reads a second, on a 2-core test box with one thread. The project's own notes call that "not competitive yet".
- The deploy kit has not yet run against a real cloud account or cluster.
- Time series is not wired to the API yet.
- AgentreksDB has not been compared with another database yet. "Fastest" waits for the harness above.