Skip to main content
Every supported framework follows the same pattern: pass a flag to init() (or call the framework subpackage’s install() directly for more control), and DecimalAI auto-captures traces, tool calls, and the underlying manifest.
Integrations come in three tiers. The tier tells you how much DecimalAI captures without extra work — every tier still gets tracing; the deeper tiers add schema-level manifests and the skills rail.

​
First-class

Native adapters with the deepest capture: full manifests (tool schemas or full config introspection), multi-agent structure, and — where the framework’s architecture allows it — live skill delivery.

LangChain & LangGraph

Callback handler. Chains, agents, LangGraph nodes all auto-traced, with skill injection via install(enable_skill_loader=True).

OpenAI Agents SDK

Deepest integration. Full manifest from agent introspection, plus the live load_skill tool.

Claude Agent SDK / Claude Code

Stream-wrapped tracing for query(), disk-installed skills for Claude Code.

​
Supported

Native adapters with a narrower surface — either tracing-only or skills-only, documented honestly on each page.

Pydantic AI

Skill loader + live load_skill tool via install(). Tracing flows through the underlying provider SDK.

Google ADK

Native ADK plugin. One trace per invocation with model, tools, and sub-agent activity.

LlamaIndex

Query engines, retrievers, synthesizers via the LlamaIndex instrumentation dispatcher.

​
Community / OTel-generic

These route through the generic OpenTelemetry exporter. They keep working, but they aren’t native adapters — manifest capture is limited to what OTel gen_ai.* conventions express.

AutoGen / AG2

Community/legacy. Upstream AutoGen is officially in maintenance mode (Microsoft’s Agent Framework is the planned successor).

CrewAI

Crews, tasks, agent conversations via OpenTelemetry.

Haystack & anything else

Any framework emitting OTel gen_ai.* semantic-convention spans, Haystack included.

​
Capability comparison

“Names only” means DecimalAI knows which tool was called but not its full input schema. If schema-aware manifests matter for your use case (e.g. you want the regression check to flag schema changes), use the explicit register_manifest() form for those frameworks. “Skills rail” is how registry skills reach the model on that adapter — see Skills for the offered → delivered → activated ladder.

​
Module-level reference

Install each framework’s dependencies with its extra — e.g. pip install "decimalai[langchain]" — so the adapter has the package it hooks into. CrewAI and Haystack ship through the same OTel pathway as AutoGen: there’s no decimalai.crewai subpackage, and init(crewai=True) is a convenience alias for the OTel exporter.

​
No framework at all

Two more rails cover raw provider-SDK usage:
  • Direct provider tracing — init(openai=True), init(anthropic=True), or init(google=True) auto-trace raw openai / anthropic / google.genai SDK calls via OpenInference instrumentors (install the matching openinference-instrumentation-<provider> package, or the flag warns and skips). Don’t combine with a framework flag that already traces the same provider, or calls are captured twice.
  • decimalai.anthropic — not a tracing adapter: it’s the SkillRouter prompt-injection adapter for the raw Anthropic Messages API (install(enable_skill_loader=True) patches client.messages.create() to inject skills into system). There is no tool loop in a single messages.create() call, so enable_load_skill_tool is accepted but dormant there.

​
What’s next

Tracing

Manual decorators if you need custom span boundaries inside an instrumented framework.

Manifests

Override the auto-detected manifest when needed.