Logs show activity. Evals score outputs. FoxCommand records the decision.

Why observability is necessary but not sufficient for consequential AI workflows.

FoxCommand·June 2026

I want to be careful here, because this is the section where it would be easy to sound like I'm dunking on tools I actually respect.

I'm not. If you're running serious agentic workflows you almost certainly have observability and you almost certainly have evals, and you should. They are necessary. The argument I'm making is narrower and more annoying than “they're bad.” It's that they answer two questions, there are three, and the third one is the one that shows up in the room with the lawyer in it.

Three questions, three layers

Walk a single consequential decision through the stack you already own.

Logs and observability — LangSmith, Arize, Langfuse, Datadog. These answer did it run, and what happened? They give you spans, tokens, latencies, the model version, the prompts, the routing. This is execution truth, and it is genuinely indispensable. When something is on fire at 2 a.m., this is the layer you live in.

Evals — Braintrust, your internal harness, the scorecards. These answer was it any good? They tell you the model hits some precision and recall on a graded set, that this prompt beats that prompt, that quality is holding in distribution. Also indispensable. This is how you ship with any confidence at all.

Decision records — FoxCommand. This answers why this decision, under what authority, and can I defend it? What policy version was in force. What threshold governed it. What documents it had. Whether the autonomy boundary required a human and whether one signed. Preserved as one artifact, at the moment of the decision, for the specific case someone will eventually ask about by name.

Three different questions. The first two are about the system. The third is about a decision. That's the gap.

Observability tells you the system ran. Evals tell you the system is good. Neither tells you why this decision was made, under which rules, and whether it was allowed.
three questions, three layersIllustrative

Captures

  • · Policy version
  • · Threshold
  • · Retrieved docs
  • · Autonomy-boundary outcome
  • · Signed at decision time

Answers

Answers the question that was asked.

The point: you probably own the top two. This is about the one underneath the question.

Why “good on average” doesn't survive the room

Here's the trap, and it's a comfortable one.

Your evals are green. The model scores 92% on the graded set, the dashboards are calm, the traces are clean. By every measure you have, the system is healthy. So when the question comes in about case #4471 — the denial from March 3rd — your instinct is to reach for those numbers.

But the regulator did not ask how the model performs on average. They asked about case #4471. And an aggregate score, however high, is the wrong shape for that question. 92% is a statement about a distribution. The letter on your desk is about one decision inside it — and statistically, possibly one of the 8%. You cannot answer a specific question with an average and call it a defense.

The logs are closer, because at least they're per-case. But the trace for #4471 says criteria not met, escalated. It shows you the path. It does not preserve which policy version defined “criteria,” what threshold “not met” was measured against, or whether the system was even authorized to resolve that class of case on its own. It's a faithful recording of execution that is silent on authority.

The decision record is the only one of the three built to answer the question that was actually asked — about that case, by name, under the rules in force that day.

one question, three layers · two of them missIllustrative
Q: Why was case #4471 denied on March 3rd?
Logs
Evals
Decision Record

The point: two of these are necessary. Only one of them is an answer.

Necessary is not sufficient

So this isn't a teardown and it isn't a replacement. You keep your observability. You keep your evals. FoxCommand doesn't sit on top of them or underneath them; it sits beside them, capturing the one artifact neither was designed to hold.

The autonomy boundary is the clean way to see where each belongs. Below the line — where the agent advises, drafts, suggests, and a human owns the outcome — logs and evals are plenty. Above the line — where the agent acts, where a decision ships downstream and becomes consequential — you need a record, because that's the decision someone will ask you to defend by name.

Most teams believe they already have all three. They have two, and a faithful log of the third that goes quiet at exactly the question that matters.

We're building the layer that answers the third question. The first two are doing their jobs. They were just never asked to do this one.

Building AI workflows that need to be defended?