Does emitting OpenTelemetry traces slow down an agent's response?

No, not when it’s set up correctly. The OpenTelemetry SDK’s batch span processor is built to keep telemetry off the request path: spans get queued in memory as they finish, and a background worker flushes them to the exporter on its own schedule, so the network call that ships your traces runs after the agent has already returned its answer, not before it. What can slow a response down is instrumenting it wrong, calling the exporter synchronously instead of through a processor, or setting a batch queue so small it blocks when full instead of dropping and retrying. Neither is how the SDKs ship by default. The one place instrumentation does cost something is CPU: building spans, serializing attributes, and copying message content takes cycles on the request thread itself, which is real but a fraction of a typical LLM call’s own latency, not comparable to it.