Arize AX MCP tracing in Antigravity shifts agent observability

At a glance

What this is: Arize describes a way to add tracing to AI applications in Antigravity without writing code, with the key result that instrumentation, dependency resolution, and verification can happen inside the IDE.

Why it matters: For practitioners, this matters because observability is moving closer to the development workflow, which affects how teams govern AI agents, validate runtime behaviour, and keep audit evidence usable.

Context

AI observability is the discipline of making agent behaviour visible enough to debug, monitor, and govern it in production. The challenge is not simply collecting logs, but ensuring the right traces, artifacts, and dependency context exist when AI systems change quickly. For agentic workflows, that visibility has to be created early, not bolted on after deployment.

This article sits at the intersection of AI workflow instrumentation and governance. The identity angle is indirect but real: when agent behaviour is mediated through tooling, access to credentials, traces, and implementation artifacts becomes part of the control surface. That makes the observability layer relevant to teams responsible for both AI operations and security oversight.

Key questions

Q: How should teams implement observability for AI agents that call tools and APIs?

A: Teams should instrument the agent path end to end, from user input through retrieval, tool execution, and final response. That gives visibility into orchestration, makes failures easier to localise, and supports repeatable debugging. In practice, capture traces for every invocation, preserve the conversation context, and ensure tool calls are recorded so teams can inspect why an agent chose a specific action.

Q: Why do tracing dependencies create operational risk in AI agent stacks?

A: Tracing often depends on a chain of compatible packages across OpenTelemetry, framework adapters, and the agent runtime. When those versions drift, teams may lose trace coverage or introduce hidden runtime failures. The risk is not only technical instability but also reduced visibility into agent behaviour at the moment it matters most.

Q: What are the signs that AI observability is being treated as a one-off task?

A: If instrumentation is added manually, undocumented, and difficult to reproduce after the first successful run, observability is being handled as a one-off task. Stronger programs keep plan artifacts, debug scripts, and versioned dependencies so traceability can be revalidated whenever the agent changes.

Q: What should security teams review when an MCP server can modify agent code?

A: Teams should review the assistant’s access scope, the files it can read, and the configuration paths it can change. If the tool can alter source, dependencies, or runtime settings, it needs the same governance discipline applied to any code-changing automation, including ownership, approval boundaries, and change traceability.

Technical breakdown

MCP-based tracing assistants inside the development workflow

Model Context Protocol gives an agent a standard way to connect to tools and data sources. In this article, the MCP server acts as an instrumentation assistant: the developer asks for tracing, and the assistant returns guidance, examples, and implementation steps that fit the codebase. That matters because observability is no longer only a post-build integration task. It becomes a guided workflow in the IDE, where the agent can reason over the project structure, identify the tracing stack, and assemble the changes needed to expose runtime behaviour.

Practical implication: Treat MCP-assisted tracing as part of the build workflow and review the resulting instrumentation paths like any other code change.

OpenTelemetry dependency conflicts in agent instrumentation

Instrumenting AI applications often fails at the dependency layer before it fails at the tracing layer. OpenTelemetry packages, framework-specific adapters, and application libraries can disagree on versions or runtime compatibility, especially in fast-moving agent stacks. The article shows the agent iterating through package upgrades, compatibility fixes, and task artifacts until instrumentation held together. That is a useful reminder that observability depends on software supply chain hygiene as much as on telemetry design.

Practical implication: Pin and review tracing dependencies alongside agent runtime packages so instrumentation does not break during framework upgrades.

Artifact-driven verification for trace integrity

The article emphasises generated artifacts such as implementation plans, walkthroughs, and debug scripts. Those artifacts create a chain of evidence that the instrumentation was applied, how it was changed, and how traces were verified in Arize AX. For practitioners, that is the operational distinction between observability as a one-time setup and observability as a governed process. The latter can be reviewed, reused, and audited, which is especially important when agents change behaviour over time.

Practical implication: Use artifacts and verification scripts to preserve evidence of what changed, then re-run them after each agent or dependency update.

NHI Mgmt Group analysis

MCP-assisted observability is becoming part of agent governance, not just debugging. When tracing instructions are delivered through the same development workflow that builds the agent, observability moves upstream into the control plane for AI behaviour. That reduces the chance that teams ship opaque agent logic and only discover gaps after deployment. The broader governance point is that runtime visibility now has to be designed into the agent lifecycle, not retrofitted later.

Dependency drift is an observability failure mode, not a nuisance. The article’s OpenTelemetry conflict handling shows that tracing can collapse when framework versions, adapters, and agent libraries drift apart. In practice, the failure is not just broken telemetry. It is broken evidence, because teams lose the ability to explain what the agent did and why. That makes version control for instrumentation a governance requirement, not merely an engineering preference.

Artifact-based instrumentation creates a more defensible audit trail for AI systems. Plans, walkthroughs, and debug scripts turn observability from an invisible setup step into reviewable evidence. That is valuable for AI governance because it lets security, platform, and development teams align on what was changed and how traceability was validated. The named concept here is observability evidence chain: the set of artifacts that proves an agent was instrumented, verified, and kept in a known state. Practitioners should treat that chain as part of operational control.

Identity and access governance still matters even when the topic is tracing. The more AI systems depend on assistants, MCP servers, and code-aware tooling, the more important it becomes to govern what those tools can access while they instrument the environment. The article does not describe a security incident, but it does show how much authority the workflow grants to the agent. Teams should therefore align observability tooling with least-privilege access and clear ownership.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Observability evidence chain: AI teams now need a verifiable chain from tracing request to verified runtime output, because that chain is what makes agent behaviour explainable after release. When the instrumentation workflow itself is automated, the evidence around it becomes part of the control surface, not a byproduct. Practitioners should design for artifact retention, not just trace emission.

For programmes that are already adopting agentic tooling, the practical question is whether observability remains attached to individual projects or becomes a reusable operating pattern. The more that assistants can edit code and resolve dependencies, the more teams need governance over who can invoke those assistants, what they can change, and how those changes are reviewed.

This is where NHI and AI governance meet. If an MCP server or agentic assistant can inspect code, handle credentials, and rewrite instrumentation, it is acting like a privileged non-human operator inside the software delivery process. Security teams should map that authority to existing access review and change management controls rather than treating it as a convenience layer.

For practitioners

• Instrument agent tracing through controlled workflows Standardise how developers add tracing to AI applications so instrumentation happens through approved workflows rather than ad hoc edits in each project.
• Pin tracing dependencies and adapters Track OpenTelemetry packages, framework-specific adapters, and AI runtime libraries together so version drift does not break trace collection during upgrades.
• Require verification artifacts for observability changes Store implementation plans, walkthroughs, and debug scripts with the code change so teams can review how tracing was added and confirmed.
• Review assistant access to instrumentation paths Limit what the MCP server or similar assistant can inspect and modify, especially when it can touch source code, credentials, or runtime configuration.

Key takeaways

• AI observability is shifting from a post-deployment task to a development-time control, which changes how teams govern traceability and debugging.
• The biggest operational risk is not only missing traces, but losing evidence when dependency conflicts or tooling drift break the instrumentation chain.
• Practitioners should make tracing reproducible, versioned, and reviewable so agent behaviour remains explainable after the code changes again.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• AI observability: AI observability is the ability to see how AI systems are being used, what information they process, and what actions they trigger. In security programmes, it extends beyond uptime or model quality to runtime visibility, policy enforcement, and audit evidence across human and agent-driven use cases.
• OpenTelemetry: An open standard for collecting and moving traces, metrics, and logs in a consistent format. It helps teams avoid re-instrumenting every system when tools change, and it supports cross-platform analysis by keeping telemetry structured and portable.
• Implementation Artifact: An implementation artifact is a generated record of what changed during a technical workflow, such as a plan, walkthrough, or debug script. In governed AI operations, artifacts provide evidence that instrumentation was applied, reviewed, and verified rather than assumed to be correct.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps security and platform teams align non-human control points with the wider identity programme.