Which agent decision made you money, and which one cost you?

Traces show what the agent did. KPIs show what mattered. The payoff is joining them, so you can see that this reasoning path lifted conversion while that tool choice drove refunds.

B

Balagei G Nagarajan

4 MIN READ


An agent trace on the left connected by a joining key to a revenue chart on the right
Tools returned 200s, the trace looks healthy, customer abandoned the cart anyway.
— from “Which agent decision made you money, and which one cost you?”

Key facts.

  • Business and session IDs attach to traces. Panels track agent-action KPIs, leads processed, revenue per interaction, right alongside the technical spans. OpenTelemetry with Grafana Cloud makes this straightforward.source
  • Workflow-level tracing (for example Langfuse) links each prompt to its model output and records execution time, giving a step-by-step view of the reasoning path you can then join to an outcome.source
  • Correlation enables surgical, revenue-saving fixes: a latency spike at a specific step matched to a drop in cart conversion points you at the exact cause, not a generic alert.source
  • The organizations that get the most from observability tie it directly to business outcomes, mapping trust, cost, and latency to KPIs so decisions are faster and defensible to leadership.source

Why is "the agent worked" not enough?

A run can be technically clean and commercially useless. Tools returned 200s, the trace looks healthy, customer abandoned the cart anyway. Or filed a refund. Technical success and business success don't overlap, they're in different systems. Trace is in your observability stack. Outcome is in your CRM, analytics, or billing. If nothing links them, you're left guessing which of the agent's decisions actually moved a number you care about. Correlation is what closes that gap, and it's the difference between a dashboard that says the agent is up and a dashboard that says this behavior is making you money and that one is leaking it.

Once the link exists, the questions you can finally answer are the useful ones. Did the agent's tool choice raise order value? Did a low-confidence retrieval correlate with higher churn? Which reasoning path converts and which one quietly drives returns? Those are product decisions, and they need the trace and the outcome on the same row.

Sankey diagram showing agent decision paths flowing into business outcome buckets like converted, refunded, and churned

What are the concrete mechanics?

It comes down to a shared key and a join. Propagate a correlation id (session, order, or customer) through every span of the run, so the whole trace is tagged with the same business identity. Record the outcome against that same key when it lands, whether that's a conversion, a refund, or a cancellation, often minutes or hours later. Then join the spans to the outcome on the key, and aggregate: group by the decision pattern (which tool, which retrieval, which path) and read off the KPI for each group. From there, an alert that a latency spike at a step coincides with a conversion dip becomes actionable, because you know exactly which step to fix. Treat vendor "business observability" dashboards as a starting point, not proof; the join only tells the truth if your correlation key is propagated cleanly and your outcome data is accurate.

QuestionTrace aloneTrace joined to outcome
Did the agent run?YesYes
Did this decision convert?NoYes, by KPI per decision pattern
What is driving refunds?NoYes, the path correlated with returns
Which fix saves revenue?GuessThe step tied to the conversion drop

A run completing isn't a run helping; even a frontier agent finishes ~61% of retail tasks first try (tau-bench), so a clean run can be a lost order. (source)

This decision-to-outcome link is what a Pattern Intelligence Layer is built to exploit. Reliability at the pattern level means you evaluate the agent's behavior by the business patterns it produces, not just by whether each run completed, so the decisions that reliably help and the ones that reliably hurt become visible and fixable. The agent stops being a black box that "worked" and becomes a set of behaviors you can tie, one by one, to the numbers that pay for it.

Frequently asked questions

what's the one thing I have to get right?
Propagate a single business key (session, order, or customer id) through every span. Without a clean correlation key, you can't join traces to outcomes, and nothing else works.

The outcome happens later than the trace. Does that break it?
No. Record the outcome against the same key when it lands and join after the fact. Conversions, refunds, and churn are expected to arrive minutes or hours later.

Can I trust a vendor's business-KPI dashboard out of the box?
Use it as a start. The correlation is only as good as your key propagation and outcome-data accuracy, so validate the join before you make decisions on it.


Share this post

Join the discussion

Have a take, a war story, or a question? Sign in with GitHub to comment and react. Comments are powered by GitHub Discussions, ad-free and yours to moderate.

Continue Reading

Find where your agent breaks, before you build it

Faultmap maps where your agent will fail from the goal and your data, then hands you the first test suite it has to pass.