Tracking: migrate OpenInference Python instrumentations into this repo

[lmolkova]

This issue tracks porting the OpenInference Python instrumentation packages into
opentelemetry-python-genai, so that GenAI instrumentation is built on the shared
opentelemetry-util-genai utilities and emits telemetry that conforms to the
GenAI semantic conventions.

Important

• Use the instrumentations from https://github.com/open-telemetry/donation-openinference/ as the source
  (once seeded). DO NOT use https://github.com/Arize-ai/openinference/.

• Before starting work on a specific library, please ask to be assigned in the table —
  for example, by leaving a comment on this issue.

• Prioritize packages with more downloads and the ones your organization is interested in.

• Make sure to link this issue from the migration PRs.

Candidate packages (ordered by recent PyPI downloads):

OI package	Downloads last month	Assignee	Status and link(s) to PR	Notes
openinference-instrumentation-langchain	2,303,629	@wrisa @keith-decker @lzchen		Existing package: opentelemetry-instrumentation-genai-langchain
openinference-instrumentation-openai	1,988,421	@eternalcuriouslearner		Existing package: opentelemetry-instrumentation-genai-openai
openinference-instrumentation-pydantic-ai	777,820			Native instrumentation — won't port. See Pydantic AI OpenTelemetry/Logfire docs
openinference-instrumentation-anthropic	715,867	@eternalcuriouslearner		Existing package: opentelemetry-instrumentation-genai-anthropic
openinference-instrumentation-claude-agent-sdk	625,120			Existing package: opentelemetry-instrumentation-genai-claude-agent-sdk
openinference-instrumentation-openai-agents	576,006	@eternalcuriouslearner	Blocked on #90	Existing package: opentelemetry-instrumentation-genai-openai-agents
openinference-instrumentation-google-adk	572,630			Native instrumentation — won't port. See ADK Cloud Trace / OpenTelemetry docs
openinference-instrumentation-agno	505,207
openinference-instrumentation-litellm	504,172
openinference-instrumentation-google-genai	472,235	@DylanRussell		Existing package: opentelemetry-instrumentation-google-genai
openinference-instrumentation-crewai	415,635
openinference-instrumentation-llama-index	413,031
openinference-instrumentation-haystack	393,875
openinference-instrumentation-bedrock	350,897
openinference-instrumentation-instructor	130,202
openinference-instrumentation-mistralai	120,700
openinference-instrumentation-dspy	119,851
openinference-instrumentation-groq	117,114
openinference-instrumentation-vertexai	114,965			Won't add — the library is deprecated
openinference-instrumentation-smolagents	114,073
openinference-instrumentation-mcp	83,845			Native instrumentation — won't port. See modelcontextprotocol/python-sdk#2381
openinference-instrumentation-portkey	33,488
openinference-instrumentation-autogen	13,098
openinference-instrumentation-beeai	12,368
openinference-instrumentation-strands-agents	10,318
openinference-instrumentation-agent-framework	7,385
openinference-instrumentation-autogen-agentchat	3,831
openinference-instrumentation-guardrails	3,390
openinference-instrumentation-pipecat	1,419
openinference-instrumentation-agentspec	690

Migration guidance

• Build on opentelemetry-util-genai. Avoid emitting spans, metrics, or events directly — use the
  shared utilities so all packages produce consistent, conformant telemetry, share the same configuration
  options and extensibility hooks, and to reduce maintenance toil.
• Do use AI to help with the port and the review. Minimize use of AI when talking to humans.
• Use the provided migration and review skills (to be added in Add skills to help with instrumentation migration #143) to drive the port consistently.
• Contribute back to the migration skills so the workflow improves as we go.
• If migration needs a design decision or some discussion, create individual issues for these
• Keep the PR scoped to the migration only. Do not instrument new operations and do not
  add new features beyond what the source instrumentation already does. Adding missing tests
  for the migrated behavior is encouraged.

Naming

• Package names follow the opentelemetry-instrumentation-genai-{lib} pattern, where {lib} is
  the PyPI name of the instrumented library — e.g. crewai →
  opentelemetry-instrumentation-genai-crewai, importing as
  opentelemetry.instrumentation.genai.crewai. This MAY be different from the suffix used by OpenInference.

Version support

• Consider supporting only the latest major version of the instrumented library and dropping
  compatibility with older versions, to reduce maintenance toil.

Existing packages

• For libraries that already have a package in this repo (marked "Existing package" above), do
  not re-port from scratch. Instead, analyze the delta between the OpenInference
  instrumentation and the existing code — operations covered, scenarios, attributes, captured
  content — and contribute only what's missing or improved back into the existing package.
  Do not modify existing code. If refactoring is helpful, do it as a follow-up to the migration PR.

Semantic conventions

• When there is no convention for a specific operation or scenario, file a bug in
  open-telemetry/semantic-conventions-genai
  to get it specified.
• In the meantime, report an empty span where appropriate (e.g. an operation span without
  speculative attributes). Do not report unconventional / non-spec attributes.
  Leave TODOs in the code pointing to the semconv issue.

Tests

• Add conformance tests for the important scenarios of each library:
  • LLM clients: inference + tool calling + reasoning + multi-modal content, embeddings.
  • Agents: invoke_agent + tools, workflows, orchestration.
• Add missing unit test coverage for the instrumentation logic (if anything is missing).

[DylanRussell]

I can check out openinference-instrumentation-google-genai

[eternalcuriouslearner]

I can check out the following instrumentations:

openinference-instrumentation-openai-agents
openinference-instrumentation-openai-agents
openinference-instrumentation-openai
openinference-instrumentation-anthropic

[DylanRussell]

is the idea with the donation that the arize people will no longer maintain their version of these instrumentations, and we will eventually take them over ? do we have to have like feature parity with them ? The spans they emit look very different so it'll be pretty much impossible to have complete compatibility, but they are doing various things we don't do but we could do.. like looking for random variables in the context that the user can optionally set and get them propagated into the span (https://github.com/open-telemetry/donation-openinference/blob/main/python/openinference-instrumentation/src/openinference/instrumentation/context_attributes.py#L214-L256 ).. lots of little random stuff like that which we could possibly add

[DylanRussell]

Alright I've looked over openinference-instrumentation-google-genai:

• They monkey patch a whole bunch of methods that our instrumentation doesn’t (we only instrument the generate_content methods: https://github.com/open-telemetry/donation-openinference/blob/main/python/instrumentation/openinference-instrumentation-google-genai/src/openinference/instrumentation/google_genai/__init__.py#L22-L38

• Our own generate_content instrumentation in general is much more complete // in-line with the otel semantic conventions

• https://github.com/open-telemetry/donation-openinference/blob/main/python/openinference-instrumentation/src/openinference/instrumentation/context_attributes.py#L214-L256 – they let the user set some attributes in the Context that then make it into the spans..

• They put the thought signature in a bunch of places (seems we have an open issue to add this GenAI semconv needs vendor-neutral reasoning parts and continuity tokens semantic-conventions-genai#192 )

• They json dump the entire request/response into attributes (input.value and output.value)

• They only emit a trace/spans.. They don’t emit events. They don’t emit the execute_tool span..

• Bunch of other minor differences that don't seem worth mentioning.. diff between the gen ai instrumentation in our repo :https://www.diffchecker.com/sgN7o4nN/

I think the main takeaway is we can / should monkey patch more methods, we can use their instrumentation to guide us a little bit but it probably makes more sense to just roll our own...