Evidence note: This article rests on the public self-presentation of a cluster of recently surfaced open-source projects — their repositories and one public discussion thread — plus a specification deposited in a public research archive. None of the capabilities described below have been independently verified, benchmarked, or reproduced for this article, and no test was run. Every functional claim here is therefore the claim of the project making it, and is marked as such at the point it appears. Where a claim is simply open, it is named as open rather than softened.
Logs prove an execution happened; they do not let you run it again
A log line is a past-tense assertion. It says a request arrived, a tool was called, a row was written. What it does not give you is the ability to put the system back where it was and watch the decision form a second time. For deterministic software that gap is usually tolerable, because the code is the record: given the same input, the same branch is taken. For an agent it is not, because the thing that chose the branch was a model sampling from a distribution, against a context window assembled at runtime from state that has since moved on.
That is the gap a growing set of projects is aiming at. Instead of observability — aggregate traces, spans, dashboards — they target the execution record: an artifact complete enough that the run can be reconstructed rather than merely summarised. Several of these appeared in public within a short window, including record-and-replay harnesses (agent-vcr), per-episode recorders (epi-recorder), and graph-structured trace models (AgentTraceDAG). The existence and framing of these projects is checkable from the repositories; whether any of them delivers faithful reconstruction in practice is not established here.
What an execution record actually holds
The composition that keeps recurring across these projects is four-part: the model’s inputs and its outputs, the tool calls with their results, the run metadata, and — the part that distinguishes a record from a trace — the actions that modified files, captured alongside a snapshot of what those files looked like before the modification.
Evidence level for that composition: uncorroborated. It is a description assembled from how these projects present themselves, not a verified schema, and it should be read as an open question rather than an established standard. No common format has been demonstrated across the projects named here, and nothing in the available material confirms that the file snapshots are complete, bounded in size, or retained long enough to matter. For a comparison of what different recorders in this space actually choose to capture — including one whose capture surface extends past the agent — see the earlier survey of tools that record the agent, and the one that also records you.
The reason the snapshot matters is that the other three parts are all intent. Prompts, completions, and tool arguments tell you what the agent meant to do. Only a before-image tells you what the world looked like when it did it.
Replay without re-running the models, and the determinism evaluation needs
The practical argument for a record over a log is cost and repeatability. If the model’s outputs are stored with the inputs that produced them, a replay can serve the stored output instead of calling the provider — the same pattern HTTP fixtures have used for a decade, applied to completions (agent-vcr). The run becomes deterministic, which is the precondition for evaluating a change to the surrounding code: if the model is held fixed, a difference in outcome is attributable to the orchestration.
Evidence level: uncorroborated. The mechanism is plausible on its face and familiar from non-agent testing, but no measured fidelity figure, cache-hit rate, or divergence rate is available for any of these projects.
The limits are worth stating plainly, because replay-without-models only holds while the recorded context is reachable. Change a prompt template, add a tool, or alter retrieval and the stored response no longer corresponds to any input the system would now produce. Whether these projects detect that mismatch or silently replay a stale answer is open. The cost pressure behind the idea is real enough — the economics of where agent inference actually runs were examined in the earlier look at what "local" means in the 2026 agent wave.
Sealing the record: a signature over canonical JSON
One project frames the unit not as a trace but as a receipt: what the agent decided, what it did, and what changed, serialised as a single canonical JSON artifact and signed with Ed25519 over an RFC 8785-style canonicalization, such that any mutation of the payload invalidates the signature (circe-receipts). A related project targets tamper-evident traces from the same direction (AegisTrace).
Evidence level: uncorroborated, and specifically the project’s own description. The cryptographic primitives named are standard and well understood, which makes the design credible as a design; it says nothing about key custody, revocation, or whether the canonicalization is applied to the whole semantic payload or a digest of part of it. The broader claim — that such records can be verified offline without trusting the issuer’s infrastructure — is open. Offline verification requires a trusted public key distributed by some means, and no project here demonstrates that distribution.
The appeal is structural rather than cryptographic. A signed record is portable: it can be handed to someone who does not have access to the system that produced it, and checked. Why that portability becomes load-bearing the moment an agent’s write is the thing in dispute was the subject of an earlier piece on the signed receipt for a write that never happened.
Why a forgeable or truncatable log leaves no portable proof
The motivating argument across this cluster is that, absent a tamper-evident record, there is no portable way to prove what an agent did when production goes wrong — because logs can be edited, rotated away, truncated under volume, or simply lost, and a dashboard is a rendering of a store you control. Evidence level: uncorroborated; this is an argument the projects advance, not a demonstrated failure mode with incident data behind it.
It is worth separating the two halves. That operational logs are mutable and lossy is unremarkable and widely experienced. That the consequence is specifically no portable proof is a stronger claim, and it depends on who is being convinced — an internal post-mortem and an external counterparty have very different standards. None of the available material establishes that any counterparty today accepts a signed agent receipt as evidence.
Stale snapshot, live data, no error raised
The failure the title points at is narrow and unglamorous. An agent reads a record, spends time generating output from it, and writes the result back. In the interval, the source changed. The write succeeds. The transport returns a clean 200 OK. Nothing raises, nothing retries, and the only signal is that live data now reflects a state of the world that has passed.
Evidence level: uncorroborated as a described failure mode. No incident report, reproduction, or frequency figure is available here. What makes it worth taking seriously is that it needs no bug to occur: every layer behaves correctly in isolation. The agent wrote what it generated, the API accepted a well-formed write, the database stored it. The error exists only in the gap between dispatch and landing, which is exactly the place no component owns.
Suppressing the write and keeping the record
The response one project describes is to make the mutation layer, rather than the agent, responsible for that gap: when the source record has changed since dispatch, the runtime suppresses the write, classifies why it was suppressed, and persists an execution record of the write that never landed (mongoclaw). Evidence level: uncorroborated project self-description.
The classified reason is the interesting half. A suppressed write with no reason attached is indistinguishable from a dropped one, and an agent that cannot tell the difference will either retry blindly or fail silently. A record of a non-event is also an unusual thing to want: it asserts that something was deliberately not done, which is precisely the fact that conventional logging — which records effects — has no slot for. Whether any of these reason taxonomies is stable or complete is open.
Checking a proposed action before it executes
A record is retrospective by construction, and the second direction in this cluster is to move the check earlier: validate an agent’s proposed action against the live system of record before it is allowed to execute, rather than only capturing it afterwards (ActionRail, pawbot). Evidence level: uncorroborated.
This is the same architectural move as a pre-commit check, and it carries the same cost: another read against the authority of record, in the latency path, for every write. No figures on that overhead are available. The pattern of an automated system proposing a change for validation rather than applying it directly also appears in security tooling, examined earlier in the look at vulnerability discovery with proposed patches.
Forking from a decision point
Several projects extend recording into interactive debugging: fork the run at a specific decision point, modify the payload, replay forward from there, and rewind state to a prior snapshot (Forked, agent-loom). A durable runtime is positioned as the substrate that makes this possible, with replay from state checkpoints and ‘what-if’ experiments framed as feeding a self-improvement loop (kitaru).
Evidence level: uncorroborated for both the time-travel mechanics and the self-improvement framing. The debugging capability and the self-improvement claim deserve different scepticism. Forking and rewinding is an engineering problem with known solutions in other domains. "Aimed at a self-improvement loop" is an aspiration, and nothing available here shows a loop that closed — that is, a recorded counterfactual that produced a measured improvement in a later run.
Records as delivered work
The last framing in this cluster treats the record less as a debugging aid than as the deliverable. If every effect of a run is captured, individual events can be proven and the agent’s delivered work can be audited rather than accepted on trust. Adjacent to it: coding agents exposing execution records so that delegated, bounded work can be inspected after the fact; a repo-native work record spanning spec, task queue, evidence log, review notes and handoff summary used to structure a coding agent’s execution (clio-coder); and recorded runs used as evidence capture to validate UI flows and emit structured results in automated testing (a2awebagent, ZeroToken).
Evidence level: uncorroborated for all of the above. The repo-native pattern is the most immediately testable of them, since it is just files in a repository — but no adoption data, completion rate, or review-quality figure is available, and whether structuring an agent this way improves outcomes is open.
Grip, and the move toward an open protocol
The furthest-reaching claim in this material is that the problem is a protocol problem rather than a tooling one: that authorised, bounded, attributable agent execution should be specified once and implemented many times. Grip is presented as such an open protocol, with a specification deposited in a public research archive and discussed publicly (specification record, public discussion).
Evidence level: uncorroborated. That the material exists and is publicly readable is checkable; that it constitutes an open protocol in any operative sense — multiple independent implementations, a stable wire format, an interoperability test — is open, and no second implementation is identifiable here. Protocols are established by adoption, not by publication, and on the available evidence this is publication.
Developer takeaway, and the question none of these records answers yet
For anyone shipping an agent with write access, two of the ideas above are worth acting on independently of whether this cluster of projects survives. First, store a before-image with every mutating action, because intent data alone cannot reconstruct a bad write. Second, treat the interval between read and write as a place where correctness is lost, and give the mutation layer — not the model — the job of noticing that the source moved; a suppressed write with a classified reason is recoverable, while a successful write of stale output is not. Both are ordinary engineering, available today, and neither requires signatures or replay.
The signing and replay machinery is a later purchase, and the honest framing is that it is early. The designs are credible on their primitives and unproven in operation, and they do not agree on what a record contains.
What none of these records answers is who is obliged to accept one. A signature establishes that a payload was not altered after the issuer sealed it. It does not establish that the issuer’s description of its own agent’s behaviour is accurate, nor that any counterparty — a customer, an auditor, a regulator, the other side of a failed transaction — has agreed in advance to treat the artifact as dispositive. Until there is a verifier someone other than the issuer runs, and a schema more than one implementation emits, a sealed execution record is a very well-constructed assertion about oneself. That is a real improvement over a mutable log. It is not yet proof.