AI Agent Observability Isn’t a LangSmith Feature

Key takeaways

• LLM observability records token traces. Agent observability records decisions. Buying the first as the second leaves an audit gap.
• The hard audit question is whether you can reconstruct why an agent acted, at the moment it acted.
• Four capabilities matter: decision context, stated reasoning per tool call, side effects with reversibility metadata, and replay against the same instructions.
• Most platforms capture inputs and outputs. Few capture the reasoning and reversibility metadata a CISO actually needs.
• You may not need to switch tools. You do need to ask your current vendor four specific questions.

What the CIO/CISO actually needs to know

A refund agent issued a $4,200 refund it should have escalated for review. That is a tolerable sentence to read in a quarterly report. It is a much worse sentence to read in an incident review, because the next question is always the same. Why did it decide to do that?

In most production agent setups I have looked at, the honest answer is that we cannot fully say. The log shows the agent received a dispute, called a refund tool, and the money moved. It shows the inputs and the output. It does not show what the agent read before it chose, which policy it weighed, what other actions were available to it at that second, or whether a human ever had the chance to stop it. The action is in the record. The decision is not.

That gap is what a CIO or CISO needs to understand before they sign off on agents running in production. A bigger dashboard does not fix it. The problem is accountability, and it grows every time you add another agent. The tool most teams bought to close that gap was built to watch a different system.

How is agent observability different from LLM observability?

LLM observability watches a language model produce text. It captures the prompt, the tokens, the latency, the cost, and often a chain of calls drawn as a trace. Langfuse, LangSmith, Arize Phoenix, Helicone, and Weights & Biases all do versions of this, and they do it well. If your problem is a model that hallucinates, drifts, or runs up a bill, this is the right category of tool.

An agent is a different kind of system. It reads context, weighs options, picks a path, and takes actions that change the state of the world. Watching the tokens it generated tells you what it said. It says nothing about why it acted, and it gives you no way to stand the decision back up and inspect it. Those are separate questions about separate systems, and the second one is the one that ends up in front of an auditor. LLM observability and agent observability are different categories.

Let me define agent observability precisely, the way I am using it here. It is the ability to reconstruct, after the fact, the decision an agent made at the moment it took an action: what it saw, what it could do, why it chose, and what changed as a result. The text the model produced is the smallest part of that.

• The prompt and the completion, Agent observability requires: The full context the agent read before it decided
• Token counts, latency, and cost, Agent observability requires: The inventory of tools available at that decision point
• A trace of model and tool calls, Agent observability requires: The agent's stated reasoning before each call
• The inputs and outputs of each call, Agent observability requires: Side effects on external systems, with reversibility metadata
• Errors and exceptions, Agent observability requires: Which actions were irreversible, and who could intervene
• Aggregate quality and drift metrics, Agent observability requires: A replay path that reruns the same instructions and compares
• What the model said, Agent observability requires: Why the agent acted

The four things agent observability actually requires

Four capabilities separate a record you can audit from a record that only looks like one. Tool-call decisions require their own observability primitives, separate from trace visualization, and here they are.

One: per-tool-call decision context. At each tool call, capture the snapshot of what the agent could see. The data it had read, the state of the systems it was about to act on, the constraints in front of it. Without this you can replay the action and still have no idea what the action was based on. A trace tells you the call happened. It does not tell you the call was reasonable given what the agent knew.

Two: the agent's stated reasoning at the decision point. Capture the agent's own account of why it chose this action, recorded before the action runs. The distinction that matters is timing. Re-prompting the model afterward to ask why it did something is not evidence. It is a fresh generation that may or may not match the original reasoning. The reasoning has to be written down at decision time or it is gone.

Three: side-effect logging with reversibility metadata. Record every external write the agent makes, and mark whether it can be undone and how. An agent that sends an email, issues a refund, or updates a signed contract has done something in a different risk class than an agent that drafted a summary. The log should say which class each action fell into. Most logs treat a reversible database read and an irreversible payment as the same line item. They are not.

Four: replay against the same instructions. Keep the ability to rerun the agent against the same inputs and the same instruction set, and see whether it reaches the same decision. This is the audit primitive most vendors are missing. It is what lets you answer the question a regulator actually asks. The basic log already shows what the agent did. Replay shows whether it would do the same thing again, and the conditions under which it would not. Replay against same instructions is distinct from evaluation, and I will come back to that boundary at the end.

For a concrete version of all four, here is a worked example: a CRM agent and what observing it actually requires, and another worked example of an agent acting through an app.

What good looks like in practice

Good is a set of guarantees you can verify. The NIST AI Risk Management Framework names this plainly. Its Measure function, subcategory MEASURE 2.8, requires that risks associated with transparency and accountability are "examined and documented," and the framework lists "Accountable and Transparent" among the characteristics of trustworthy AI (NIST AI 100-1, nvlpubs.nist.gov). You cannot document a decision you never recorded. That is the test, and it turns into eight questions you can put to any vendor or internal platform team before you ship.

1. At any past decision point, can you show the full context the agent had read before it acted?
2. Can you retrieve the agent's stated reasoning for a specific tool call, captured at the time and not regenerated now?
3. Does the log record every external write, and mark which writes were irreversible?
4. Can you replay a past run against the same instructions and inputs, and compare the result?
5. Is the decision record enforced by the platform by default, or does each agent have to be instrumented by hand?
6. Does the trail cover both the reasoning and the execution, or only the model calls?
7. Can you export the whole record to your SIEM in a format your security team already reads?
8. Are governance metrics available, not just operational ones?

The last question is where most monitoring stops. Latency, cost, and tool-call failure rate are operational metrics. They are necessary and they are not sufficient. The numbers a CISO actually needs are governance metrics: decisions per agent per day, irreversible actions per session, and human-override rate. If your platform reports the first set and not the second, it is measuring the agent as infrastructure rather than as an actor.

Where vendors are getting this wrong today

I want to be fair about this, and fair means applying the same test to each. The four requirements above are the yardstick.

Datadog frames AI observability as an extension of application performance monitoring (see its AI observability post). For traces, latency, and cost across model and tool calls, that lineage is a strength. Measured against the four, it captures decision context partially through traces and stated reasoning only when you have logged it yourself. Reversibility metadata and replay against same instructions are not part of the model. The position being argued against is the framing itself: that observing an agent is monitoring with more spans.

LangSmith, from the LangChain team, treats observability as trace visualization of LLM calls (see its agent observability post). The traces are good and the developer experience is real, with the assumption that you are already building inside LangChain. Against the four, it lands in the same place. Strong on the trace, partial on context, dependent on you to record reasoning, and silent on reversibility and replay. Defining observability as traces of LLM calls is the exact reduction this whole argument is about.

Arize comes from ML observability and extends into agents (see its agent monitoring post). Its metrics framework around accuracy and drift is more mature than most. Measured against the four, it leans heavily on aggregate metrics and lightly on the per-decision audit question. That is the ML-monitoring heritage showing through, and it is a different question than the governance one.

None of these are bad tools. They are good tools for the system they were built to watch, sold into a problem they were not built to solve. The mistake is the category claim, not the engineering.

What we're doing about it at Major

We built Major because we were tired of treating observability as a flag you switch on after the agent already shipped. On Major, agents reason and apps execute. The agent reads context across connectors and decides what needs to happen. Every action it takes then runs as a deterministic app query, with typed inputs, logged at the query layer, with RBAC enforced where the query runs rather than in a UI dropdown. Major is the Agentic OS for AI-Native Enterprises, and that split is the entire point. Reasoning and execution leave one audit trail instead of two that never quite line up.

Because of that design, every agent run captures the four things by default. The tool inventory available at each decision point. The agent's stated reasoning before each call. The inputs and outputs of every action, with reversibility metadata. A replay path against the same instructions. One record across reasoning and execution, exportable to your SIEM in a form your security team already reads.

This runs in production today for customers across security, fintech, and benefits, and Major is SOC 2 Type II, which is the compliance signal a CISO recognizes on sight. We treat the four requirements as the floor we build on rather than a premium tier we charge for. That is the floor, not the ceiling.

If your current agent platform cannot do these four things, you do not have an emergency. You have a procurement conversation worth having next quarter, and now you have the questions to bring to it. The Major answer is one click away if you want to see how Major implements the four requirements.

What this article doesn't cover

This is an argument about observability, not evaluation. Observability tells you what the agent decided and why. It does not tell you whether the decision was correct. "Did the agent do the right thing" is a separate and harder problem, and even a perfect record will sit quietly next to a bad outcome. Observability is a precondition for governing agents, not a substitute for governing them. The evaluation question deserves its own piece, and it will get one.