Every agent run in my stack leaves a trace. It doesn't capture the content the agent read or wrote. It records metadata: the plan it ran, the context files it opened, the tool calls it made, the metrics, the exit status. A small JSON file per run, plus one append-only row in an index. That's it.
It started as a way to stop scraping raw logs. When an overnight run did something surprising, I'd dig through pages of output trying to reconstruct what happened. The trace collapsed that into one file I read in ten seconds: here's the plan, here's what it touched, here's how it exited. No archaeology.
Keeping it metadata-only is deliberate, and it buys two things at once. Because I don't store what the agent read or generated, a trace can't leak the contents of a private file or a customer record. And it still answers the questions that matter: did the run touch files it shouldn't have, did it exit clean, did it stay inside its budget. None of those need the content.
Then the trace grew a second half. A tripwire reads the trace before the next run is allowed to proceed, and it fails closed. The pre-run gate is the load-bearing piece: lifecycle_start runs first, and if the trace looks wrong, the run doesn't start. Postflight can change how the next run proceeds too. The gate defaults to blocking, so a broken or missing trace stops the pipeline instead of waving it through.
I shipped v0.1 as a fail-closed CI gate. Zero dependencies, no content capture, wired into CI so it runs on every change and not only when I remember to look. That last part matters more than it sounds. A safety check I have to run by hand is a safety check I'll skip on the busy day, which is exactly the day I need it running.
The loop I ended up with is short: trace every run, gate on the trace, block by default when the trace is bad. Three steps, no content capture, and it runs whether or not I'm paying attention. That last property is the whole reason it earns a place in the pipeline.