Send Respan LLM and agent traces to Sazabi

Last verified on Nov 8, 2026.

An LLM app fails in ways an HTTP status never shows. The model answered, the status was 200, and the answer was wrong because a tool call returned empty data three steps earlier. Respan (formerly Keywords AI) records those steps as spans: LLM calls, tool calls and agent runs.

Sazabi, the AI-native observability and security platform, can receive those spans next to your service logs, and its agent can read Respan directly. The first tells you what the app did. The second tells you what Respan recorded about it.

What each source sends

Spans from the Respan SDK. Install respan-ai for Python or @respan/respan for TypeScript, and set RESPAN_BASE_URL to your Sazabi intake URL, or pass it to the constructor. The SDK's auto-instrumentation, which Respan says covers 25+ frameworks including OpenAI, Anthropic, Bedrock, Vertex and LangChain, then exports over OTLP/HTTP. Nothing else changes: if you use an agent framework, pass the same instrumentor you would pass when exporting to Respan. The source accepts both /api/v2/traces from the SDK and standard /v1/traces, so a team that already runs an OpenTelemetry exporter can skip the SDK. Sazabi ingests OpenTelemetry metrics (Prometheus metrics through an OpenTelemetry Collector) and OTLP traces through the same intake as your logs. It stores each metric data point and each span as a log record that its agent queries alongside your logs, so there is no separate metrics store to run.

Tools from Respan's MCP server. The connector talks to https://mcp.respan.ai/api/mcp with a Respan API key and exposes:

• list_logs, get_log_detail and create_log for LLM request logs
• list_traces and get_trace_tree for execution traces
• list_customers and get_customer_detail for customer data and budget usage
• list_prompts, get_prompt_detail, list_prompt_versions and get_prompt_version_detail for prompts

The respan CLI in the sandbox. It covers traces, prompts, evaluators, experiments and datasets, authenticated with RESPAN_API_KEY.

Questions it answers

• Which tool call returned nothing before the model produced a bad answer?
• Did the failing runs all use one prompt version?
• Which customer is burning through their budget?
• Were slow runs slow in the model call or in a service the agent called?
• Did the LLM provider's errors line up with errors in our own API?

A worked example: one customer, one prompt version

Respan lets you tag traces with customer_identifier and metadata, and group calls with the @workflow and @task decorators. Suppose a customer reports that the support assistant started giving odd answers on Friday. The prompt was edited that day.

Ask the Sazabi agent in a thread:

Using Respan, list traces for customer_identifier "acme-demo" since Friday 09:00.
For the three slowest, get the trace tree and tell me which prompt version each
one used. Then check our application logs for errors in the same windows.

The agent calls list_traces and get_trace_tree, and list_prompt_versions or get_prompt_version_detail for the versions in question. Two outcomes are common. If every slow trace used the new prompt version, the edit is the lead, and you can compare the prompt text it reads from Respan. If they spread across versions, the cause is elsewhere, and the application logs, which arrive over the same intake as the spans, show whether a downstream service was failing in those windows. Either way you leave with a specific trace to open in Respan, not a hunch.

If you only want investigation and no changes, turn on the connection's read-only toggle so create_log is unavailable.

How it fits with other integrations

Respan belongs to the AI frameworks category, alongside LangSmith and Langfuse, which take the same MCP-connector route. The OTLP path is the same one described on the OpenTelemetry page. Coding agents such as Claude Code have their own page. For volume, see pricing.