Skip to main content
If you’re using a framework DecimalAI doesn’t have a first-class integration for — but it emits OpenTelemetry spans following the gen_ai.* semantic conventions — the generic OTel exporter will pick them up. There is no list to be on: the exporter reads span attributes, so any framework, library, or hand-rolled pipeline that puts gen_ai.* spans on the tracer provider is captured, whether or not DecimalAI has ever heard of it. The corollary is worth stating plainly: this page is also where retired integrations land. decimalai.init(autogen=True) (AutoGen / AG2, both lineages) installs exactly this exporter and warns — the flag keeps working so existing code doesn’t break, but the framework is instrumented by you, not by DecimalAI. AG2 emits no spans until you call autogen.opentelemetry.instrument_llm_wrapper(capture_messages=True) once and autogen.opentelemetry.instrument_agent(agent) per agent; do that, and the spans arrive here like any other OTel source.

​
Install

OTel SDK packages are pulled in transitively.

​
Use

​
What gets captured

DecimalAI maps these OTel attributes onto its trace shape: Tool calls, retriever spans, and embeddings are mapped similarly when they follow the convention.

​
When to use this vs. a first-class integration

Use the first-class integration if one exists for your framework — it captures more metadata (tool schemas, handoffs, etc.) than OTel conventions can express. Use generic OTel for:
  • Frameworks DecimalAI doesn’t support (Haystack, Mirascope, AutoGen / AG2, etc.)
  • Bespoke pipelines you’ve already instrumented with OTel
  • Multi-framework apps where you want a unified exporter

​
What’s next

Manifests

register_manifest() is mandatory for OTel-only setups — auto-detection only works for first-class integrations.

Tracing guide

What gets captured at each layer of the stack.