Skip to main content
Already instrumented with OpenTelemetry? Point any OTel SDK, auto-instrumentation library, or Collector otlphttpexporter straight at the engine - no AgentX SDK needed:

​
Wire formats

​
Attribute conventions

Each incoming span becomes one trace row, with input/output/model/token counts pulled from whichever convention the instrumentation actually sends: Monitor runs against every OTel-ingested span by default; set AGENTX_OTEL_MONITOR=false to turn that off.

​
First-class citizenship

Three attributes make OTel traffic part of the full loop, not just rows in Live Traces:
  • Sessions - set session.id, gen_ai.conversation.id, or agentx.session_id and traces group into conversations on the Sessions surface, with session judging applying exactly like SDK traffic. Without one, spans still group by OTel trace id.
  • Prompt identity - set agentx.prompt_name (and optionally agentx.version) and the whole Improve loop lights up: prompt-registry evidence gathering and version comparison treat the trace as if the SDK had tagged it.
  • Tool calls - a child span carrying gen_ai.tool.name (or an MLflow TOOL-typed span) is folded up into its root interaction’s tool_calls, with success/error derived from span status - so Tool quality, the built-in Tool-failure check, and Tool Schema evidence all work on OTel traffic. In-batch only: a parent exported in an earlier OTLP batch isn’t updated retroactively.

​
Verify it’s flowing

Send one span, then check Observe → Live Traces - OTel spans arrive with their full span tree (Timeline and Graph views) whenever the instrumentation emits parent/child links.
Popular auto-instrumentation packages (openinference-instrumentation-langchain, OpenLLMetry’s SDK, MLflow Tracing) all export full span trees - one env var and your existing instrumentation becomes AgentX’s data source.