Your Agent Needs a Chain of Custody, Not a Better Prompt

A run finished at 2:40am. Dozens of actions. I had approved two of them.

That night is a composite of runs like it, not a single incident I logged. The pattern is the point.

The two I approved were emails. The rest were reads, drafts, and internal writes. It opened a folder of notes, pulled a spreadsheet, drafted four replies, wrote two files, and updated a log of its own. Nothing broke. I closed the lid and went to bed.

At 9am I tried to answer a question I thought would take a minute. What did it do?

I could show what it produced. Four drafts in a folder. Two emails in a mailbox. Then I opened the run record. The record was thin: most entries carried a timestamp and a tool name, and no arguments. A few said only "tool call completed."

I could tell you what it produced. I could not tell you what it did.

That gap is the whole problem, and it is not a model problem.

The model is the part you will replace

Earlier this year I wrote about giving an agent my phone number. That post was about capability: what happens when you hand an agent a channel, a tool list, and permission to keep going. A few weeks ago I published the six questions I ask about any AI tool. This is the other half: what the agent leaves behind.

Everyone argues about the layer that changes. Which model, which harness, which framework, how large the context window. Those choices matter, and they matter less every quarter. The model is the part that gets cheaper and gets swapped. A prompt is a craft, and a good one is worth writing. A prompt is not a control.

The model is the part you will replace. The record is the part you deploy.

The record is the boring artifact that survives the swap: which tool ran, with which arguments, under whose authority, and whether the evidence still holds after a week of other people touching things. Swap the model tomorrow and the record still has to answer for yesterday.

Three ways an agent loses its story

All three are record failures, not model failures.

Silent action. The agent did something real and the record does not show it. The email sits in the recipient's inbox. The row changed in the database. The file left the folder. Your log says the tool ran. It does not say with what, against which record, or what came back. And the log lives in the vendor's console, on the vendor's retention schedule, behind the vendor's export button. The action crossed your boundary. The evidence stayed inside someone else's product.

The advisory gate. This is the one that looks responsible on a slide. A human approval step that is a notification. The run does not wait. It pings you, keeps going, and the ping lands after the work is done, or at 2:41am while you are asleep. If the process can finish without the approval, the approval is decoration. A gate that does not block is a status update.

Unrecoverable state. Something goes wrong and you cannot roll back, replay, or export. You cannot reconstruct the inputs the agent saw, so you cannot reproduce the decision, so you cannot explain it. You can turn the agent off and apologize. That is the full menu.

What the record has to contain

Four parts: action classes, a gate for each class, an append-only log, and a replay path.

Action classes. Classify by consequence, not by tool name. "Filesystem write" tells you nothing about whether the write mattered. A read, an internal write, and an outbound email are three different risks, so they get three different gates.

A gate per class. The gate is code, not a policy paragraph. It sits between the agent's intent and the effect, and it can refuse. A read needs no approval. An outbound email needs a blocking approval, per message, with the exact body attached so the approver approved that text and not a summary of it. Spending money gets a ceiling and an approval above it. Changing permissions gets two approvers and a channel the agent cannot reach.

An append-only log. One entry per action. The intent is appended before the effect and the outcome is appended after it, so the chain records both what was attempted and what happened. Each entry carries the run id, the step number, the parent step, the tool and its version, a hash of the arguments, a hash of the result, and the approval record. Each entry also carries the hash of the entry before it. That chain is what makes the log tamper-evident: edit a line or delete one, and every later line stops matching. It does not make the log tamper-proof. Someone with write access can still damage it. What they cannot do is damage it quietly.

A replay path. Every logged action keeps enough to run again: the inputs, the tool version, the model version, and the state it saw. Replay in a dry run against a copy, compare the result, and you know whether the behavior is stable. Without replay the log is a story. With it, the log is a test.

That table is the minimum I would specify. Helm implements four classes — read, workspace write, mutating, outbound — with a blocking gate on the last three. Spend and permission changes arrive as mutating or outbound actions, not as separate classes. Add a class when a new tool creates a new consequence, not when a vendor ships a new integration.

What the record proves, and what it does not

Helm is an agent workspace built for in-boundary deployment. It runs on HARBOR's hosts today. It has more than 180 evidence tests behind it. helm.harborgovcon.com

Evidence tests test the record, not the answer.

An evidence test does not ask whether the output was good. It asks whether the record is complete: the approval is present, the scope matches the action, the argument hash matches what was executed, and the chain still verifies. The useful version of that test also breaks the log on purpose, deletes an entry, and asserts that verification fails. If nobody has tried to break the log, tamper-evident is a claim, not a property.

Here is what I cannot claim. Helm has no ATO, no certification, and no FedRAMP or CMMC status. No customer runs it, federal or commercial, and no pilot has run. I am not an assessor. The record does not substitute for that work, and it will not pass an audit on its own. What it does is narrower: when a step is missing, you can see where, and you can show the break to somebody else.

I said at the start that the run is a composite. I would rather say that early than let a good story do work that a record should do.

The Bottom Line

You do not need a better model to deploy an agent. You need a record you can defend when the model is gone and somebody asks what happened.

Write three things down before the agent touches anything real. Which actions require a person who can say no. What each log entry must contain. How you would replay a run from six weeks ago. If you cannot answer the third one, the first two are theory.

You cannot deploy what you cannot reconstruct.

If you are about to let an agent into a workflow that matters, the review starts with the record, and it is the work I do: /services.