Azure Functions Agents runtime adds OpenTelemetry tracing for agent runs

Azure Functions Agents, the runtime that turns a folder of markdown agent files into a serverless functions app, now includes OpenTelemetry tracing in the runtime itself. Every agent run becomes a structured trace in Application Insights: the model used, the session, each tool call, and every sub-agent hand-off. No telemetry code needs to be added to the application.

Bootstrapping an agent app is still two lines:

from azure_functions_agents import create_function_app
app = create_function_app()

Enabling export takes two settings, not code: add azurefunctions-agents-runtime[monitor] to requirements.txt, set the APPLICATIONINSIGHTS_CONNECTION_STRING app setting, and every run appears in Application Insights' Agents view with a consistent set of attributes: which agent ran, which model answered, which tools were called, and how the run finished.

The runtime does not require selecting what to instrument. It captures the whole run every time, in the same shape, regardless of what the agent does underneath. That consistency makes the tracing useful beyond debugging; it also exposes behavior that would otherwise be hidden inside a single API call.

The Model Router example illustrates this. Model Router is a model you deploy yourself in a Foundry resource, the same way you'd deploy any other model. Point an agent's model setting at it, and it picks a different underlying LLM for each prompt: smaller models for simple requests, larger ones when a prompt actually needs the extra capacity. Normally that choice is invisible because it happens inside one API call. Because the runtime traces every run the same way regardless of which model sits behind it, the decision is visible without any additional work.

In one example, a single chat session sends two prompts: an easy one-shot question routes to gpt-5-mini; a complex, multi-step reasoning request escalates to gpt-5.4. Both requests record gen_ai.request.model = model-router — the deployment the agent called — while the response attribute names whichever model Router actually picked. The trace for the easy prompt shows gpt-5-mini; the trace for the hard prompt shows gpt-5.4. The full session is visible in the Agents pane of Application Insights.

Nothing here was instrumented specifically for Model Router. This is what a trace looks like now, for any agent, on any model. To reproduce it on an existing app: add the two settings, send requests, and open the Agents view or Transaction Search. The model, session, tool calls, and timing are all there, correlated under one trace.

The runtime source is on GitHub. The behavior is worth testing on your own agent: whether it is a single-model agent or something as dynamic as router-based model selection, you can see what happened without adding any instrumentation yourself.