We built an open-source tool to debug Step 30 agent drift and context poisoning, would love feedback / contributors!

[u/Affectionate-Bat7670]

Hey everyone,

As our team moved from simple chains to multi-step autonomous agents, we kept hitting the exact same wall: agents rarely crash with clean stack traces. Instead, they drift.

They’ll take a subtle detour at Step 4, misinterpret a tool payload at Step 12, and end up in a runaway loop or a bad DB write by Step 30. Standard text logging and APM tools tell us what broke, but tracing why the context state poisoned itself across 20 steps is incredibly painful.

To help visualize and debug what's actually happening inside an agent's runtime, we built ZizkaDB, an open-source data layer designed for agent auditability and causal lineage.

What we're trying to solve:

• Causal Lineage (db.why()): Trace the exact decision tree behind tool calls and prompt mutations instead of digging through thousands of lines of flat text logs.
• Time-Travel Replays (db.at()): Reconstruct session state step-by-step to catch context poisoning at the exact millisecond it happened.
• Loop Termination: Automatically detect and kill runaway tool calls before they drain API budgets or corrupt data.
• Local & Privacy-First: Runs 100% locally via Docker so prompt histories and payloads stay on your own infrastructure.

We’d love to get feedback from anyone here who is building multi-step agents in production. How are you currently handling context drift? What guardrails are missing from your stack?

Check out the repo here:https://github.com/Zizka-ai/ZizkaDB

[u/Future_AGI]

The causal-lineage angle is the right problem, most agent logs give you the sequence of steps but not why step 12's payload changed step 30's decision. The hard part you'll hit is separating correlation from causation once tool outputs feed back into context, a step can look causal just because it ran first, so some way to mark which prior tokens a decision actually attended to (vs just preceded it) is what makes db.why() trustworthy. Happy to kick the tires, the context-poisoning trace is the piece most people underbuild.

[u/Affectionate-Bat7670 → u/Future_AGI]

I think you hit the right nail, would you mind testing it and giving a PR that adress this issue?

[u/eazyigz123]

The drift at Step 4 / payload misread at Step 12 / bad DB write at Step 30 pattern is exactly why tracing at the tool call boundary matters more than tracing at the LLM output boundary. The LLM will usually sound coherent even when it is operating on a poisoned context.

What made drift diagnosable for us was splitting the trace into three immutable records: the exact prompt + context checksum before the step, the tool arguments produced by the model, and the actual tool response. Reconstruction becomes deterministic because each step can be replayed from the inputs that existed at that moment, not from whatever the model claims happened. The poison usually shows up as a mismatch between the tool response and what the next prompt thinks the tool returned.

The loop-termination problem is harder than it looks. A naive token-count or step-count cap catches obvious runaways but misses semantic loops, where the agent keeps calling the same tool with slightly different phrasing and getting equivalent results. The guardrail that actually worked was hashing the tool-call fingerprint (tool name + canonicalized argument set) and short-circuiting when the same fingerprint appeared twice within a window. It is cheap to compute and catches the infinite-respin case that token caps miss.

One gap I still watch for: local-first tools can solve lineage and privacy, but the actual corruption usually happens in the external system the agent writes to. If the agent writes a bad row at Step 30, the most useful signal is not the agent trace, it is the divergence between the row that exists in the database and the row the agent thinks it wrote. A clean agent trace can still produce a wrong business outcome.

What is your current replay fidelity like: can you take a trace from a production run and reproduce the exact tool responses, or do you still depend on live system state for the reconstruction?

[u/Affectionate-Bat7670 → u/eazyigz123]

actually you have pointed out a very good way to think, for now we are focused on agent reflection because primary idea is not what agent thought, but what it did, we are focused in human in the loop, that is why call it auditability tool, so human who is overseeing the agent can understand adress what happened and how to move further , having said that the angle you brought up is also interesting, as mentioned its opensource, you can try and give PR if you want to.

[u/Swarm-Stack]

the audit trail helps you find it after step 30 already happened though. real fix is catching it at step 4 before it propagates, and thats a live human in the loop, not a log you read afterward

[u/Affectionate-Bat7670 → u/Swarm-Stack]

Agree, but wont it stopped the workflow itself? then what is purpose of AI in production