Microsoft Agent Framework Tracing Is Here - Stop Shipping Agents You Can't Debug

Your agent picked the wrong tool on step three of a seven-step run, looped twice, burned tokens on a retry, and returned a confident wrong answer. Your logs show a timestamp, an HTTP 200, and a final output. That’s it. You cannot see the decision chain, so you cannot explain the failure, so you cannot fix it.

This is the default state of most agent deployments right now, and it just became inexcusable. Microsoft Agent Framework tracing is in public preview in Foundry, for both Python and .NET. The dual-language coverage is the headline: whichever side of the Microsoft stack your team lives on, first-class visibility into agent execution is now a setup step, not a side project.

“It worked in the demo” agents break in production precisely because nobody can see what happened between the prompt and the answer. Tracing is the line between an agent demo and an agent product. Here is what shipped, how it works, and what to do about it this week.

What Microsoft Agent Framework Tracing Actually Ships

The release gives you a decision chain, not an API log dump. When your agent runs, tracing captures the orchestration flow: the agent run itself, each model call with model name and token usage, and each tool invocation. You see the loop structure - agent went to the model, model requested a tool, tool returned, model was called again - as a connected trace rather than scattered line items.

Two qualifications matter, and the marketing copy will not volunteer them.

First, “reasoning” here means orchestration steps and model interactions, not the model’s hidden chain of thought. You see that the agent chose a tool, with what arguments, and what came back. You do not see inside the model’s head. That is still enormously useful; it is just not mind reading.

Second, sensitive content is off by default. Prompt and response bodies and tool arguments are exactly the kind of data you want when debugging and exactly the kind of data your security team does not want flowing into a telemetry backend by accident. Capturing them requires an explicit opt-in, which is the right default. Flip it on in dev, think hard before flipping it on in prod.

Traces land in the Foundry tracing view, where you can walk a run span by span, or in any backend you point an exporter at. That second part is the interesting one.

The takeaway: both major Microsoft ecosystems now get orchestration-level visibility with minimal instrumentation code, and the sensitive-content default is sane.

OpenTelemetry AI Agents: How the Spans Fit Together

OpenTelemetry AI agents support is the actual foundation here, and it is the reason this release matters beyond the Foundry portal. Agent Framework emits standard OTel spans following the GenAI semantic conventions - gen_ai.* attributes on spans like invoke_agent, chat, and execute_tool.

Mapped to agent terms: the agent run is a parent span. Each model call and each tool invocation is a child span with attributes - model name, token counts, tool name, duration. Nested agents produce nested spans. The result is a tree you can read the way you read a distributed trace for a microservice call chain, because structurally that is what an agent run is.

Portability is the payoff. Because this is OTLP, your exporter options include Azure Monitor and Application Insights, the Foundry UI, the Aspire Dashboard for local .NET work, or Jaeger on your laptop. If your organization already runs an observability pipeline, agent traces can flow into it. Treat agents like any other distributed system, because they are one.

Now the practitioner caveats, because the docs show the happy path and production is not the happy path:

• The GenAI semantic conventions are experimental. Attribute names have drifted across versions and will drift again. Pin versions, and validate the telemetry you actually receive before you build dashboards on specific attribute names.
• Tool inputs often contain user data. If you opt in to content capture, you need PII scrubbing - a Collector processor that redacts span attributes is the standard pattern - before those spans leave your boundary.
• Decide sampling before launch, not after. Trace volume scales with turns times tools times sub-agents, and agents are chatty. Tail-based sampling that keeps error traces and high-cost runs while dropping routine successes is the pattern to aim for.
• Retention is a cost line. Full-content traces of a busy agent are not cheap to store. Work out tiers and retention windows before finance finds them for you.

The takeaway: because it is OpenTelemetry, you are not buying into a proprietary dashboard. You are instrumenting a distributed system with the same discipline you already apply elsewhere. Alternatives like LangSmith and Langfuse exist and are fine tools; the point is that OTel-native output means you are not forced to choose a walled garden at all.

Logs vs. Tracing: Be Honest About the Gap

Plenty of teams believe their structured logging is good enough. For a single-call agent, it might be. For anything with a loop, it is not, and the comparison below is why.

Logs win exactly one row, and only for agents simple enough that you should question whether they needed to be agents at all - a decision I have argued at length in Microsoft agent vs flow: when to build which. For everything else, the recommendation is not balanced: wire in tracing.

The Real Unlock: Three Jobs Beyond Bug Hunting

Debugging justifies the setup cost on its own. But three other jobs are where tracing compounds.

Cost and latency attribution. When a run takes nine seconds, a trace tells you whether that was one tool call eating three seconds or three model calls eating two each. When token spend climbs, span-level token counts tell you which call pattern is burning budget. These figures are illustrative - calibrate against your own runs, actuals vary - but the mechanism is the point: attribution per step instead of a per-run blob. This is the raw material for the cost controls I covered in AI cost governance for Azure LLM workloads.

Audit trail. When compliance asks what the agent decided and why, a trace is an answer. A log file is an apology. Be precise about the limit, though: a trace is evidence for an audit trail, not a compliance solution. Retention policy, access control, and data handling for the traces themselves are still your problem, and if you opted in to content capture, your traces are now sensitive data with their own governance requirements.

The tuning loop. Most prompt iteration is guessing from final outputs. With traces, you iterate against execution data: this tool description caused the wrong tool selection in these runs, this prompt change cut the average loop count. You tune the mechanism, not the symptom.

The takeaway: tracing pays for itself the first time you have to explain an agent’s behavior to someone who was not in the room. That someone will exist.

Foundry Observability Is a System, Not a Feature

This release is one leg of the broader Foundry observability push. The loop Microsoft is assembling: build with Agent Framework, trace via OpenTelemetry, debug in the Foundry trace view, evaluate quality and safety with the evaluation tooling, monitor in production. Tracing feeds the other legs - evaluation against real execution data beats evaluation against synthetic transcripts.

The strategic read: Foundry is being positioned as the operational control plane for agentic apps, not just a model gateway. Agent Framework is the public convergence of Semantic Kernel’s enterprise primitives and AutoGen’s multi-agent orchestration, and tracing is the unglamorous piece that makes the converged story enterprise-deployable. It fits squarely into the CI/CD and operations picture I walked through in AgentOps on Microsoft Foundry.

One caution: convergence is in motion, not finished. Teams invested in Semantic Kernel should read the migration guidance in the repo and docs rather than assume feature parity today. The public artifacts describe convergence; nothing there says “deprecated,” and neither should you.

The takeaway: evaluate Foundry observability as a system - tracing plus evaluation plus monitoring - because the value is the loop, not any single pane.

What to Do This Week

Not next quarter. This week, in a dev environment, with an agent you already have.

The strong position, stated plainly: wire tracing in before you write your second tool, not after your first incident. An agent without tracing is technical debt on day one, because the day it misbehaves in production - and it will - you will have nothing but a final output and a guess.

The gap between a demo agent and a production agent is observability. Microsoft Agent Framework tracing just removed the last excuse. Enable it in dev this week, before your agent does something in production you cannot explain.