Inspectable by Default: Accountability for AI Agents

Inspectable by Default: Accountability and Replay for AI Agents

Your AI coding session did something clever an hour ago. It refactored a module, touched a config file, ran a command against your environment. Can you show me exactly what it did, in order, with timestamps? Probably not. You can see the end state — the files as they are now — but the sequence of actions that produced it has mostly evaporated. We have quietly accepted that agent work is write-only: the agent acts, the world changes, and the record of how is thin to nonexistent. The argument here is that this is backwards. Work an agent does on your machine should be at least as inspectable as work a person does — logged, timestamped, attributable, and replayable — and that “inspectable by default” is a property you have to design in, not a report you generate after the fact.

The write-only problem

Notice how strange the current arrangement is by comparison to the rest of computing. When a human commits code, there’s a diff, an author, a timestamp, a message. When a database changes, there’s a transaction log. When money moves, there’s a ledger with two sides. We built accountability into the systems that matter precisely because “trust me, it happened correctly” was never good enough.

Then we handed an agent the keys, and somehow the bar dropped. An agent can read a dozen files, call out to a tool, modify your project, and execute commands — and the durable trace of all that is, at best, a scrollback buffer in a terminal that closes when the tab does, or a chat transcript that records what the agent said it would do rather than what it did. Those are not the same thing. An agent’s narration of its own work is a diary it writes about itself. It is not a record.

Write-only is fine when the actor is deterministic and you can re-derive what happened. It is exactly wrong when the actor is a probabilistic model that can be confused, misled, or simply mistaken. The situations where you most need to reconstruct what an agent did — something broke, something surprised you, something looks wrong — are precisely the situations where a write-only system has the least to offer. You’re left reverse-engineering the present state and guessing at the path.

What “inspectable” and “replayable” should mean

Set the aspiration plainly. I’m describing the property we should hold agent systems to, not narrating a mechanism — the how is a deeper conversation, and an actual replay demo would cross into implementation this piece deliberately doesn’t cover. At the level of what a trustworthy system owes you, inspectable means four things:

• Logged. Every consequential action the agent takes leaves a durable entry — not a summary it chose to write, but a record of the action itself.
• Timestamped. The record has an order and a clock, so “what happened, and when” is answerable rather than reconstructed.
• Attributable. Each action ties back to what initiated it — which task, which request, which agent — so a change is never an orphan you can’t trace to a cause.
• Replayable. The record is complete and structured enough that the sequence of events can be walked through after the fact, in order, rather than inferred from the wreckage.

Replayable is the demanding one, and it’s the one worth aiming at. There’s a large gap between “here’s a log you can grep” and “here’s the actual sequence of what happened, steppable end to end.” The first is a courtesy. The second is what turns “I think the agent did something like this” into “here is what the agent did.” I’ll be honest about the boundary: demonstrating replay in a live system is a deeper, mechanism-level thing than this post covers. The claim here is about the standard, not the build — that replayability is the bar an agent-native system should be measured against, and that write-only falls short of it by definition.

Why this is an OS-level guarantee

Here’s the part that decides whether any of this is real: inspectability can’t be an app feature, because an app can only see its own process. The agent, though, acts across the whole machine — files, tools, the network, other programs. A log that lives inside one tool records one tool’s version of events and goes blind the moment the action crosses a boundary. That’s not a complete record. It’s a keyhole.

For agent work to be genuinely inspectable, the record has to live below the app, at the layer that sees every consequential action regardless of which tool initiated it. That’s the same structural argument that puts agent trust at the OS layer: the properties we want — least privilege, containment, accountability — are properties of the environment the agent runs in, not the individual program. Accountability is just the one that answers what happened. And it has cousins: durability, so the record survives the crash and the reboot instead of dying with the session; and locality, since a record of work that mostly happened on someone else’s server is a record with holes in it. Inspectability, durability, and local-first keep pointing at the same conclusion from different directions.

The takeaway

We normalized write-only agents because the tools grew up one app at a time, and no single app was in a position to keep the whole record. That’s an accident of how the tooling evolved, not a law of nature. The fix isn’t a better logging feature bolted onto the next AI editor. It’s treating inspectability as a first-class property of the system the agent runs in — logged, timestamped, attributable, and, when we get it right, replayable.

That’s one of the properties an agent-native operating system is built to hold itself to, and I’ll stay phase-honest about it: naming the standard is not the same as shipping the demo, and the alpha replaces the desktop session, not the kernel. But the direction is not in doubt. Agent work should leave a record at least as good as the one we already demand from people. Anything less, and “trust the agent” is just a request to look away.