Why AI agent observability needs a system boundary

The short version: native agent telemetry is better than the old argument assumes

The useful question in 2026 is no longer whether coding agents expose telemetry. Claude Code now exports OpenTelemetry metrics, events, and optional traces for sessions, API requests, tool results, permission decisions, MCP activity, hooks, skills, cost, and token use. Gemini CLI exports logs, metrics, and traces for prompts, API traffic, tools, selected file operations, agent runs, and its own CPU and memory behavior. The current open-source Codex tree contains a dedicated OpenTelemetry crate with session-scoped business events, API timing, metrics, trace-context propagation, and GenAI span fields.

That changes the boundary debate. Native telemetry can describe a great deal of what an agent believes it is doing. The remaining blind spot begins when execution crosses into another process, runtime, script, package manager, MCP server, container, or network client whose low-level behavior is not represented by the parent agent's own events. A system profiler is valuable at that boundary, not because native telemetry is poor, but because the two sources answer different questions.

This review was refreshed on 7 August 2026 against the current Claude Code monitoring reference, Gemini CLI commit cf22ac7e86f3dcf528e3ae591fec1c03090a49f8, Codex commit 3aae5d885bac39c1262491aa3fd100dfd8b3919f, and AgentSight v1.0.3.

A boundary map for coding-agent observability

The table below separates six questions that are often collapsed into the word “observability.” “Native” means telemetry emitted by the agent itself. “System” means activity observed outside the application at the process, file, network, resource, or TLS boundary. The entries deliberately describe the documented scope; they do not imply that one source is universally better.

Claude Code gives us the cleanest proof of where the boundary sits

Anthropic's current monitoring reference is unusually detailed. Claude Code can emit aclaude_code.tool_result event after a tool runs, including the tool name, success state, duration, error category, input and result sizes, and—when detailed tool logging is enabled—parameters such as the Bash command or MCP server/tool name. It separately records tool decisions, API requests, retries, skills, hooks, MCP activity, commits, pull requests, token use, and cost. That is enough for many fleet, cost, adoption, policy, and application-debugging questions.

The same reference also documents a subtle implementation choice that matters for system investigations: Claude Code does not pass its OTEL_* environment variables to Bash subprocesses, hooks, MCP servers, or language servers. If a program launched through Bash should export its own telemetry, the exporter settings must be supplied to that program separately. This is a concrete example of an instrumentation boundary: the parent can record that it launched a command and received a result without automatically turning every child and grandchild operation into the same distributed trace.

Consider npm test. Claude Code can record the Bash invocation and its result. The command can then start Node.js, a test runner, a browser, a compiler, and helper processes; those processes may read thousands of files, touch caches, or contact services. Some of that may be summarized by the tool result, but the parent event is not a syscall-by-syscall or connection-by-connection account of the process family. That distinction is the durable reason to correlate native agent events with process-level observation.

Gemini CLI shows how far application telemetry can extend into files and resources

Gemini CLI's telemetry is an important counterexample to simplistic claims about application tracing. Its documentation lists gemini_cli.file_operation events for file creation, reads, and updates performed by tools, tool-call counters with accept/reject/modify decisions, API request/response events, token metrics, agent-run metrics, and CLI memory/RSS and CPU metrics. With detailed tracing enabled it also emits GenAI-oriented spans for operations such as tool_call, llm_call,agent_call, and schedule_tool_calls.

The exact wording matters: the file events are operations “performed by tools.” This is excellent semantic data because the CLI knows which tool owns the operation. It is still a different statement from “every file opened by every descendant process.” A shell tool can invoke a compiler or package manager whose internal reads happen below the tool implementation. The native event tells you what Gemini intended and instrumented; the system layer tells you which process touched which path when execution escaped that instrumented path.

This also suggests a practical rule for debugging: start with the native trace because it has better semantic labels. Add a system profile when the question mentions an unexplained child process, an unexpected path, a non-model network destination, or resource use that cannot be attributed from the agent's own metrics.

Codex exposes another useful source: the implementation itself

Codex is open source, so its current telemetry surface can be inspected directly rather than inferred from a dashboard. The codex-otel crate wires log, trace, and metric exporters, providesSessionTelemetry for session-scoped business events, and exposes W3C trace-context helpers. The current session telemetry records conversation configuration, API request duration and status, WebSocket and SSE activity, token fields, startup phases, and other business events, while the metrics layer includes API and tool-call counters and duration instruments.

Reading the source is useful for a second reason: telemetry evolves faster than many comparison pages. A static feature checklist ages quickly. For durable analysis, record the exact upstream commit you reviewed and describe the boundary rather than promising that a named event will exist forever. This article pins the Codex review to commit 3aae5d885bac39c1262491aa3fd100dfd8b3919f for that reason.

OpenTelemetry standardizes meaning; it does not create observations by itself

OpenTelemetry's GenAI conventions define portable names for model, conversation, input/output messages, token use, tool names, tool-call arguments, and tool-call results. The CLI conventions similarly define how an instrumented command-line program can represent its execution and exit code. These conventions are highly valuable because Claude, Gemini, Codex, AgentSight, and downstream backends can converge on compatible field meanings.

A semantic convention does not imply that a process was instrumented or that a field came from an independent operating-system source. For example, gen_ai.tool.call.result is the result available to the instrumentation. It is not defined as a proof that the result enumerates every process, file, or network effect produced while the tool ran. This is the most important conceptual distinction in the whole stack: standardizing a record and independently observing an effect solve different problems.

MCP makes the same distinction visible at the protocol layer

The Model Context Protocol defines tools that a model can discover and invoke. A server returns a tool result, and applications are responsible for validation, access control, confirmation, logging, and timeouts. The protocol deliberately leaves the server implementation free to perform the work however it chooses.

That means an MCP transcript can answer “which tool was called with which arguments and what result came back?” while a host-level trace can answer “which executable handled it, which children appeared, which paths were opened, and which destinations were contacted?” For an audit, both are useful. Treating either record as a complete substitute for the other throws away information.

A four-layer model is more useful than “application versus eBPF”

A practical observability model for coding agents has four layers. First is intent and session: prompts, models, skills, subagents, approval policy, and tool selection. Second is tool protocol: the command or MCP invocation and the result returned to the agent. Third is system execution: processes, descendants, file operations, sockets, CPU, memory, and I/O. Fourth is provider traffic: the actual model request and response at the API or TLS boundary. Different products cover different subsets, and modern agent CLIs increasingly cover the first two very well.

AgentSight is most useful when one investigation crosses those layers. Its v1.0.3release combines native/local agent session material with eBPF process and file monitoring, network activity, resource views, and TLS-based model traffic reconstruction. It can export captured model calls as OpenTelemetry GenAI spans. The export has an explicit limitation today: AgentSight does not yet emit standard tool/workflow spans for all of its internal provenance, so the richer system relationships remain in AgentSight's own rows and views. That limitation is important because it prevents the OTel export from being described as a lossless copy of the full AgentSight session.

When should you use native telemetry, a system profiler, or both?

Privacy is also a boundary decision

Richer telemetry can expose sensitive content. Claude Code keeps prompt content out of its OTel events by default and requires an explicit option to include it. Gemini CLI documents separate controls for prompt logging and detailed traces, with full prompt and tool output attributes disabled by default for detailed tracing. OpenTelemetry's GenAI specification itself warns that input messages, system instructions, tool arguments, and tool results may contain sensitive information. AgentSight likewise exports model content only when --otel-capture-content is enabled, while its local session databases can contain prompts, responses, paths, headers, and network targets.

The safest architecture is therefore not “collect everything.” Decide which layer answers the question, keep raw capture local when possible, export the minimum fields needed for shared analysis, and preserve the configuration that determines whether content was recorded. Observability quality and data minimization can be designed together.

The durable conclusion

Coding-agent observability is becoming a multi-source problem. Native telemetry is now rich enough to be the first place to look for model, tool, policy, and session questions. A system profiler becomes valuable when the investigation crosses the application boundary into descendants, files, network destinations, resource use, or closed components. OpenTelemetry provides the common vocabulary that lets the two sources meet; it does not erase the difference in how those observations were produced.

That framing is more useful than claiming one universal tracing layer. It also gives a concrete test for every observability feature: state the question, identify the boundary that can actually observe the answer, and correlate another boundary only when the first one cannot close the causal chain.