Etch
Trace, replay, and verify every AI agent decision.
Start new thread

Etch - Trace, replay, and verify every AI agent decision.

by•
Every AI agent decision (prompts, tool calls, edits, multi-agent handoffs) recorded into a tamper-evident, verifiable history. Debug why the agent did what it did without grepping text logs. When customers or auditors ask what your agent did on Tuesday, prove it in one link. Sits underneath whichever agent stack or context graph you already use. Works with Claude Code, Cursor, Codex, Continue, and any tool that emits webhook events.

Add a comment

Replies

Best
Maker
📌
Hey everyone, Saravanan here. Started building world-model-mcp a while back to help coding agents maintain context across sessions and avoid repeating mistakes. Focus was on giving agents a structured memory they could actually use reliably. While using it on real projects, it became clear that memory alone was not the full problem. Even when the agent made good decisions, there was no clean way to later understand or prove why a particular decision was made, what context was used, or what constraints were considered. That gap became especially noticeable when I needed to debug something after the fact, review a multi-agent handoff, or answer a straight question about what an agent actually did. Text logs go stale, in-memory state is gone. That is what led to Etch. It records every agent decision into a verifiable history, so you can trace, replay, and validate what happened long after the run. Free to try today. If you build with AI agents and have run into any of this, would love to hear how you are handling it currently. world-model-mcp is Apache-2.0 on GitHub for anyone who wants to look at the memory layer side.

The tamper-evident history part is really nice, especially for audit handoffs. One thing that would help a lot: let me pin a custom note or human decision onto a specific span in the timeline. Right now I can see what the agent did, but if I intervened mid-run or overrode a tool call, I want that context attached right next to it instead of buried in a separate log.

Maker

 thanks for this. Appreciate the specific ask.

The underlying "world-model-mcp()" decisions table already carries source_tool and confirmer provenance fields, so the data model supports it. What's missing is a first-class primitive for pinning a human note or override rationale directly to a span in the timeline, signed into the same Merkle chain as the agent events. Right now those would land in the general events log, exactly the pattern you called out.

I'm going to prioritise this. A pin_annotation MCP tool that attaches author, rationale, and timestamp to an event range, signed the same way agent events are, feels like a clean addition.

One question back: would you need reviewers to filter human interventions from agent actions as a separate view, or is a single unified timeline with author metadata enough? Would shape whether annotation is a distinct event type or a field on the existing schema.

Plugged it into my Claude Code setup and the multi-agent handoff view alone is worth it, way easier than piecing together scattered logs. Curious how it handles high-volume sessions though.

Maker

 thanks for actually installing it. The handoff view was one of the harder pieces to get right, so it means something that it landed for you.

On high-volume: the largest project I'm testing against right now is a design partner at ~16K+ events on the default SQLite backend, running without issues. Epoch closes (default 1024 entries) batch the Merkle root sign with Ed25519 + SLH-DSA, so per-event overhead is a single hash. Signing throughput is not the bottleneck.

Where you could hit ceilings on default SQLite, based on the underlying engine's scaling envelope (not yet benchmarked at these levels in Etch):

  • ~500K+ events per project starts showing query latency (fact retrieval uses FTS5)

  • Concurrent write contention past ~50 sessions/sec on a single project

Both are solvable. Postgres backend is on the roadmap for fleet-scale teams. Per-project SQLite sharding works today for multi-project deployments.

One question back: what load shape are you looking at? Concurrent sessions, event burstness, retention window? Would help me tell you what would hold vs what would break.