Distributed Tracing (W3C Trace Context)

How dobby-collector v0.4.0+ auto-emits W3C traceparent headers, and what that unlocks for your governance score.

TL;DR: Upgrade to dobby-collector ≥ 0.4.0 with pip install -U dobby-collector. Every batch your SDK ships to Dobby will automatically carry a traceparent header. Within the next governance rescore (hourly), the Tracing Enabled control will flip from Not applicable → Configured for every agent in your org.

What is "tracing" in Dobby's governance score?

One of Dobby's 19 Surrounding-mode governance controls is Tracing Enabled (control weight = 4). It checks whether your agents' requests carry a W3C Trace Context traceparent header — the industry-standard way to correlate a single logical operation across multiple services.

Why CISOs care: If an agent makes a chain of LLM calls + tool calls across 3 services, traceparent is what lets you reconstruct the whole flow from any single log line. Without it, post-incident forensics requires guessing which gateway request matches which downstream side-effect.

What a traceparent looks like

traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01

Version

0af7...319c

Trace ID (16 bytes)

b7ad...3331

Span ID (8 bytes)

Sampled flag

Path 1 — Upgrade dobby-collector (recommended)

Since v0.4.0 (2026-05-16), the SDK generates a fresh traceparent per batch via Python's secrets.token_hex and adds it to every outbound POST. No code changes required.

pip install -U 'dobby-collector>=0.4.0'

That's it. Your existing init(...) call picks up the new behavior automatically.

Verifying it worked

Trigger any agent run in your code path so a batch ships to Dobby.
Wait up to 60 minutes for the next governance-rescore cron tick (or click Rescore in the governance drill-down to fire it immediately).
Open your agent's governance page. The Tracing Enabled control will be green with source: "sdk_workload" in the details.

Path 2 — Configure OpenTelemetry on your gateway clients

If your agents talk to LLMs through Dobby's gateway (Inline or Hybrid mode), you can pass the detector by configuring OpenTelemetry in your HTTP client. Any standard OTel instrumentation that auto-injects traceparent works:

# Example: OpenTelemetry instrumented httpx client
from opentelemetry.instrumentation.httpx import HTTPXClientInstrumentor
HTTPXClientInstrumentor().instrument()

# Now every httpx request — including to Dobby's gateway —
# carries a traceparent header automatically.
client.chat.completions.create(model="gpt-4o-mini", messages=[...])

Same outcome for the governance score, with source: "gateway" in the control details.

How Dobby uses the header (server side)

Validation: Strict W3C format check + rejection of all-zero sentinel trace-ids (per spec). Malformed headers are dropped silently — no batch is ever rejected for a bad header alone.

Storage: Validated header is stamped onto workload_runs.metadata_json.traceparent (for SDK customers) or llm_gateway_requests.metadata.traceparent (for gateway customers).

Governance scoring: The hourly governance-rescore cron queries both tables. Either path having ≥ 1 traced row in the last 7 days flips the control to Configured.

Privacy: traceparent is an opaque random-bytes correlation identifier — Dobby never logs your code/IP/PII based on it. The trace-id has no link to your customer data.

Why does the control show as "Not applicable" before I act?

Most agent stacks (LangChain, CrewAI, OpenAI SDK, Anthropic SDK, raw requests / httpx) do not emit traceparent by default. If Dobby counted that as a failure, every customer would lose 4 weight units on every agent until they did something they hadn't been told to do.

So when zero traceparent is observed, Dobby routes the control to Not applicable (removed from the weighted denominator, doesn't lower your score), with an actionable hint pointing back to this page. Once you ship even a single traced request, the control flips to Configured and starts counting toward your score.