OpenTelemetry Observability for Builders — Agent 365: Operate at Scale

Every governance promise about agents depends on a quieter engineering promise: the agent must leave a trustworthy trail. Threat detection, compliance review, access investigation, and audit reporting all need records of what the agent did, what it called, and where work was handed off. OpenTelemetry gives builders a standard way to create that trail, and Agent 365 can consume it through automatic, manual, or direct integration paths.

Visibility is built, not assumed

An agent does not become observable simply because it exists in a tenant, a registry, or a development platform. Someone has to instrument it. Instrumentation means adding code or configuration that records activity and sends that record to an observability system.

For builders, this is the practical bridge between application code and governance. If an agent receives a prompt, calls a tool, invokes a model, reads business data, or delegates work to another agent, those events need to be represented in telemetry. Without that wiring, administrators and security systems are left reasoning from incomplete evidence.

This does not mean every internal variable or every token must be logged. Good observability is selective. It records the events needed to understand behavior, investigate risk, and prove control, while avoiding unnecessary exposure of sensitive data.

⚠️

No trail, no control. A policy system can only evaluate agent activity that has been captured and delivered to it.

OpenTelemetry gives builders one common language

Agent 365 observability builds on OpenTelemetry, often shortened to OTel, an open industry standard for collecting telemetry across different platforms and tools. The important word is open. OpenTelemetry is not a Microsoft-only format, and it is not tied to one agent framework.

That matters because agent estates are rarely uniform. One team may build with Microsoft tools, another may use LangChain, another may use OpenAI tooling, and another may build a custom runtime. A shared telemetry standard reduces the number of special cases. The same broad tracing model can describe work across those different stacks.

In OpenTelemetry, a trace represents a path of work through a system, and spans represent meaningful steps inside that path. For an agent, those steps might include receiving a request, choosing a tool, calling a model, invoking an application programming interface, or handing work to another agent. Agent 365 uses this kind of telemetry as the raw material for observability.

Different agent stacks all describe their work in one shared telemetry model.

The Microsoft OpenTelemetry Distro reduces the setup burden

A standard is useful, but builders still need libraries, defaults, exporters, and configuration. Microsoft provides the Microsoft OpenTelemetry Distro for this purpose. A distro, short for distribution, is a packaged set of components and defaults that helps teams adopt OpenTelemetry without assembling every piece themselves.

The Microsoft OpenTelemetry Distro provides a single observability software development kit across Microsoft services, including Agent 365, Microsoft Foundry, and Azure Monitor. That means a builder does not need to learn a different observability approach for each of those destinations.

In many cases, an artificial intelligence guided setup can configure the observability path automatically. That does not remove the need for engineering judgment, but it can remove a large amount of repetitive setup work.

Choose the right instrumentation path

There are three practical paths into Agent 365 observability. The best choice depends on the agent framework, programming language, and level of control the builder needs.

Auto-instrumentation is the lowest-effort path. If an agent is built with supported popular stacks such as OpenAI tools, LangChain, or Microsoft Agent Framework, tracing can often be enabled with little additional code because the integration already understands common operations in those frameworks.

Manual instrumentation is the deliberate path. The builder writes the tracing calls into the agent code and decides which operations deserve spans. This is useful when a framework is not covered by automatic integration, or when the team needs precise control over what is recorded.

Direct integration through OpenTelemetry Protocol, often shortened to OTLP, is the fallback path when the Agent 365 software development kit cannot be used. If the framework is incompatible or the agent is written in a language the software development kit does not yet support, telemetry can still be sent directly to Agent 365 over Hypertext Transfer Protocol using OTLP, with no software development kit dependency.

Use auto-instrumentation when the agent uses a supported framework and the default trace coverage is enough.
Use manual instrumentation when the team needs to decide exactly which agent actions become telemetry.
Use direct OpenTelemetry Protocol integration when the software development kit is not available for the framework or language.

The right instrumentation path depends on whether the framework is supported.

What to record in an agent trace

The goal of tracing is not to produce a noisy diary of every line of code. The goal is to preserve the shape of the work. A useful agent trace lets an investigator understand the request, the major decisions, the tools used, the systems touched, and the handoffs that occurred.

For example, a trace might show that an agent received a user request, selected a customer relationship management tool, called a model to summarize results, wrote a draft response, and returned that response to the user. If something goes wrong, the trace gives the investigation a timeline instead of a mystery.

Builders should also think carefully about data minimization. Telemetry can become sensitive if it includes prompts, outputs, identifiers, file names, or business records. The safest design records enough context to support audit and debugging, but not more content than the organization is prepared to protect.

📌

Trace the shape. A good trace explains the path of work without turning observability into a second copy of sensitive business data.

A useful trace preserves the shape of the work as ordered spans.

Super agents need visible delegation chains

Some agents are super agents: they call one or more sub-agents to complete a task. This pattern is powerful, but it can hide accountability if the internal handoffs are not logged.

When a super agent delegates work, each sub-agent call should be recorded. Depending on the design, the call may be logged as an ordinary tool call or as an agent-to-agent call. Agent-to-agent is often shortened to A2A. The naming is less important than the outcome: the delegation chain must remain visible and auditable.

Without this record, the outer agent may look responsible for the whole outcome while the important decisions happened somewhere else. Observability must follow the work across the boundary, not stop at the first agent.

⚠️

Hidden handoffs. If a super agent delegates work without logging the handoff, the most important part of the decision path may disappear.

Every sub-agent handoff is logged so the delegation chain stays auditable.

The real decision for leaders and builders

The practical question is not whether observability matters. It is where the organization will standardize and how much variation it will allow. Leaders need a baseline that makes every agent traceable, while builders need enough flexibility to use the right tools for their stack.

A sensible standard is simple: supported frameworks should use auto-instrumentation by default, custom agents should use manual instrumentation, and unsupported stacks should use direct OpenTelemetry Protocol integration rather than becoming exceptions. The policy should also say that super-agent delegation must be recorded.

This turns observability from an afterthought into an engineering requirement. It also gives platform teams a clear review question: before an agent is approved for production, can its important actions be traced in a way that security, compliance, and operations teams can actually use?

Set a default instrumentation path for supported frameworks.
Require manual spans for custom agent decisions and tool use.
Allow direct OpenTelemetry Protocol integration when the software development kit is not usable.
Review super-agent designs for complete delegation logging.
Treat telemetry design as part of production readiness, not post-launch cleanup.

Key takeaways

Agent visibility is not automatic; builders must instrument agents so activity becomes telemetry.
Agent 365 observability builds on OpenTelemetry, an open industry standard rather than a Microsoft-only format.
The Microsoft OpenTelemetry Distro provides one observability toolkit across Agent 365, Microsoft Foundry, Azure Monitor, and related Microsoft services.
Builders can use auto-instrumentation for supported stacks, manual instrumentation for custom control, or direct OpenTelemetry Protocol integration when the software development kit is not usable.
Super agents must log sub-agent handoffs as tool calls or agent-to-agent calls so delegation remains auditable.
Good traces record the path of work while avoiding unnecessary exposure of sensitive content.

Glossary

Instrumentation: Instrumentation is the code or configuration that records what a system does and sends that record to an observability system.
OpenTelemetry: OpenTelemetry is an open industry standard for collecting telemetry such as traces across different platforms and tools.
Microsoft OpenTelemetry Distro: The Microsoft OpenTelemetry Distro is a Microsoft-provided OpenTelemetry toolkit used across services such as Agent 365, Microsoft Foundry, and Azure Monitor.
Trace: A trace is a record of a path of work through a system, usually made up of smaller steps called spans.
Span: A span is one meaningful step inside a trace, such as a model call, tool call, or agent handoff.
Auto-instrumentation: Auto-instrumentation enables tracing with little extra code because the observability integration already understands a supported framework.
Manual instrumentation: Manual instrumentation means the builder writes tracing calls directly into the agent code.
OpenTelemetry Protocol: OpenTelemetry Protocol is the transport protocol used to send OpenTelemetry data and can be used directly without a software development kit.
Super agent: A super agent is an agent that calls one or more sub-agents to complete a task.