ZizkaDB Founder Publishes AI Agent Memory Audit Guide

ZizkaDB founder Mir Arshad Talpur has published an implementation guide for giving AI agents memory that engineers can inspect and audit. Its central recommendation is practical: store memories as linked events, then separately record which memories were retrieved for each model call.

The guide, How to Give Your AI Agent Memory You Can Audit, was published around October 27, 2026. That date is approximate because it was inferred from the page’s relative timestamp. It covers token budgets, freshness, supersession, conflicting memories, tenant isolation, deletion, time-travel inspection, and regression tests.

Talpur is promoting a product he founded, and the guide’s code comes with an important qualification: some SDK return fields, ranking behavior, and limits are not publicly documented, so the examples are illustrative. Builders should check them against the current SDK documentation before using them in production.

The useful engineering contribution is the separation between having memory and being able to reconstruct how memory entered an answer. A searchable history can supply context. An auditable system also needs records of selection, filtering, prompt assembly, and subsequent changes to that history.

ZizkaDB’s technical reference, dated October 25, 2026, provides the product-level detail behind that approach. It describes event storage, causal links, semantic search, point-in-time reconstruction, and metadata-filtered deletion. Those are documented vendor capabilities, not independently measured results.

Store Memories and Retrieval Decisions Separately

ZizkaDB represents agent activity as events. Its documented event fields include an agent identifier, event type, JSON payload, optional causal parent, optional session identifier, metadata, and a timestamp. A parent_id connects an event to an earlier event, while session_id groups activity within a run or conversation.

That gives a memory record somewhere to live in an operational history. An agent could record the source message that introduced a preference, the event that converted it into durable memory, and the later action associated with it. ZizkaDB’s documented why operation follows an event’s ancestor chain back toward its root. The technical reference describes these fields and APIs.

Retrieval needs its own record because the memory store changes over time. Running the same search tomorrow may return different results after new events arrive, old records expire, or personal data is erased. A later search cannot reliably reconstruct what the agent received yesterday.

For an application implementing this pattern, I would distinguish three stages:

• Retrieved candidates: the records returned by a search or context-selection operation.
• Selected memories: the records that survived freshness, permissions, conflict, and budget checks.
• Submitted context: the actual text or structured representation included in the model request.

Those stages are an implementation recommendation derived from the guide’s audit pattern, not a claim that ZizkaDB automatically records all three.

The distinction matters when context is shortened. A retrieval log containing five event IDs says little about an answer if the application included only two of those events, summarized another, and discarded the rest. Recording selection and transformation decisions makes the trace much more useful.

Even a complete trace has an interpretive boundary. It can establish which memories were available to the model and how the application supplied them. It cannot reveal exactly how much each memory contributed to the model’s internal computation. “Memory influenced this answer” should therefore be grounded in the recorded request path, with any stronger causal interpretation explained separately.

Freshness Is a Policy, Not a Similarity Score

The guide addresses freshness, supersession, and conflicts because semantic relevance alone leaves important questions unanswered. An old shipping address may be highly similar to a delivery question while still being the wrong address to use.

ZizkaDB’s documented event model provides timestamps and arbitrary JSON payloads and metadata. Those fields give an application space to record validity and provenance. The reference does not specify a complete, automatic policy for resolving every stale or contradictory memory. That policy remains an integration responsibility. The documented data model is described here.

A practical design should distinguish at least two kinds of time:

• Recorded time: when the system logged the information.
• Validity time: when the information applies, or when it should be reviewed or expire.

A newly ingested document can contain an old policy. Conversely, an older event may still describe a valid preference. Sorting by ingestion time cannot resolve both cases.

Supersession also benefits from an explicit relationship. When a customer updates a delivery address, the application can record which earlier memory the new one replaces. That preserves the historical explanation while allowing retrieval to exclude the obsolete value from current decisions.

Conflicts need a defined outcome as well. Depending on the task, an agent might prefer an authoritative source, use a confirmed update, ask the user, or stop a consequential action. Leaving that decision to whichever passage happens to rank highest creates an unstable policy.

My view is that freshness rules should be written as decision rules before they become prompt instructions. A rule such as “exclude superseded addresses from delivery actions” is testable. A prompt asking the model to “use the latest relevant information” leaves more room for interpretation.

Token Budgets Can Change the Meaning of Memory

ZizkaDB documents a context_for(agent, task, max_tokens=...) interface that combines recent and semantically relevant events into context suitable for system prompts. The exposed token-budget parameter is useful, but a budget is only one part of context assembly. The interface appears in the technical reference.

An application still has to allocate room for its system instructions, the current request, tool definitions, other retrieved material, and the model’s response. Memory should receive a deliberate share of that capacity.

The audit consequence is easy to miss: truncation is a decision about evidence. If a budget removes the event that superseded an older instruction, the remaining context can become misleading even though every retained sentence is accurate.

Builders should therefore log which memories were excluded for budget reasons and preserve important relationships during selection. An address and its replacement should be evaluated together. A claim and the event withdrawing it should not be separated casually.

The guide’s warning about illustrative code is especially relevant here. Its examples should not be treated as a guarantee of exact ranking behavior, token counting, or returned fields. An integration should verify those details for the SDK version it uses and make its own selection policy observable.

Tenant Isolation Has Two Different Boundaries

ZizkaDB’s technical reference states that API keys scope reads and writes to a tenant. It also lists metadata fields such as user_id and environment tags. These serve different purposes: the API key establishes the documented tenant boundary, while metadata identifies records within that scope. See the documented tenancy model.

That difference matters for an AI product serving multiple customers or users.

A tenant-specific key may separate one organization from another. Inside an organization, the application may still need to separate individual users, workspaces, projects, or permission groups. The presence of a user_id tag alone does not describe how authorization is enforced across those groups.

The practical question is whether every relevant access path applies the intended scope. Search, context assembly, event inspection, exports, deletion, and historical reconstruction all deserve attention. A correctly filtered search is insufficient if another application route can expose the same records without the same check.

I would make isolation tests a release gate for an agent with persistent personal memory. The reason is concrete: a retrieval mistake can place another person’s information directly into a model request, before the model has any opportunity to handle it safely.

Tests should include both separate API-key tenants and separate users inside one application tenant. Those exercise different boundaries and can expose different integration mistakes.

Deletion Must Cover the Copies Created by Auditing

ZizkaDB documents forget(filter_key, filter_value) as deleting matching events and their vectors. Its integrity section says deletion leaves a content-free tombstone so the event chain can continue to verify. That is the vendor’s stated deletion behavior. The deletion and retention semantics are documented here.

The wider engineering issue is that an agent application may create several copies of a memory:

• The original event.
• An embedding-backed search entry.
• A retrieved-context record.
• A prompt or response trace.
• A cached summary or derived preference.
• An export used for debugging or evaluation.

Some of those copies may sit outside ZizkaDB. Deleting the source event therefore cannot, by itself, demonstrate that the application has erased every retained copy.

This is where observability and privacy can pull in different directions. Recording full prompt contents makes an audit easier, but it can also duplicate the personal information the application later needs to remove.

A useful design separates the audit record from unnecessary content. Event identifiers, policy versions, selection reasons, and deletion markers may preserve part of the explanation without retaining a complete copy of the memory. Any remaining personal content still needs a defined retention and erasure path.

Deletion tests should also revisit summaries and historical views. If a derived memory repeats a deleted address, deleting the original address record has not achieved the intended application-level result. The pass condition should follow the data, not merely the success response from a deletion call.

Time Travel Reconstructs Records, Not Model Behavior