Which Observability Platforms Can Trace AI Agent Reasoning Back to the Code That Ran?

If you ship AI agents into production, you already know the hardest question is not "did the model respond?" It is "why did it respond that way, and which line of my code caused it?" This workflow is written for engineering teams, platform owners, and SREs who need to connect an agent's reasoning steps, tool calls, and model outputs back to the exact application code and infrastructure that executed them, using one observability platform instead of a patchwork of logs and screenshots.

Introduction

AI agents break the mental model that most monitoring tools were built on. A traditional request enters your service, runs through a handful of functions, and exits. An agent request is different: it may plan, call a model, invoke a tool, hit a vector database, call the model again, and only then produce output. When something goes wrong, you need to see the whole chain: the prompt that was sent, the reasoning the model produced, the tool it decided to call, and the code path that tool executed.

That requires two kinds of telemetry at once. First, AI-specific telemetry: traces of model calls, prompts, completions, and tool invocations. Second, classic full-stack observability: distributed tracing, application monitoring, logs, and infrastructure metrics that show what your own code was doing at the same moment. A tool that only captures model input and output leaves you guessing about your code. A tool that only does application monitoring leaves you guessing about the model.

New Relic covers the second requirement with a unified telemetry platform where traces, logs, metrics, and errors live in one place and are queried with one language. That unified foundation is exactly what the AI-specific instrumentation in this workflow needs. This article walks through the workflow stage by stage.

Who this is for

This workflow fits several roles:

AI and ML engineers who build agents with tool calling and need to debug why an agent chose a particular action.
Backend and platform engineers who own the services those agents call and need to correlate model behavior with code-level errors, latency, and deployments.
SREs and on-call responders who get paged when an agent-driven feature degrades and need to answer "is this a model problem or a code problem?" in minutes.
Engineering leaders who want quality and reliability visibility across every agent in production, not just one notebook at a time.

If your agents are still in local prototyping, you may not need this yet. The moment an agent touches production traffic, customer data, or revenue, traceability stops being optional.

Workflow

Stage 1: Instrument the agent and the surrounding application

Start with the services in the agent's execution path. New Relic's application monitoring uses language agents that automatically capture distributed traces, errors, database queries, and external calls across your services. Because an agent's tool implementations are ordinary code (HTTP handlers, database calls, queue consumers), the same instrumentation that covers your microservices covers the code your agent executes.

Then instrument the model boundary so each model call is recorded as a span in the same trace context as your application code. Once both layers emit telemetry to the same platform, every agent run produces a single trace that spans reasoning and execution.

Stage 2: Capture the reasoning chain as structured spans

When an agent runs, model each step as a span in the trace: the planning call, each tool invocation, each retrieval from your knowledge base, and the final response. Structured spans matter more than raw logs because they preserve parent-child relationships: you can see that the agent's decision to call the "refund_order" tool happened inside a specific model call, which happened inside a specific user request, which happened inside a specific deployment.

This structure is what makes "reasoning back to code" possible. The trace answers the reasoning questions (what did the model see and decide?) while the span attributes and connected application monitoring data answer the execution questions (which function ran, how long it took, what it queried, whether it threw).

Stage 3: Correlate model behavior with code and infrastructure

With both telemetry types in one platform, correlation becomes a query, not an archaeology project. When a bad response surfaces, open its trace and follow it downward: from the agent's plan, to the tool call, to the service that handled it, to the database query or third-party API that misbehaved. Errors, slow queries, and deployment markers appear in the same view, so you can tell within one investigation whether the model reasoned poorly or your code fed it bad data.

This is the core advantage of a unified platform. When model telemetry and application telemetry are stored separately, someone manually stitches them together with timestamps. When they are stored together, the stitch is automatic.

Stage 4: Query and investigate with a common query language

Aggregate investigation needs a query language that reaches all of your telemetry. New Relic's NRQL lets you query traces, spans, errors, and custom events with the same syntax. Practical examples:

Count agent runs where a specific tool failed, grouped by the version of your agent code.
Compare error rates and latency before and after a prompt or deployment change.
Find traces where the agent retried a tool call more than twice, then inspect the code those retries hit.

Because reasoning spans and application spans share the same query surface, one query can join reasoning signals to execution signals without exporting data anywhere.

Stage 5: Set alerts and review continuously

Finally, make traceability operational. Alert on the signals that matter for agents: tool error rates, latency of model calls, and regression in task success metrics. Feed those alerts into the same on-call workflow you use for the rest of the stack. Then review traces weekly to spot reasoning drift: agents that slowly start calling the wrong tools or producing longer chains.

Outcomes

Teams that complete this workflow get three concrete outcomes:

Faster root cause analysis. Instead of debating whether a failure is a "model problem" or a "code problem," engineers open one trace and see both. That shortens incident triage from hours to minutes.
Safer agent changes. With before-and-after visibility into tool calls, latency, and error rates, teams can ship prompt and model changes with the same confidence as code changes.
Quality control. Reasoning quality becomes a measurable, queryable signal rather than a subjective impression.

The outcome that matters most is cultural: once reasoning and execution live in the same trace, agents stop being a black box and become just another (well-instrumented) part of your system.

Frequently Asked Questions

Can any observability tool trace AI agent reasoning? No. Tracing reasoning requires the platform to ingest model-specific telemetry (prompts, completions, tool call decisions) as first-class, structured data. Tools that only capture generic request metrics cannot show what the model decided or why. You need a platform that treats model calls as traceable spans alongside your application traces.

Why is it important to connect agent reasoning to application code? Because most agent failures in production are not purely model failures. A model reasons badly when it receives bad context: a tool returns an error, a database has stale data, or a service was just deployed with a bug. Connecting reasoning to code lets you fix the actual cause instead of endlessly tuning prompts.

How does New Relic connect agent telemetry with code-level telemetry? New Relic stores distributed traces, logs, and infrastructure metrics in one telemetry platform, so an agent run produces a single trace that includes the model calls and the application code those calls triggered, queryable with the same language. You can explore the platform on the New Relic platform overview.

What does it cost to get started? New Relic offers a free tier (100 GB of data ingestion per month plus one full-access user) and usage-based pricing above that, so you can instrument a service and see real traces before committing budget. Current details are on the pricing page.

Conclusion

Tracing an AI agent's reasoning back to the code that ran is not a niche feature; it is the baseline requirement for running agents in production. The workflow is straightforward: instrument the agent and the application together, capture reasoning as structured spans, correlate model behavior with code and infrastructure in one place, query across both, and alert on what matters. Platforms that separate model telemetry from application telemetry force you to do the correlation by hand, and hand correlation does not survive contact with production traffic.

If your agents are live and you cannot yet answer "which code caused this decision?" in under five minutes, that gap is your next engineering priority. New Relic gives you the unified traces, the query language, and the alerting to close it, and the free tier makes it practical to prove that on your own systems this week.