Trace context

The identifiers that connect work

Trace context commonly carries a trace identifier for the overall operation, a parent span identifier for the current caller, and flags that influence processing such as sampling. A service reads the context from an incoming request, creates a span for its own work, and passes the new context to the next dependency.

Without that handoff, each service may still produce telemetry, but the records cannot be navigated as one request. A slow database query can appear detached from the API request that waited for it. An agent's tool call can appear detached from the task that selected it.

Propagation needs boundaries

Context can cross HTTP requests, message queues, scheduled jobs, and worker processes. The propagation mechanism must match the transport and the instrumentation used by the receiving component. Asynchronous work may need an explicit link when there is no simple parent and child relationship.

Treat trace context as correlation metadata, not as a place to store prompts, credentials, or arbitrary business data. Validate and sanitize values at trust boundaries. Check propagation in tests and in a real trace, because a successful request does not prove that its context was preserved.

Context makes investigation possible

A stable context lets teams follow timing, errors, retries, and decisions across a workflow. It is especially useful when a request crosses application code and an AI provider. Combine it with outcome data and deployment history so the trace explains both what happened and what the team can change.