You Cannot Trust What You Cannot Replay

An agent in production did something wrong. A customer got an email they should not have, or a credit got applied that should not have. Now answer one question: why? Not “what is the model in general capable of,” but specifically, what did this agent see, what did it conclude, and what exact chain of decisions led it from a benign trigger to a wrong action, on Tuesday at 4:17pm.

If you cannot answer that question precisely, you do not have an autonomous system. You have an unlogged actor with write access to your business, and you are hoping it behaves. The hoping is not a strategy. Trajectory logging and rollback are not features you add to a finished agent. They are the thing that makes the agent trustworthy enough to ship at all.

A log line is not a trajectory

Most “agent logging” captures the wrong thing. It records that an action happened. The refund was issued. The email was sent. That tells you the outcome and nothing about the reasoning, which is exactly the part you need when something goes wrong.

A trajectory captures the whole decision path. For every step the agent took, it records what the agent perceived, what it was thinking, what it decided, and what it did:

step 4  perception: invoice INV-2291, status overdue, customer "Acme",
                    message thread quoted text included a refund figure
        reasoning:  customer appears to request refund of $4,000
        decision:   propose refund, amount 400000 cents
        envelope:   refund_cap 50000 -> DENIED at cap
        outcome:    blocked, escalated to human
        inputs_hash: 9f2a...   model: claude (1m ctx)   latency: 1840ms

That single record answers the why. The agent pattern-matched a number out of a quoted email thread, decided on a $4,000 refund, and the envelope killed it. Without the perception and reasoning fields, all I would have is “refund blocked,” and I would never learn that the agent was being misled by quoted text, which is the actual bug and the actual fix. The trajectory is what turns an incident into a lesson instead of a mystery.

If your log tells you what the agent did but not what it saw and why it chose to, you can detect failures. You cannot diagnose them, and you certainly cannot prevent the next one.

Replay is the discipline that keeps you honest

Logging perception and reasoning enables the thing that actually matters: replay. Because the trajectory records exactly what the agent perceived at each step, including a hash of its inputs, you can reconstruct a run and step through it. You can see the moment the reasoning went sideways. And if you fix a prompt or tighten an envelope, you can re-run the same trajectory against the change and confirm the agent now does the right thing on the input that previously broke it.

This turns agent debugging from archaeology into engineering. Without replay, a production incident is a guess. You read some logs, form a theory, change a prompt, and hope. With replay, you reproduce the exact failure, watch it happen, fix it, and prove the fix against the real input. I treat a reproduced failing trajectory the way I treat a failing test: it is the thing I am allowed to consider fixed only once it passes.

Replay also pays for itself outside of incidents. Before I widen an agent’s envelope or push a decision up the autonomy ladder, I replay a corpus of past trajectories against the proposed change. If loosening a limit would have caused any historical run to do something I do not want, I find out before it ships, not after a customer does.

Rollback is the difference between a mistake and a disaster

Logging tells you what happened. Rollback lets you undo it. An autonomous system that can act but cannot reverse its actions has an unbounded downside, because the cost of any single wrong action is permanent. Reversibility is what caps the blast radius.

This is why I design actions to be reversible from the start, and why every consequential action carries enough recorded context to be undone. A credit applied as a ledger entry can be reversed with another ledger entry. An email sent within a recall window can be pulled. A status change can be set back, because the trajectory recorded the prior status. The agent’s outputs are not raw side effects fired into the void. They are recorded operations with a defined inverse.

def apply_credit(run_id, step, invoice, cents):
    entry = ledger.post(invoice=invoice, amount=-cents,
                        origin=(run_id, step))   # reversible by construction
    record_trajectory(run_id, step, action="apply_credit",
                      reversal=lambda: ledger.post(invoice=invoice, amount=+cents,
                                                   origin=(run_id, step, "reverse")))
    return entry

When an action genuinely cannot be made reversible, like a real charge to a real card, that is the signal that it does not get to be autonomous. It goes to a human gate. Irreversibility and autonomy do not mix, and the trajectory log is where I enforce that, because an irreversible action with no recorded reversal path is one I refuse to let an agent take on its own.

What this gives you that nothing else does

Put trajectory logging and rollback together and the whole posture toward autonomy changes. Three things become possible that are impossible without them.

• Attribution. Every consequential action traces back to the run, the step, the perception, the reasoning, and the envelope that permitted it. In a federal context this is not optional. “The agent decided” is not an answer; “here is the full chain from trigger to action, and the authority that allowed it” is.
• Bounded blast radius. A wrong action is a thing you reverse, not a thing you survive. The downside of any single autonomous mistake is capped at “undo it,” which is what lets me grant more autonomy on reversible decisions in the first place.
• Compounding improvement. Every failure becomes a replayable trajectory, which becomes a regression test, which means the agent gets monotonically safer instead of failing the same way twice. An agent that cannot be replayed makes the same mistake forever, because you can never prove you fixed it.

The actual prerequisite for autonomy

We talk about autonomy as if the hard part is the model’s intelligence. It is not. The hard part is building the substrate that makes an intelligent actor safe to leave running: the durable state so it survives, the envelope so it cannot exceed its authority, the human gates on the irreversible, and underneath all of it, the trajectory log and the reversal path that mean you can always answer why and always undo. This substrate is exactly what I’m building underneath the agents in Vontra, because the model was never the hard part.

The order matters, and it is the opposite of the order people build in. The instinct is to build the autonomous agent and add observability later, when there is time. There is never time, and by then the agent is in production making decisions you cannot reconstruct. So I build the replay and the rollback first, before the agent does anything consequential, because an agent I cannot replay is an agent I cannot trust, and an agent I cannot trust has no business touching a real business.

Autonomy is earned, not declared. It is earned by being able to point at any action the system ever took, replay exactly how it got there, and undo it if it was wrong. Build that, and you can let the thing run. Skip it, and you have not built an autonomous system. You have built a fast way to do something irreversible and never find out why.