# AI use cases for ZizkaDB (ZIZKA-AI-SL/ZizkaDB)

Repo: [ZIZKA-AI-SL/ZizkaDB](https://github.com/ZIZKA-AI-SL/ZizkaDB) | Use cases: 3 | Page: https://dedupedai.com/use-cases/zizka-ai-sl-zizkadb/

ZizkaDB is an audit trail database for AI agents with tamper-evident, checksum-backed decision logs, session replay, time-travel debugging, drift detection, an MCP server and Python and TypeScript SDKs, aimed at EU AI Act Article 12 record-keeping.

This file holds every use case of this repo. Each one starts with a "## " heading and ends with its URL.

- Self-host a tamper-evident audit log for your agents: https://dedupedai.com/use-cases/zizka-ai-sl-zizkadb/self-host-agent-audit-trail/
- Trace why your agent made a bad tool call: https://dedupedai.com/use-cases/zizka-ai-sl-zizkadb/replay-agent-session-to-debug/
- Catch drift in agent behaviour and ask about it over MCP: https://dedupedai.com/use-cases/zizka-ai-sl-zizkadb/detect-drift-in-agent-behavior/

## How to self-host a tamper-evident audit log for your agents with ZizkaDB

Repo: [ZIZKA-AI-SL/ZizkaDB](https://github.com/ZIZKA-AI-SL/ZizkaDB) | Difficulty: Intermediate | Time: 45 minutes | Basis: From the README

Run ZizkaDB in Docker and log your agent's events through the Python or TypeScript SDK into a hash-chained record you can verify and query.

**Who it is for:** A team running AI agents in production, especially in regulated settings, that needs a durable record of what each agent did and why.

**The problem:** Ordinary logs can be edited or lost, and they do not link a tool call back to the message and model response that caused it.

**The outcome:** A local ZizkaDB with a dashboard on port 3001 and API on 8000, where every event is checksummed and chained, so you can prove nothing was edited or removed.

### Steps

1. Run locally: `docker run -d --name zizkadb -e ENV=development -p 127.0.0.1:8000:8000 -p 127.0.0.1:3001:3001 -v zizkadb_data:/data ghcr.io/zizka-ai-sl/zizkadb`
2. Open the dashboard at localhost:3001; development mode signs you in with one click
3. Install the SDK: `pip install zizkadb-sdk`
4. Log events from your agent with db.log, passing parent_id so events link into a chain
5. For a server, copy .env.example and run `bash scripts/init-secrets.sh`, then set ENV=production, a new DEV_API_KEY and SELFHOST_ADMIN_TOKEN
6. Check integrity with db.verify_chain for an agent

### Prompt to paste into your agent

```text
Add ZizkaDB logging to my agent in <file>: log user_message, llm_response and tool_call events with parent_id links using zizkadb-sdk against http://localhost:8000. Then show me how to verify the chain for this agent.
```

### Caveat

In production the API refuses to start if DEV_API_KEY is left at its default.

Risk, credentials: The admin token and API keys control the whole audit store; keep them out of commits.

Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/

URL: https://dedupedai.com/use-cases/zizka-ai-sl-zizkadb/self-host-agent-audit-trail/

## How to trace why your agent made a bad tool call with ZizkaDB

Repo: [ZIZKA-AI-SL/ZizkaDB](https://github.com/ZIZKA-AI-SL/ZizkaDB) | Difficulty: Intermediate | Time: 30 minutes | Basis: From the README

Use ZizkaDB's causal chain, session replay and time travel to walk back from a wrong tool call to the message or context that caused it.

**Who it is for:** An engineer debugging an agent that did something odd in production, such as calling the wrong tool or using stale information.

**The problem:** Flat traces show what happened but not why, and you cannot see what the agent knew at the moment it decided.

**The outcome:** The causal chain behind any event, a step by step replay of the session, and a rebuild of the agent's knowledge at any past timestamp.

### Steps

1. Start ZizkaDB with the quickstart or the docker run command and log your agent through the SDK
2. Find the suspicious event in the dashboard and open the Why? (causal) tab
3. From the terminal, run zizkadb why with that event's id
4. In code, call db.why(event_id) to print the chain back to the user message
5. Call db.at(agent, timestamp) to see exactly what the agent knew at that moment
6. Replay the whole session event by event to find where it went wrong

### Prompt to paste into your agent

```text
Using ZizkaDB, explain why <agent> called <tool> in session <id>: print the db.why chain for that event, rebuild what the agent knew with db.at at that time, and point to the step where the context was wrong.
```

### Caveat

Replay and causal chains cover only what your integration logged.

Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/

URL: https://dedupedai.com/use-cases/zizka-ai-sl-zizkadb/replay-agent-session-to-debug/

## How to catch drift in agent behaviour and ask about it over MCP with ZizkaDB

Repo: [ZIZKA-AI-SL/ZizkaDB](https://github.com/ZIZKA-AI-SL/ZizkaDB) | Difficulty: Intermediate | Time: 30 minutes | Basis: From the README

Use ZizkaDB's baseline to flag when an agent starts behaving differently from its history, and query the record from Cursor or Claude through its MCP server.

**Who it is for:** A team that changes models or prompts and needs to know when an agent quietly starts acting differently.

**The problem:** After a model or prompt update, behaviour shifts in small ways that nobody notices until users complain.

**The outcome:** Drift alerts against past sessions, and the ability to ask your coding assistant why an agent did something, answered from the audit record.

### Steps

1. Log sessions over time with the ZizkaDB SDK so there is history to compare
2. Call db.baseline(agent) to set drift detection against past sessions
3. After a model or prompt change, check the drift result before and after
4. Add the MCP server to Cursor or Claude: command uvx with args zizkadb-mcp and ZIZKADB_HOST set to http://localhost:8000
5. Ask in your assistant, for example why did support-bot call lookup_order?
6. Replay sessions where drift shows up to confirm the change

### Prompt to paste into your agent

```text
Connect the ZizkaDB MCP server (uvx zizkadb-mcp, ZIZKADB_HOST=http://localhost:8000). Compare <agent>'s behaviour before and after <date of model change> using its baseline, and list the sessions that drifted most with one sentence each on what changed.
```

### Caveat

The README positions it as support for EU AI Act Article 12 record-keeping, not a compliance guarantee.

Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/

URL: https://dedupedai.com/use-cases/zizka-ai-sl-zizkadb/detect-drift-in-agent-behavior/
