OpenTelemetry defines how telemetry is produced and named
OpenTelemetry provides APIs, SDKs, instrumentation, collectors, exporters, resources, and semantic conventions across traces, metrics, logs, and profiles. Semantic conventions standardize field names and meaning; they do not create an observation in code that was never instrumented. That distinction is important when an agent launches descendants whose behavior is not represented by the parent application trace.
AgentSight is a data source with its own capture boundary
AgentSight collects a local run through eBPF, runtime/TLS attachment, and agent-session parsing. Its saved session can contain process, file, network, resource, and reconstructed model-call information that does not originate from an OpenTelemetry SDK inside the agent. This is why AgentSight can work with some closed-source CLIs without asking them to link an OTel library.
The current OTel export is intentionally narrower than the full AgentSight session
AgentSight v1.0.3 can export captured LLM request/response pairs as GenAI-style spans over OTLP/HTTP. The exporter maps provider, model, conversation identifiers when available, token usage, finish reasons, HTTP status, and server address. Prompt/completion content is opt-in. The same documentation states that tool/workflow spans such as execute_tool or invoke_agent are not emitted yet, and AgentSight-specific provenance remains in AgentSight rows.
Correlation should preserve source provenance
If a model request is exported to your OTel backend, keep enough metadata to know that the span came from AgentSight capture rather than native SDK instrumentation. Native agent traces may have richer tool or policy semantics; AgentSight may have richer process/file/network context. A shared backend can display both while still preserving which measurement mechanism produced each field.
Privacy settings differ by measurement source
AgentSight content export is off by default for its OTel path because model payloads can be sensitive. Native agent OTel exporters have their own content and redaction controls. Treat the collector as a new data boundary: exporting a local run to a remote backend changes the storage and access model even if the same fields were originally captured locally.
Use OTel to connect tools, not to erase their differences
Choose OpenTelemetry when you need interoperable transport, naming, collection, and backend integration. Choose AgentSight when you need the local system and closed-component measurements it can provide. The strongest combination is AgentSight feeding selected standard spans into the same OTel environment while the full local session remains available for deeper process-level analysis.