A single LLM call has one main output. An agent has a sequence of decisions. That difference changes what you need to observe, and most observability tooling was designed for the first case.
A model might receive a prompt, generate a response, and finish. An agent might interpret a task, read a file, call a tool, inspect the result, change its plan, call another tool, retry, and only then generate an output. The failure might have happened anywhere in that sequence — usually not where it became visible.
What a single LLM call looks like
The simplified flow is: prompt, context, model, response. If the response is wrong, there are four places to look, and you can look at all of them in about a minute.
What an agent does instead
An agent working on a coding task makes multiple decisions. It might search the repository, read files, run tests, inspect an error, change its approach, modify code, run another command, and retry a failed operation.
Each step depends on the information available at that point — not on the information available at the start, and not on what's visible in the final diff. The diff is the residue of the process, not a record of it.
Where single-call observability breaks down
Consider an agent that calls the wrong tool early in a workflow. It receives an unexpected response, interprets it incorrectly, and makes three more decisions on that basis. By the time the final output looks wrong, the original mistake happened several steps earlier — and nothing in the output points back to it.
There's a second gap specific to agents: the agent's own summary of what it did is not the same thing as what it did. The two can disagree. A trace that records only the agent's narration is recording a claim, not a fact.
What agent observability should capture
- Full tool call sequence, in order
- Tool inputs and outputs, not just names
- Retries and abandoned branches
- The context available at each step
- Agent decisions, including the ones it reversed
- Human intervention points
- Differences between the agent's summary and the system logs
Single call vs agentic system
| Single LLM call | Agentic system |
|---|---|
| One request and response | Multiple decisions |
| Failure usually visible in the output | Failure can happen mid-sequence |
| Prompt + response trace is enough | Full tool call sequence required |
| One main model interaction | Many model and tool interactions |
| Output is the main record | Agent summary may differ from the logs |
Everything the left column needs, the right column also needs — plus the sequence.
Why this matters for coding agents
A coding agent isn't just generating text. It reads source files, runs commands, changes configuration, modifies code, executes tests, and produces a real diff that lands in a real repository.
If the resulting change causes an incident, “an AI wrote this” isn't an answer. You want to know which run, which step, which tool, which context, which decision — and whether anyone was looking at the change before it took effect. The agentic incident postmortem template is built around exactly those fields, because a standard postmortem format quietly assumes you can ask the author what they were thinking.
Record the agent's own summary and the system logs, then compare them. A run where those two accounts diverge is worth more attention than a run where something simply failed.
Observability still isn't prevention
Better observability makes agent failures far easier to understand. It doesn't make the agent make better decisions, and it doesn't stop a risky code change from merging.
That's a separate control. You need one layer to explain what an agent did, and another to determine whether the resulting change is safe enough to ship. Conflating them is how teams end up with excellent traces of incidents they could have prevented. For the broader definition of the first layer, see what AI observability actually means; for how to evaluate the second, the governance buyer's checklist.
Observability tells you what happened after the fact. It doesn't change what the agent does in the moment.
Frequently asked questions
What is observability in AI agents?
Tracking the full sequence of decisions an agent makes — tool calls, retries, and the context available at each step — not just the prompt and the final output, the way single-call observability does.
Is agent observability the same as AI observability?
Agent observability is a subset, specifically the tool-call chains and decision sequences of autonomous agents. AI observability is the broader category, covering any model call, agent-based or not.
Why will AI agents fail?
The same reasons any multi-step automated process fails: a wrong decision early in a chain that compounds before anyone notices. Agents don't need to be unreliable in some special way for this to matter — ordinary compounding error is enough.
Does more observability make agents more reliable?
No. It makes failures traceable, which is different. Observability tells you what happened after the fact. It doesn't change what the agent does in the moment or stop a bad decision before it ships.
Can you trust an agent's own summary of what it did?
Not on its own. The agent's summary of its run and the system logs of that run are two separate records, and they can disagree. Agent observability is partly about being able to check one against the other.
Observability gets you the trace after something happens. Stopping the bad decision before it merges is a separate check — the one Tomosu runs at the merge gate. Book a call →
