Verdict
Instrument at the boundary with OTel GenAI and treat backends as swappable sinks - unless you need a vendor's eval-and-annotation workflow deeply enough to accept re-instrumentation risk. The honest state of the standard as of July 2026: the gen_ai.* conventions are still marked Development/Experimental (the GenAI README in open-telemetry/semantic-conventions states 'Status: Development'), and in 2026 the conventions moved into a dedicated open-telemetry/semantic-conventions-genai repository - an org split that signals investment, not a 1.0. That experimental status is survivable because the core attributes are already ingested nearly everywhere: Datadog LLM Observability consumes gen_ai.* natively (since OTel semconv v1.37-era support), Langfuse exposes an OTLP endpoint at /api/public/otel, Arize Phoenix translates GenAI spans into OpenInference, and LangSmith's OpenTelemetry endpoint maps gen_ai.* attributes into its run model per docs.langchain.com. The best-of-both answer for many teams is a third option: an OTLP-native open-source backend like Langfuse, which gives you vendor features without vendor instrumentation. What you accept in exchange is churn - gen_ai.system was renamed to gen_ai.provider.name, prompt_tokens/completion_tokens became input_tokens/output_tokens, and gen_ai.prompt/gen_ai.completion are deprecated in favor of gen_ai.input.messages/gen_ai.output.messages - so pin your semconv version and gate upgrades.
The decision hinges on two facts most 2025-era content gets wrong. First, stability: the conventions did not stabilize - the OpenTelemetry docs page (opentelemetry.io/docs/specs/semconv/gen-ai) now redirects readers to the dedicated GenAI repo, the main-repo GenAI README says 'Status: Development', and instrumentations use the OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental environment flag to opt into the latest experimental attribute shapes rather than a frozen default. The timeline is precise: the main repo's v1.42.0 release (June 12, 2026) deprecated and moved all gen_ai.* content into the dedicated GenAI repo, and the main conventions have since moved on to v1.43.0 (July 3, 2026) - the split versioning itself tells you this surface is still moving. Second, ingestion is broader than the experimental label suggests: the attributes that survive across essentially every backend are the small stable core - gen_ai.operation.name, gen_ai.provider.name (né gen_ai.system), gen_ai.request.model, gen_ai.response.model, gen_ai.usage.input_tokens/output_tokens, and the gen_ai.tool.* set for agent tool spans - as documented across the OTel registry, MLflow's semconv mapping docs, and LangSmith's OTel ingestion table. Vendor SDKs are genuinely richer today (sessions, user feedback, eval scores, prompt playgrounds attached to traces), which is why this is a real decision and not a lecture: OpenLLMetry (Traceloop) demonstrates the middle path by emitting standard gen_ai.* spans from a convenience SDK, and Langfuse demonstrates the backend-side middle path by accepting pure OTLP. The cost of the vendor path is concrete: LangSmith's @traceable, Braintrust's loggers, and Langfuse's decorators each encode their backend's schema, so switching backends later means re-instrumenting every service rather than repointing an OTLP exporter.
Decision Table
| Criterion | Edge | Explanation |
|---|---|---|
| Portability and backend switching | OpenTelemetry GenAI semantic conventions (gen_ai.* spans over OTLP) Best edge | This is the whole point of the standard, and it works today: the same gen_ai.* OTLP stream can land in Datadog (native gen_ai.* consumption), Langfuse (/api/public/otel OTLP endpoint - HTTP, not gRPC), Arize Phoenix (translated to OpenInference internally), and LangSmith (documented attribute mapping at docs.langchain.com/langsmith/trace-with-opentelemetry). Switching backends is an exporter config change plus attribute-mapping review. With a vendor SDK, switching means touching every instrumented call site - re-instrumenting, remapping attributes, and re-plumbing payload redaction, which in practice means it doesn't happen. |
| Capability richness today | Vendor tracing SDKs (LangSmith @traceable, Langfuse decorators, Braintrust, Datadog LLM Observability SDK) Best edge | Vendor SDKs are honestly ahead on product surface: LangSmith attaches datasets, human feedback, and eval runs to traces; Langfuse's SDK adds sessions, scores, and prompt management; Braintrust ties traces to its eval loops; Datadog's LLM Observability SDK links traces into monitors, dashboards, and cost views out of the box. Raw gen_ai.* spans give you spans - the workflow layer on top (annotation queues, regression sets, judge scoring) is exactly what the standard does not specify. If your team lives in those workflows daily, the SDK's ergonomics are worth real money. |
| Schema stability and upgrade churn | Vendor tracing SDKs (LangSmith @traceable, Langfuse decorators, Braintrust, Datadog LLM Observability SDK) Best edge | The experimental label is not decorative. Within the conventions' short life, gen_ai.system became gen_ai.provider.name, gen_ai.usage.prompt_tokens/completion_tokens became input_tokens/output_tokens, and flat gen_ai.prompt/gen_ai.completion attributes were deprecated for structured gen_ai.input.messages/gen_ai.output.messages (OTel registry; LangSmith's ingestion docs still map the older gen_ai.system spelling, which shows the transition mid-flight). Instrumentations hide this behind OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental, but dashboards and alerts keyed to renamed attributes silently break on upgrade. A vendor SDK absorbs this churn for you - schema migrations are the vendor's problem. If you go OTel, pin the semconv version in code and treat semconv upgrades like API version bumps with a dashboard audit. |
| Multi-backend and multi-team consistency | OpenTelemetry GenAI semantic conventions (gen_ai.* spans over OTLP) Best edge | Once two backends are in play - say Datadog for the platform team's SLOs and a specialized LLM tool for the AI team - the standard wins decisively: one instrumentation feeds both through an OTel Collector, with sampling, redaction, and routing centralized in collector config instead of duplicated per-SDK. This is also the answer to org sprawl: gen_ai.* is vocabulary any team can emit from any language with stock OTel SDKs, rather than each team adopting whichever vendor SDK its favorite framework integrates. |
| Best of both worlds: open-source OTLP-native backends | Tie | A third party wins this row: Langfuse (and Phoenix in the same spirit) collapses the tradeoff by being a feature-rich backend that ingests standard OTLP directly - self-hostable, maps gen_ai.* onto its trace model, and adds sessions, evals, and prompt management server-side rather than SDK-side. You keep portable instrumentation and still get a product. The limitation to check before committing: Langfuse's OTLP endpoint is HTTP-only (no gRPC), and property mapping from experimental attribute versions can lag renames - the same churn risk as any gen_ai.* consumer. |
| Time-to-value for a small single-backend team | Vendor tracing SDKs (LangSmith @traceable, Langfuse decorators, Braintrust, Datadog LLM Observability SDK) Best edge | If you are three engineers shipping one Python service and you already chose your backend, the vendor SDK is an afternoon: decorator on the agent entrypoint, API key, done - traces, costs, and evals appear. Getting equivalent depth from raw OTel means picking instrumentation libraries (OpenLLMetry or per-framework), wiring an exporter or collector, and accepting that agent-graph semantics beyond gen_ai.tool.* spans are still thin in the spec. The standard pays off at portfolio scale and over time; the SDK pays off this sprint. |
Choose OpenTelemetry GenAI semantic conventions (gen_ai.* spans over OTLP) if...
- Platform teams standardizing tracing vocabulary across multiple services, languages, and teams with stock OTel SDKs.
- Anyone shipping to two or more backends - Datadog for ops plus a specialized LLM tool for the AI team - from one instrumentation via a collector.
- Teams with data-residency or redaction requirements that belong in a self-managed OTel Collector, not in each vendor SDK's config.
- Builders hedging vendor risk: repointing an OTLP exporter is a config change; unwinding a decorator SDK from every call site is a migration project.
Choose Vendor tracing SDKs (LangSmith @traceable, Langfuse decorators, Braintrust, Datadog LLM Observability SDK) if...
- Small single-backend teams that want traces, costs, and evals working this afternoon with a decorator and an API key.
- Teams whose core workflow is the vendor's product - annotation queues, regression datasets, judge-scored experiments attached to production traces.
- Datadog shops that want LLM traces joined to existing APM, monitors, and cost dashboards with first-party support.
- Workloads needing rich agent-graph semantics today (nested chains, retrieval hops, framework-aware spans) that the experimental gen_ai.* spec still models thinly.
Decision rules
- 01If you run (or will run) more than one observability backend, emit gen_ai.* over OTLP through a collector - one instrumentation, N sinks, and sampling/redaction centralized. This is the strongest single argument for the standard.
- 02If your team's daily workflow is a vendor's eval-and-annotation product (LangSmith datasets, Braintrust experiments), adopt their SDK consciously and budget the future re-instrumentation cost as the price of today's workflow.
- 03If you want vendor features without vendor instrumentation, put an OTLP-native backend like Langfuse (self-hosted or cloud) behind standard gen_ai.* spans - the third option that wins for most small platform teams.
- 04Whatever you emit, pin your semconv version and audit dashboards on upgrade: gen_ai.system → gen_ai.provider.name and prompt_tokens → input_tokens style renames are exactly what 'Status: Development' means in practice.
- 05Check your backend's ingestion docs against the attribute version you emit - LangSmith documents mappings for older spellings like gen_ai.system while the registry has moved on, and mismatches surface as silently empty fields, not errors.
- 06Emit the stable core everywhere (operation.name, provider.name, request/response.model, usage.input_tokens/output_tokens, gen_ai.tool.*) and treat everything beyond it as backend-specific enrichment you can afford to lose in a migration.
Migration Notes
- Vendor SDK → OTel: start at the boundary, not the leaves - wrap the model-call layer (or adopt OpenLLMetry, which emits standard gen_ai.* spans) so new spans are portable while legacy decorator spans age out service by service.
- OTel → vendor SDK is the cheap direction: every major vendor ingests OTLP (Langfuse /api/public/otel, LangSmith's OTel endpoint, Datadog natively), so you can adopt a vendor's backend and product without abandoning portable instrumentation - often you never need their SDK at all.
- Budget for the renames: any migration or upgrade crossing semconv versions must map gen_ai.system → gen_ai.provider.name, prompt_tokens/completion_tokens → input_tokens/output_tokens, and gen_ai.prompt/completion → gen_ai.input.messages/output.messages, and re-point every dashboard and alert keyed on the old names.
- Keep payload capture policy (prompts and completions in span attributes vs redacted) in collector/processor config rather than sprinkled through app code - it is the part auditors ask about and the part that must survive a backend switch intact.