Connect agent traces to business outcomes with OpenTelemetry

An agent trace can explain how a request executed without establishing whether the user’s goal was achieved. To investigate outcomes, connect the execution record to the application’s authoritative result: the updated record, completed job, or rejected operation.

OpenTelemetry provides the tracing foundation. Its trace documentation explains spans, parent-child relationships, and links between causally related work. The application design below builds on those concepts; the example field names are custom suggestions, not standardized OpenTelemetry semantic conventions.

Separate execution structure from business identity

A trace identifier groups execution activity. An order identifier names a business object. An operation identifier names an attempted business change. These identifiers answer different questions and should not be substituted for one another.

Consider a user asking an agent to reschedule a delivery. A request span contains a model call and a scheduling tool call. The tool queues a job. A worker processes it later, potentially in a separate trace. The worker’s terminal result determines whether the delivery changed.

Preserve causal trace context where your transport and instrumentation support it. Also preserve a stable operation identifier through the queue and downstream response. The business join gives investigators a way to resolve the action even when execution crosses a trace boundary or some telemetry is missing.

Capture a compact evidence envelope

{
  "app.operation.id": "op_example_42",
  "app.operation.type": "delivery.reschedule",
  "app.operation.target": "delivery_example_17",
  "app.operation.state": "pending",
  "app.operation.attempt": "attempt_example_1",
  "app.release": "example-release"
}

This illustrative JSON is an application-owned schema. It is not a drop-in SDK configuration. Define field types, allowed states, retention, and access before adopting an equivalent structure. Use opaque identifiers rather than customer names or addresses.

The envelope should support a few questions: which action was intended, which object it targeted, which attempt produced this event, and what release was running? Store detailed payloads only when necessary and permitted. A concise status and authorized evidence reference can be more useful than a large unstructured dump.

Make asynchronous work explicit

Represent acceptance and completion as separate events. A queue acknowledgment establishes that work was accepted by a particular component. It does not establish that the downstream change succeeded. Give the worker a way to emit a terminal outcome tied to the same operation.

Account for duplicate and out-of-order delivery. A delayed “pending” event should not erase an authoritative completion result. A newer failure for a different attempt should not automatically override an already committed business action. Resolve state using your application’s semantics and event versioning, rather than a generic last-write-wins rule.

If work fans out, track the required sub-actions. “Reschedule delivery” may include a warehouse update and a carrier confirmation. Define whether partial success is acceptable and how the user should be informed. Otherwise a trace viewer can display two green steps while the application lacks a clear overall outcome.

Distinguish missing instrumentation from bad behavior

Create a telemetry completeness check alongside the behavior check. Does the operation have a request event? Can the terminal result be joined? Is the final user-facing statement captured? If a required piece is absent, mark the assessment as evidence-limited.

This prevents a subtle failure mode: a detector appears to improve because the system stopped recording difficult outcomes. Track the fraction of sessions that are assessable, not just the fraction judged successful. Review changes in evidence coverage after instrumentation and sampling changes.

Test boundaries instead of only the happy path

Exercise a delayed worker, a duplicate event, a tool timeout followed by a successful write, a missing terminal event, and two actions on similar objects. Ask an engineer to reconstruct the result without reading application source code. Any required guess identifies an instrumentation or contract gap.

Measure overhead as part of the integration. Large payloads and excessive event volume can create their own operational problems. Choose the evidence required for investigation, then verify that the chosen transport and retention policy preserve it.

The goal is a trace that helps a reviewer make a defensible statement about an action. Pair this design with the completion-state model and the observability cost worksheet before expanding collection across every workflow.