Google Agent Gateway Gets Cloud Trace Support in Preview

Somebody's agent hung, and the ticket says only "it was slow." Agent Gateway Cloud Trace support, now in Preview, lets you answer that by following one request from the agent, through the gateway, to the tool, other agent or MCP server (Model Context Protocol, the standard way agents call tools) it was talking to. Google's release notes list it under September 30, 2026, in the Gemini Enterprise Agent Platform section.

This piece covers what it traces, what to switch on, and what a support team can do with it on Monday.

What shipped: Agent Gateway Cloud Trace in Preview

Agent Gateway is the network entry and exit point for agent traffic on Gemini Enterprise Agent Platform. It checks agent identity, consults the Agent Registry and applies policies such as Model Armor before a call goes through (overview). It already writes allow and deny decisions to Cloud Logging. The new part is spans.

Per the monitoring docs, you get end-to-end request visibility across the gateway and the Google Cloud services, tools, agents and MCP servers behind it. You can read it in Trace explorer, a timeline view or a graph view.

The link back to logs is the useful bit for support. Every gateway request log carries a trace field, so Logs Explorer has a "View trace details" action, and Trace has a "Show logs" action going the other way.

It is Preview, so the Pre-GA Offerings Terms apply.

Turn on Agent Gateway Cloud Trace

Enable the API and grant the roles

gcloud services enable cloudtrace.googleapis.com --project=<your-project-id>

for SA in \
  service-<project-number>@compute-system.iam.gserviceaccount.com \
  service-<project-number>@gcp-sa-networksecurity.iam.gserviceaccount.com \
  service-<project-number>@gcp-sa-agentgateway.iam.gserviceaccount.com; do
  gcloud projects add-iam-policy-binding <your-project-id> \
    --member="serviceAccount:${SA}" \
    --role="roles/cloudtrace.agent"
done

These are the three Google-managed service agents that write spans. If your own agent starts traces, give its workload service account roles/cloudtrace.agent too. Whoever applies the policy needs roles/compute.networkAdmin or roles/compute.admin, and anyone reading traces needs roles/cloudtrace.user.

Apply a tracing policy to the gateway

# tracing-policy.yaml
name: "projects/<your-project-id>/locations/<region>/telemetryPolicies/<policy-name>"
targetTelemetry:
  resources:
  - "//networkservices.googleapis.com/projects/<your-project-id>/locations/<region>/agentGateways/<agent-gateway-name>"
displayName: "Tracing policy for Agent Gateway traffic"
tracingConfiguration:
  samplingRate: 1.0
  parentBasedSampling:
    enabled: true
    samplingRate: 1.0

gcloud beta network-services telemetry-policies import <policy-name> \
  --source=tracing-policy.yaml \
  --location=<region>

The policy targets one gateway. The docs suggest 1.00 only to validate on low traffic, and 0.01 or 0.001 in production. Note the gcloud beta command group.

Make your agents pass the traceparent header

The docs are explicit: your application needs an OpenTelemetry SDK with context propagation enabled, so the W3C traceparent header travels across service boundaries. Without it, you get gateway spans but no story that starts at the agent.

import requests
from opentelemetry import trace
from opentelemetry.propagate import inject

tracer = trace.get_tracer("support-agent")

with tracer.start_as_current_span("agent.call_tool"):
    headers = {}
    inject(headers)  # adds the W3C traceparent header
    requests.post("https://<tool-or-mcp-host>/mcp", headers=headers, json=payload)

This is plain OpenTelemetry, not a gateway API. Many frameworks do the injection for you, so check what yours does before adding code.

What a support team does on Monday

1. Pick one non-production gateway and run the three steps above at a sampling rate of 1.0.
2. Fire a test request that you know gets denied, and one that succeeds. Find both in Trace explorer.
3. Add a "trace ID" field to your agent incident template. The gateway log's trace field has the format projects/<project-id>/traces/<trace-id>.
4. Write the runbook in one line: ticket, then Logs Explorer filtered on the gateway, then "View trace details", then the timeline.

For the log filter, the docs use the gateway's monitored resource:

resource.type="networkservices.googleapis.com/Gateway"
resource.labels.location="<region>"
resource.labels.gateway_name="<agent-gateway-name>"

The gateway logs also show 403 denials, so "the agent was blocked" and "the agent was slow" stop being the same ticket.

Gotchas

• Low sampling means missing traces. At 0.01, roughly 99 in 100 requests have no trace. Turn on parent-based sampling so the gateway honors the sampled bit from upstream callers.
• No traceparent, no end-to-end view. Check propagation first when a trace starts at the gateway.
• Trace is not the audit trail. Logs carry the allow and deny decisions. Traces carry the path and timing.
• Preview. Treat it as something to pilot, not something to promise customers.

If agents are going to fail in production, it is better to fail where your support team can open one trace and see which hop did it.