Verification & Observability

This is one of the biggest mindset shifts in harness engineering: you do not trust the final sentence because it sounds confident. You ask what external checks can back it up.

Verification: asking for receipts

For coding work the receipts are easy to name: tests run and pass, the build compiles, types check, lint is clean. For a presentation, it might be a browser screenshot with no overlapping text. For research, primary sources and a claim table. The shape varies; the principle doesn't — "looks good to me" is not a verification strategy.

Here's the telling detail: when an agent finishes a change and says "now let me run the tests" without being asked, people credit the model's intelligence. Some of that is real. But for a long time that behavior was a differentiating feature of specific harnesses — because the harness was engineered to steer the model toward verification as a step. The model does the checking; the harness made sure checking happened.

Observability: the flight recorder

Verification tells you whether something passed. It cannot tell you why it failed. A test fails — was the context wrong? Did a tool return bad output? Did the agent edit the wrong file? Did a sub-agent miss a constraint?

Without a run record, debugging an agent is folklore. Observability is the recorder:

• Traces — the full chain from user intent to final output
• Tool-call timelines — what was called, with what arguments, what came back
• Prompt and tool versions, costs, latency, approval events

In the wild

Eval suites that score agent runs. Trace viewers that replay every step of a session. Cost and latency dashboards per tool. Approval-event logs. If your agent product can answer "what exactly did the model see on turn 14?", it has this primitive.

Knowing isn't improving

Now the harness can prove what passed and inspect why things failed. One question remains — the one that separates a good agent session from a good agent system: does any of this make the next run better?