Most teams that put a Claude agent into production get burned by the same gap: they can see the final output, but not the reasoning that produced it. A support ticket gets answered wrong, a document gets summarised incorrectly, or an MCP tool call fails silently, and there is no record of what the agent actually decided along the way. Observability for agents is not the same discipline as observability for a normal web service, and treating it that way is the single biggest reason production Claude deployments stall after the pilot stage.
Why agent observability breaks the old playbook
Traditional application monitoring tracks requests, response times and error rates. An agent run is different because the interesting failures happen inside the reasoning, not at the API boundary. A Claude agent might call three tools, reconsider its plan after a bad result, and still return a confident-looking answer that turns out to be wrong. Standard logging tells you the call succeeded. It does not tell you the agent second-guessed itself, picked the wrong tool on the first attempt, or hit a rate limit halfway through a multi-step task and quietly dropped a step. For an Australian business handling client data under the Privacy Act, that gap is not just an engineering annoyance. It becomes a real accountability problem the moment someone asks how a decision was actually made.
The blind spots tend to look the same across clients we work with in Sydney and further afield:
No record of which tools an agent considered before choosing one, so a bad tool choice looks like a mystery after the fact.
Token usage and cost sitting in a single monthly Anthropic Console total, with no way to attribute spend to a specific workflow or client.
Multi-step MCP tool chains where one call fails partway through and the agent quietly continues, producing a plausible but incomplete result.
No link between a user complaint and the specific agent run that caused it, so debugging starts from scratch every time.
Retry loops that succeed on the third attempt and never get flagged, quietly tripling cost on a task that looks fine in the final output.
The five signals worth tracing
A full observability platform is not required to get useful visibility. Five signals cover most of what goes wrong in practice, and all five are available if you capture them at the right layer of the stack.
Prompt and system message versions, so you can tell which version of an agent's instructions produced a given run.
Every tool call and its arguments, including MCP calls, alongside the raw result returned before any post-processing.
Token counts per step, not just per run, so a runaway sub-task shows up before the monthly bill does.
Latency per tool call, which usually points straight at the external API or database that is actually slow.
A final decision trace: what the agent concluded, and which piece of evidence it weighted most heavily to get there.
Building a lightweight tracing stack on Claude
None of this requires a bespoke platform. The Claude Agent SDK exposes hooks around tool calls and message turns, and wiring those into OpenTelemetry spans gives a standard trace format that tools like Grafana, Honeycomb or even a simple Postgres table can consume. For MCP-based workflows specifically, logging the request and response payload for every tool call, with a run ID that ties back to the originating conversation, solves most of the debugging pain teams report in the first month of a live deployment. Anthropic's Console gives useful usage-level cost and token data out of the box, but it stops at the account level. Attributing that spend to a specific client, workflow or agent takes a thin logging layer on top of it, usually a few days of engineering work rather than a new platform purchase.
What good tracing catches before a client does
In one Sydney-based deployment we reviewed, tracing surfaced a tool-selection loop that was retrying a failed CRM lookup four times before falling back to a generic answer. The output looked fine to the end user. The trace showed the agent burning close to four times the expected token budget on every affected query, and the fix took an afternoon once the pattern was visible in the logs.
What this costs in practice
For a small or mid-sized Australian business, a workable tracing setup is not a large project. Budget roughly $3,000 to $6,000 to instrument an existing Claude workflow with OpenTelemetry spans, structured tool-call logging and a basic dashboard. Businesses that skip this step tend to discover the real cost the hard way, through unexplained token spend, client escalations with no audit trail, and rework when a workflow needs to be debugged from scratch because nothing was captured the first time around. One client we worked with was losing an estimated $45,000 a year in wasted token spend from undetected retry loops across three agent workflows, a problem that surfaced within a week of adding step-level token tracing.
Instrumentation and OpenTelemetry setup: roughly $3,000 to $6,000 for an existing single-workflow deployment.
Ongoing dashboard and alerting maintenance: typically $500 to $1,200 a month, depending on trace volume.
Cost of not doing it: commonly $20,000 to $45,000 a year in unattributed token spend and debugging hours, based on the deployments we have reviewed.
Observability is not a nice extra once a Claude agent is handling real client work. It is the difference between fixing a problem in an afternoon and rebuilding trust with a client after a mistake nobody can explain. If your agent workflows are running blind, we run a short session to map the tracing gaps in your current setup and what it would take to close them. Book a session with Automata AI.
