The short answer
Native agent telemetry is usually the best first source for model calls, token use, tool selection, permission decisions, prompts, skills, subagents, and other application semantics. Independent system observation is strongest for what actually executed after that decision: process descendants, file and network effects, CPU or memory use, and runtime behavior outside the instrumented agent.
OpenTelemetry can give both sources a common transport and vocabulary, but a semantic convention does not manufacture an observation that was never collected. A gen_ai.tool.call.result field can describe what instrumentation knows about a tool result; it is not proof that every descendant process, path, or connection produced by that tool was represented. That provenance distinction is the reason a system boundary remains useful even as native agent telemetry improves.
Four evidence layers are more useful than “application versus eBPF”
| Layer | What it can answer well | What it does not prove by itself |
|---|---|---|
| Intent and session | Prompt/model context, skills, subagents, approval policy, tool selection, application retries. | The complete low-level behavior of every process or runtime launched afterward. |
| Tool protocol | Command or MCP invocation, arguments, declared tool identity, returned result. | That the result enumerates every child process, file effect, or remote destination. |
| System execution | Processes, descendants, paths, sockets, CPU, memory, I/O, and other host-visible effects. | Why the agent selected the action or what semantic policy caused it. |
| Provider traffic | Actual model request/response timing and wire-visible provider fields when the traffic can be reconstructed. | All local tool behavior before or after the provider call. |
Native coding-agent telemetry now covers a lot of the first two layers
The upstream review behind this page remains pinned to exact sources rather than a generic feature checklist. Claude Code documents OpenTelemetry metrics, events, and optional traces for sessions, API requests, tool results, permission decisions, MCP activity, hooks, skills, cost, and token use. Gemini CLI documents logs, metrics, and traces for prompts, API traffic, tools, selected file operations, agent runs, and its own CPU and memory behavior. The open-source Codex telemetry implementation exposes session-scoped business events, API timing, metrics, trace-context propagation, and GenAI-oriented span fields.
These are strong semantic sources. They are also application-defined sources. For example, a parent agent may record that it launched npm test and received a result. The command can then start Node.js, a test runner, browser workers, compilers, or helper processes whose internal file reads and network activity are not automatically equivalent to the parent tool event. The right question is not whether the native event exists; it is whether that event contains the evidence needed for the current investigation.
Upstream agent facts in this article retain their 7 August 2026 research pins: Gemini CLI commitcf22ac7e86f3dcf528e3ae591fec1c03090a49f8 and Codex commit3aae5d885bac39c1262491aa3fd100dfd8b3919f. The AgentSight-specific sections were revalidated on 3 September against release v1.0.30, commit 934f441e.
What AgentSight v1.0.30 exports to OpenTelemetry—and what stays outside those spans
AgentSight can reconstruct captured LLM request/response pairs and export them as OpenTelemetry GenAI spans over OTLP/HTTP. The current product documentation is precise about the boundary: each pair becomes a chat {model} CLIENT span; request and response timestamps define the wire latency; provider, model, conversation, usage, finish reason, HTTP status, and server address are mapped when available. Prompt and completion content are excluded by default and require--otel-capture-content.
| Evidence | v1.0.30 OTel export | Boundary / limitation |
|---|---|---|
| LLM request/response pair | One GenAI CLIENT span with request/response timing. | Requires a captured pair; streamed bodies that cannot be reparsed still have reduced response detail. |
| Conversation grouping | Real conversation ID when present, then session ID, then current recording as fallback grouping. | Root/child span relationships are not inferred yet. |
| Prompt / completion content | Opt-in only with --otel-capture-content. | Metadata-only is the default because content may be sensitive. |
| Tool/workflow provenance | Not emitted as standard execute_tool, invoke_agent, invoke_workflow, or plan spans today. | Richer AgentSight-specific provenance remains in AgentSight rows and views. |
| Process/file/network/resource relationships | Not a lossless projection of the full AgentSight evidence graph. | Use AgentSight-native evidence when the investigation depends on those system relationships. |
This is a useful architecture rather than a missing-feature embarrassment. OTLP lets the model-call portion join an existing telemetry pipeline without pretending that a standards export preserves every source-specific relationship. The exact observation boundary remains inspectable instead of being hidden behind one blended “trace.”
A concrete example: a slow test command
Suppose the agent emits a native tool event for npm test and that event says the command took 90 seconds. That is enough to attribute wall-clock time to the tool decision. It is not enough to answer why the command took 90 seconds if the delay lives in a browser worker, compiler, network fetch, cache miss, or a child process that the parent tool result summarizes only as final output.
A useful investigation starts with the native event, because it names the tool and preserves agent context. Add a system profile only if the duration remains unexplained. Then correlate the tool interval with the process family, CPU/RSS, file and network activity. If the model call itself is the suspect, provider-traffic or native API telemetry is the better next boundary. The sequence avoids collecting every possible signal when one source already answers the question.
Choose the first source from the question
| Question | Best first source | Add another source when… |
|---|---|---|
| Which model call used the tokens and time? | Native agent / provider telemetry. | You need to connect model time to local execution before or after it. |
| Why did the agent choose this tool? | Native session, policy, skill, and tool-decision records. | You need to verify the effects after the decision. |
| Why was a build/test command slow? | Native tool timing. | The child-process or resource breakdown is missing. |
| Which paths or destinations did an extension actually touch? | System execution evidence plus the native MCP/plugin record. | Either source lacks the semantic or low-level half of the causal chain. |
| How do we feed captured model calls into an existing backend? | AgentSight OTel export or native agent OTel. | The backend also needs AgentSight-specific system provenance that is not projected into GenAI spans. |
Privacy follows the same boundary rule
More telemetry is not automatically better telemetry. Native agent events can contain prompts, tool arguments, results, paths, and identifiers. AgentSight local evidence can contain prompts, responses, paths, headers, and network targets. The v1.0.30 OTel exporter therefore keeps message content off by default. Decide which layer answers the question, export the minimum useful fields, and keep richer raw evidence local when shared analysis does not require it.
Provenance helps here too: knowing whether a field came from the agent, the tool protocol, the host, or reconstructed provider traffic makes it easier to set different retention and sharing policies instead of treating every record as one homogeneous trace payload.
The durable conclusion
Coding-agent observability is a multi-source problem. Native telemetry is increasingly rich and should be the default for questions about intent, model behavior, policy, and tool semantics. System observation becomes useful when execution leaves that instrumented boundary. Provider traffic answers another class of questions. OpenTelemetry gives these systems a shared vocabulary and transport, but it does not erase where an observation came from.
A good observability design therefore starts with one sentence: “What fact am I trying to prove?” Pick the source that can directly observe that fact, and correlate another boundary only when the first source cannot close the causal chain. AgentSight is useful in that design when the missing evidence lives at the machine boundary—or when captured model traffic needs to join an existing OTel pipeline without pretending that the export is a lossless copy of the full system profile.
Primary sources and reproducibility
- Claude Code monitoring and OpenTelemetry reference — native metrics/events/traces, tool records, subprocess behavior, and content controls.
- Gemini CLI telemetry at commit cf22ac7 — file/tool/API events, resource metrics, and GenAI traces.
- Codex OpenTelemetry crate at commit 3aae5d8 — exporter, session-event, metric, and trace-context architecture.
- OpenTelemetry GenAI semantic attributes — standard model, conversation, tool-call, and content fields.
- OpenTelemetry CLI span conventions — execution and exit-code semantics for instrumented CLI programs.
- AgentSight v1.0.30 OpenTelemetry export — exact GenAI mapping, grouping, content opt-in, wire timing, and tool/workflow-span limits.
- AgentSight v1.0.30 README — current system-observation and local-session product scope.
- AgentSight v1.0.30 OTel sink source — OTLP/HTTP exporter implementation behind the documented mapping.
- Model Context Protocol tool specification — protocol-level tool invocation and result semantics.
- AgentSight paper — system-level design and evaluation background.