Questions, answered.

abagraph is the database for AI agents — a bitemporal graph and vector memory engine. Agents write what they learn as subject–predicate–object facts, each carrying a source, a confidence score, and two timelines (when it was true, and when you learned it).

They recall it by pattern match, graph walk, semantic search, or time-travel, then pull a compact build_context packet for the next turn. It is the memory system-of-record for the AI era — the warehouse and lakehouse successor, built for agents rather than analysts. Facts, not blobs.

A vector database stores embeddings and returns nearest neighbours by similarity. That is exactly one of four access paths abagraph fuses into a single answer. abagraph also matches exact entities and patterns (symbolic), walks the relationships between facts (graph), and answers as of any point in time (temporal).

And every fact carries provenance — source and confidence — plus bitemporal validity. So the engine can collapse stale data, surface contradictions, and abstain when it is not sure. A flat vector index can do none of that: no time, no source, no graph, no governance.

Those are memory libraries that sit in front of a model and mostly store and retrieve text. abagraph is a database. The unit is not a remembered blob — it is a typed fact with a subject, predicate, object, source, confidence, and two timelines.

That makes memory queryable, auditable, and time-travelable: you can ask what the agent believed at time T, see why it believed it, and watch a new fact atomically supersede the old one. It is an engine with strict bitemporal semantics and multi-tenant isolation, exposed natively over MCP — not a wrapper around a vector store.

Facts. The atomic unit is a subject–predicate–object triple with valid_from, valid_until, recorded_at, confidence, and source. You can attach larger blobs when you need them, but the thing the engine reasons over is the typed fact graph — and that is what makes recall, time-travel, and supersede possible in the first place.

Every fact tracks two independent timelines: valid time (when the fact was true in the world) and transaction time (when abagraph recorded it). That lets you ask two genuinely different questions — “what is true now,” and “what did I believe last Tuesday.”

as_of(timestamp) returns the entire world-state as the engine knew it at any moment, so you get real audit and time-travel instead of a destructive overwrite. For an agent, that is the difference between memory you can trust and a mutable blob you cannot.

When you assert a fact that contradicts an existing one, abagraph closes the old fact (marks it Superseded) and opens the new one in a single atomic batch. The prior value is not deleted — it is retired with an end time, so the history stays intact and queryable.

Most predicates are functional (one active value per subject). Set-valued predicates like references or tag coexist instead, on a per-assert basis. And low-confidence assertions land as Candidate — they do not supersede anything until they are reasserted at full confidence.

build_context is a single call that assembles a compact, ready-to-inject context packet for an agent’s next turn. You give it seed entities and a token budget; the engine recalls across every access path, ranks facts by confidence and relevance, collapses superseded duplicates to the single current truth, and trims the set to fit your budget exactly.

Every fact in the packet keeps its source, so the agent can verify rather than guess. It is context compaction as one deterministic operation — instead of stuffing the prompt and hoping the model finds the signal.

Memory lives in-process behind covering indexes, so there is no network round trip inside the agent loop. A single bitemporal index lookup returns in the hundreds-of-nanoseconds range, and fused semantic-plus-graph recall completes in well under a millisecond. Fast enough to run every turn, without a hop.

Yes. Each tenant’s data is isolated by namespace, and reads filter on that namespace through a single chokepoint — even admin reads are scoped, and conflict resolution is tenant-local. Nothing leaks across tenants by default.

Access is gated by scoped bearer tokens, the MCP surface is auth-gated identically to the REST API, and the engine is single-writer for consistent, ordered writes. The MCP tools return bounded, provenance-rich projections — never raw embeddings.

Yes — MCP is a first-class surface. abagraph exposes the engine as the orchestrate MCP server: seven outcome-oriented tools — digest, remember, recall, recall_as_of, whats_changed, build_context, and explain_fact — each namespace-scoped to a tenant.

It speaks JSON-RPC 2.0 over stdio for local agents, and the same dispatcher is served over HTTP at POST /mcp, auth-gated identically to the REST API. Any MCP-capable model can use abagraph as its long-term memory with no custom glue.

abagraph is in early access. There are no public pricing tiers yet — tell us what you are building and we will get you set up. Join via the early-access page and we will be in touch.