WRITING
Date
September 2026
Read time
6 min
Category
engineering

Trust Is a Checklist, Not a Feeling

A few weeks ago, my own system tried to hand me a fake — fluent, plausible, and wrong. A checklist question caught what inspection never would have. Here's the pre-flight for any agent with persistent memory, before it touches production.

A few weeks ago, while producing this very series, my own system tried to hand me a fake.

The task was mundane: take an article I had already reviewed and approved, and place it into the publishing pipeline. The approved file wasn’t where the executing agent expected to find it. And here is where it gets interesting — because the agent didn’t fail, and it didn’t ask. It rebuilt the article from its task description. Fluently. Plausibly. It even added a few specific details that sounded exactly right: a participant count, a date range, a technical claim. None of them had been verified. All of them were the kind of thing that sails through review, because nothing about a confident reconstruction looks wrong.

It got caught for one reason. The delivery gate carried a question that had to be answered before anything shipped: was this written from the approved source, or rebuilt? The honest answer — rebuilt — triggered a replacement with the actual approved artifact, and the fabricated details died in a branch instead of on my website.

Read that story again and notice what did the catching. Not inspection — the output read beautifully. Not expertise — I approved the original and still wouldn’t have spotted the drift on a casual read. A question caught it. A question asked at the boundary, before trust, whose answer had to be on file.

Now the uncomfortable part. Sometime this week, an agent in your system wrote something down — a status, a summary, a conclusion — and another process read it and built on it. Nobody reviewed the note. Nobody signed it. That’s not an accusation; it’s arithmetic, and you knew it was true before you finished the sentence. The only difference between your week and mine is that my pipeline asked the question. Most pipelines don’t.

That’s the whole final argument of this series, and it fits in one sentence.

Pilots don't trust the plane. They trust the checklist.


Nobody walks around an aircraft because they doubt the machine. They walk around it because fluent-looking systems fail in ways inspection doesn’t catch, and because the walk-around converts trust from a feeling into a procedure. The pilot’s confidence isn’t faith. It’s a list of questions with answers on file.

(Already feeling this one? The walk-around exists as a working tool: the Context Architecture Blueprint — free, MIT-licensed. The rest of this article is why it exists.)

Over the past three weeks this series established that your AI system now runs substantially on what it remembers — working notes it rewrites hourly, records that outlive the session, documents it treats as ground truth, and conclusions one agent hands another. Last week mapped those four surfaces and where a control attaches to each. This week is the walk-around: the questions worth answering before any agent with persistent memory touches production — or, if it’s already there, before you sign this quarter’s attestation that everything is under control.

The working-state questions. Where does the agent’s in-flight state actually live — context window, scratch file, database row? Is it snapshotted at decision boundaries, so a long run has a diffable “before” when something turns? And if a run went sideways at hour six, could you tell — today, with current tooling — what it believed at hour five?

The persistent-store questions. What can write to long-lived memory — which agents, which processes, under what conditions? Does the write path distinguish an assertion (the system claims it) from a verified fact (checked against the artifact it describes)? And when a record turns out to be wrong, can you trace what was built on top of it — or does correction mean hoping?

The corpus questions. When was your retrieval corpus last audited against reality, and by whom? Does every source have an owner — a name, not a team? What’s the freshness half-life of its most load-bearing documents, and does anything expire on a schedule rather than on an incident?

The handoff questions. When one agent writes a conclusion for another, does the record carry an author, a source, and a confidence — or just the conclusion? Can a downstream consumer, human or machine, distinguish a verified result from an upstream summary? If the answer is no, you don’t have handoffs. You have rumors with good formatting.

And the question that governs the other four. Who answers these — by name? A checklist without an owner is a poster. The pre-flight works in aviation because a specific person signs it, and the signature means I walked around the plane. Your memory surfaces deserve the same: one accountable name per surface, on file, before trust.

Fifteen questions. No framework adoption, no platform migration, no new headcount. Every one has a knowable answer with the stack you already run. The list changes exactly one thing: whether you learn the answers before the system is trusted — or after it’s wrong.

If you can't answer it before launch, you'll answer for it after.


Four weeks ago this series opened with a phantom file — a record my system remembered that was never true, trusted downstream for weeks. If you’ve followed the whole arc, you’ve watched that one incident become a discipline: the evidence that the entire industry moved behavior into memory. The map of the four surfaces where that memory lives. And now the checklist that stands between those surfaces and your production traffic.

Here’s the closing version of the honest position, and it’s the strongest one yet: if you can answer even most of these questions, you are ahead of nearly every team running agents today — not because the questions are hard, but because almost nobody has asked them yet. The surface is new. The checklist is short. The teams walking around the plane this quarter are buying something the market hasn’t priced in: the ability to say here’s how we know, calmly, with the answers on file, when someone finally asks.

A checklist you have to reconstruct from a blog post is a checklist that never gets run. So I built the walk-around as a working tool. The Context Architecture Blueprint turns these questions into a structured assessment of your own architecture: where your memory surfaces are, which controls exist, which are missing, what to fix first. It’s free. It’s MIT-licensed. It’s shorter than your next status meeting. Run it while “we’re working on it” is still an acceptable answer.

The behavior moved into memory. The map exists. The questions are knowable. All that’s left is the walk-around — because pilots don’t trust the plane. They trust the checklist.


This series applied The Comprehension Standard — AI doesn’t reach production until you can see, understand, and verify what it does — to the newest surface in the stack. Start with the Context Architecture Blueprint, free and MIT-licensed. And if your team is standing where this series started — accountable for a system you can’t fully see into — that’s the conversation I have every week.

Wilfred Morgan

AI Systems Architect · Agentic AI Implementation

Book a Strategy Call →