The essentially composable nature of modern enterprise software stacks enables architectural freedom. Software developers are able to take advantage of componentized and containerized logic to create optimized code deployments, which can themselves be shifted between workloads that traverse multi-cloud instances.Agentic functions are enjoying some of the same freedom of movement, but unstandardized AI agent telemetry leaves us in the Wild West.Developers are empowering agents in production with the ability to call multiple system tools, invoke connections to AI models (language, visual and so on, both large and small) and even “improve” user requests and hand off work to other domain-specific agents.That’s all great news for system adaptability, but it’s a nightmare waiting to happen for agent telemetry.“When you use standards like OpenTelemetry and OpenInference, you keep optionality without losing visibility… The trace format stays consistent even as the stack changes.” – Richard Young, Arize.Why agent telemetry mattersInside the wider universe of observability, telemetry at this level lets software engineers know where agents exist, what connections they are entitled to and what actions they have taken.According technical director of partner solutions architecture at AI agent engineering company Arize, Richard Young, the agent telemetry challenge is not a question of where integration points exist, he says that the “important part is portability”, not just of agents, but of the telemetry standards we use to measure them.“When you use standards like OpenTelemetry and OpenInference, you keep optionality without losing visibility. Standardized agent telemetry lets you change frameworks, models, tools, or observability backends without rebuilding your instrumentation every time. The trace format stays consistent even as the stack changes,” writese Young, on his organization’s blog channel.For Young, the real story isn’t a point-to-point integration, but the push toward a shared telemetry model for agents.Google Cloud & Arize AI Arize is partnering with Google Cloud subsequent to the hyperscaler launching Gemini Enterprise Agent Platform last month. The Arize AX enterprise agent development platform not only receives traces (chronological records of software execution event history) from the Gemini Agent service, it also aligns agent telemetry around OpenTelemetry and OpenInference. This is done so software engineering teams can instrument agents once, analyze behavior consistently, and avoid locking critical observability data inside a single platform.CEO of cloud resource optimization company EfficientEther, Ryan Mangan, tells The New Stack that in any live production software deployment, you can’t operate what you can’t see, and that goes double for agents. “A single agent run can include request rewriting, retrieval, multiple tool and model calls, retries, and handoffs before producing a final answer,” Mangan says. “Without structured telemetry covering each of those steps, debugging becomes painstaking guesswork and evaluation becomes extremely difficult.”Mangan agrees that standards like OpenTelemetry and OpenInference matter because they give developers a consistent way to understand what an agent actually did, regardless of which framework, model, or platform produced it.Google Cloud NEXTOpenTelemetry arrived back in 2019, created through a merger of two initiatives, Google’s OpenCensus and the Cloud Native Computing Foundation’s OpenTracing project. In a Google Cloud NEXT session, Arize AI founder and CEO Jason Lopatecki and Google Cloud product leader Rami Shalom spent time discussing how enterprise AI agents need to be monitored and improved on the road ahead. Arize’s Young referenced this session and explained that observability has already “gone through this transition once”, when teams dealt with competing tracing standards, vendor-specific SDKs, and fragmented instrumentation.Instrument once, route anywhereThe bottom line that’s starting to become evident here is that teams need the ability to instrument once, but route anywhere.Founding engineer and Field CTO at cloud-native observability platform company groundcover, Noam Levy tells The New Stack that OpenTelemetry has indeed quickly become regarded as essential. But he cautions, adopting the standard doesn’t solve the harder problem: how telemetry is actually collected, normalized, and trusted at scale. “The next question isn’t just whether teams can afford to pay SaaS vendors to store and interpret that data — it’s whether that model holds up given the volume and privacy demands of agent-driven systems,” Levy says. “And even then, OpenTelemetry alone doesn’t unify agent observability. Teams still have to reconcile fragmented telemetry across providers i..e OpenAI looks different from Anthropic, which forces them to build systems that constantly adapt to upstream changes.Levy suggests that this is where eBPF changes the foundation. By operating at the operating system level, eBPF allows teams to observe system behavior without relying on application-level instrumentation, capturing signals directly from how software actually runs rather than how it’s instrumented. “OpenTelemetry agent conventions are being written by ML engineers for ML engineers, but… the CISO hasn’t shown up to that conversation yet.” – David Girvin, Sumo Logic.Simultaneously spawning sub-agents AI security researcher at log analytics and cloud security information & event management (SIEM) company Sumo Logic, David Girvin, tells The New Stack that converging on OpenTelemetry as a foundation for agent telemetry is genuinely important, but the harder problem is what teams do when that telemetry arrives into a platform at scale.“A single agent run is a manageable transcript,” Girvin says. “A thousand agents all running across production, handing off between each other, calling external tools, hitting retrieval systems and spawning sub-agents simultaneously? That becomes a data problem.”Advocating some wider tool democracy here, Girvin reminds us that OpenTelemetry agent conventions are being written by ML engineers for ML engineers, but, he warns, the CISO hasn’t shown up to that conversation yet. When they do, he says that teams that have instrumented purely for observability will find their telemetry doesn’t hold up for board-level investigation.How to question an agentWith the increasing autonomy granted to agents, we now need traces to illustrate the path followed by an agent to deliver its end output. Without this, software engineers will struggle to evaluate, debug and improve agent actions. That means agent traces need to answer the following questions: what was the original user request and now was it transformed; which models, tools and data sources were employed; to what degree did latency, hallucination, policy failure, or bad retrieval occur; and which steps agentic code execution steps should be further analyzed for improvement?Standardization before agentificationIn the spirit of not running before we can walk, the industry appears to be forming a solidifying consensus around the need to standardize measures of agent behavior. When those measures also include standardized methods of measurement, then we may achieve structured agent telemetry with enough semantic detail to support evaluation and agentic improvement.The post Arize AI and Google Cloud lay down standardized telemetry mandate to keep enterprise agents in check appeared first on The New Stack.