Observability for Coding Agents: OpenAI Agents SDK vs LangChain vs Google ADK

Your coding agent can pass a demo and still be impossible to debug in production.

When a run edits the wrong file, burns through a retry loop, or silently loses a child-agent span, the useful question is not only “what did the model answer?” It is “what happened across the entire workflow?”

This comparison looks at observability paths in three popular Python stacks:

• OpenAI Agents SDK
• LangChain agents with LangSmith
• Google Agent Development Kit (ADK)

The practical hook: choose the stack that gives your team the right evidence for a failed coding task without leaking repository content or locking every service to one telemetry destination.

Scope and evaluation criteria

This is an official-documentation comparison checked on July 21, 2026. I did not run a shared benchmark, measure export latency, or score the dashboards. Treat the “best fit” guidance as engineering judgment, not a universal ranking.

I compared five things:

1. Default capture: What does one agent run record without custom spans?
2. Control and export: Can you disable, extend, replace, or fan out telemetry?
3. Coding-agent usefulness: Can a trace explain model turns, tool calls, handoffs, and failures?
4. Privacy controls: How explicit is the path for excluding prompts, outputs, or message content?
5. Evaluation loop: How naturally can traces become datasets, feedback, or regression checks?

At a glance

Stack	Default observability path	Strongest debugging signal	Export/control shape	Main trade-off
OpenAI Agents SDK	Built-in traces and spans sent to the OpenAI Traces dashboard	A structured hierarchy for runs, model turns, tools, guardrails, and handoffs	Add processors or replace the default processors; community integrations are listed in the docs	The default backend is OpenAI, and tracing is unavailable for organizations using OpenAI API Zero Data Retention
LangChain + LangSmith	LangChain agents automatically support LangSmith tracing when enabled	Step-by-step agent traces with tools, model interactions, decisions, metadata, and tags	Native tracing plus OpenTelemetry export, alternate OTLP endpoints, and collector fan-out	Requires LangSmith setup for the easiest path; distributed traces can disappear if ancestors are never exported there
Google ADK	Built-in logging, metrics, and traces	Agent workflow telemetry plus events from tools and multi-agent execution	OpenTelemetry is a first-class route; integrations can add analysis and monitoring	You still need to choose a backend and decide how much message content to capture

The table describes documented capabilities, not equal implementations. “Built-in” does not mean identical span names, retention, sampling, or dashboard features.

1. OpenAI Agents SDK: fastest path to a workflow trace

The SDK traces a complete Runner.run() by default. Its documented hierarchy includes task and turn spans, agent spans, model generations, function tools, guardrails, handoffs, and custom spans. That is a good match for a coding agent where the failure may be in the transition between steps rather than in the final text.

A minimal run can therefore answer questions such as:

• Did the agent call the repository search tool before editing?
• Which model turn produced the risky tool arguments?
• Did a handoff send the task to the reviewer agent?
• Did a guardrail run, and where did it sit in the trace?

The SDK also exposes a useful control boundary. Add a custom trace processor to send a second copy elsewhere, or replace the default processors entirely. For long-running workers, the docs call out flush_traces() when you need an immediate delivery guarantee after a unit of work.

The privacy footgun is equally clear: generation and function spans may contain sensitive data, and trace_include_sensitive_data is true by default. A coding-agent team should decide whether prompts, diffs, file contents, and tool arguments belong in the trace before enabling this in a repository with secrets or customer data.

Choose this path when: you are already using the OpenAI Agents SDK, want rich workflow structure with little instrumentation code, and accept OpenAI Traces or are prepared to install a custom processor.

2. LangChain + LangSmith: the most complete trace-to-evaluation workflow

LangChain’s current agent docs say agents built with create_agent automatically support LangSmith tracing. Enabling it is primarily configuration: set LANGSMITH_TRACING=true and provide an API key. The resulting traces cover the input-to-output path, including tools, model interactions, and decision points. Tags and metadata can be attached per invocation, which is especially useful for coding-agent slices such as repository, branch, model route, or task type.

The differentiator is not merely “it has traces.” LangSmith’s observability docs connect traces to debugging, evaluation, monitoring, feedback, and datasets. That makes it a natural fit for a team asking:

• Which tool-error pattern is recurring across repositories?
• Did a prompt or model change increase failed patch attempts?
• Can production traces seed a regression set before the next harness change?

It also has a vendor-neutral route. LangSmith documents OpenTelemetry tracing for LangChain and non-LangChain applications, including collector fan-out to multiple destinations. That is useful when your coding agent spans an API service, a sandbox worker, and a separate test runner.

There is a subtle distributed-tracing limitation worth testing: the docs state that a span whose parent is never sent to LangSmith is dropped. A successful OTLP response from the collector is not proof that the complete trace will appear as one connected run. Export the ancestors you need, or make the loss mode visible in your own checks.

Choose this path when: trace search, metadata, human feedback, evaluation, and production monitoring are part of the same improvement loop, or when you need OpenTelemetry fan-out.

3. Google ADK: telemetry as a framework capability, backend as a choice

Google ADK’s observability documentation treats logging, metrics, and traces as built-in capabilities rather than an afterthought. Its examples show OpenTelemetry for traces and a logging plugin for detailed output. The docs also warn that basic input/output monitoring is insufficient for complex agents because debugging needs visibility into reasoning traces, tool calls, and other internal activity represented in telemetry.

That model fits multi-agent coding workflows where the orchestration graph matters: a planner may delegate to a code-search agent, which invokes tools, which triggers a test runner. You want to correlate those events with service-level metrics, not only inspect the final response.

ADK leaves more backend choice to you. The official quick start configures an OTLP exporter, and the docs point to observability integrations for additional monitoring and analysis. This can be an advantage for teams that already run an OpenTelemetry Collector, but it is also setup work: you must choose the exporter, backend, retention policy, and content-capture policy.

The privacy control is explicit in the docs’ Kotlin example: capturing full message content is configurable and should be used with caution in production. The same operational rule applies to a coding agent in any language: structured metadata such as repository ID, task ID, model name, and exit status is often safer than storing full prompts, diffs, or tool payloads.

Choose this path when: you want framework-level logging, metrics, and traces, run multi-agent workflows, and already have an OpenTelemetry-oriented platform team.

A practical coding-agent trace contract

Whichever framework you choose, define a small contract before adding every possible payload to telemetry:

task_id: task_2026_07_21_0042
repo: payments-api
base_revision: abc123
agent: implementer
model: router-selected
tool: run_tests
side_effect: read-only
outcome: failed
error_class: test_failure
duration_ms: 1840

Store the full diff, command output, and prompt only where your security policy allows it. Keep the trace useful even when content capture is disabled. A task ID and stable error class are often enough to join a redacted trace to an internal artifact store.

This complements, rather than replaces, a regression strategy. A trace shows what happened; an evaluation or replay check decides whether the behavior is acceptable. For a concrete workflow, see Stop Replaying Coding-Agent Bugs by Hand: Turn Traces Into Regression Tests.

Decision checklist

Pick OpenAI Agents SDK if:

• You want detailed agent-native spans immediately.
• Your team is comfortable with OpenAI’s tracing destination or custom processors.
• The agent’s main complexity is handoffs, guardrails, and tool execution.

Pick LangChain + LangSmith if:

• You need traces connected to feedback, datasets, evaluations, and monitoring.
• You want tags and metadata for slicing coding tasks.
• You need documented OpenTelemetry export or multi-destination fan-out.

Pick Google ADK if:

• You want logging, metrics, and traces as part of an ADK workflow.
• You operate a multi-agent system and already have an OTLP backend or collector.
• Backend portability matters more than a zero-setup hosted dashboard.

If your agent performs side effects, pair observability with explicit error classification and retry policy. A trace can reveal that a tool failed, but it should not silently turn a non-idempotent write into a retry. Tool Errors Are Not Retries covers that boundary.

What to do now

1. Pick one representative coding task: a failing test plus a small patch is enough.
2. Run it with content capture disabled first.
3. Verify that the trace still records agent, model, tool, handoff, duration, status, and task ID.
4. Export one trace to the backend your team actually operates.
5. Intentionally fail a tool and confirm the failure is visible without exposing secrets.
6. Promote the trace to a regression case only after you can state the expected outcome.

Candid limitations

This is a documentation-based comparison, not a common benchmark. I did not measure dashboard query speed, export overhead, retention, pricing, or trace completeness under process crashes. Framework versions and integrations change quickly. OpenTelemetry compatibility also does not guarantee identical semantics across backends: span names, attributes, sampling, and redaction behavior still need a small integration test.

The right observability stack is the one your team will actually inspect during a failed run and can operate within its data-retention and security constraints.

Sources

• OpenAI Agents SDK tracing
• LangChain observability
• LangSmith OpenTelemetry tracing
• Google ADK observability
• OpenTelemetry GenAI semantic conventions

What is the first field or event you would refuse to omit from a coding-agent trace, and why?