Feature Request: Native OpenTelemetry trace export for agent interactions

[kylehounslow]

Feature Request: Native OpenTelemetry trace export for agent interactions

Problem

Kiro CLI and IDE perform complex agentic workflows — LLM calls, tool invocations, file operations, reasoning steps — but there's no way to export structured telemetry about these interactions. Users building AI-powered applications need to understand agent behavior, debug failures, and measure performance using the same observability tooling they use for the rest of their stack.

Proposed Solution

Export OTLP traces for Kiro agent sessions using the OpenTelemetry GenAI Semantic Conventions.

What to trace

Span	Key Attributes
Agent session	gen_ai.system, gen_ai.request.model, session duration
LLM call	gen_ai.usage.input_tokens, gen_ai.usage.output_tokens, gen_ai.request.temperature, latency
Tool/MCP invocation	tool name, parameters (redacted), success/failure, duration
File operations	path, operation type, result

Configuration

Follow standard OTel SDK conventions — env vars only, zero config files:

export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318
export OTEL_SERVICE_NAME=kiro-cli
kiro chat

When OTEL_EXPORTER_OTLP_ENDPOINT is unset, no traces are exported (zero overhead by default).

Example trace

[agent_session] kiro-cli chat (12.4s)                          — gen_ai.system: anthropic
  ├── [invoke_agent] Kiro Agent (12.1s)                        — gen_ai.request.model: claude-sonnet-4, gen_ai.agent.name: Kiro Agent
  │   ├── [gen_ai.chat] claude-sonnet-4 (2.1s)                — gen_ai.usage.input_tokens: 890, gen_ai.usage.output_tokens: 210, finish_reason: tool_calls
  │   ├── [execute_tool] fs_read (45ms)                        — gen_ai.tool.name: fs_read
  │   │   └── [tools/call] fs_read (38ms)                      — SPAN_KIND_CLIENT
  │   ├── [gen_ai.chat] claude-sonnet-4 (3.8s)                — gen_ai.usage.input_tokens: 1240, gen_ai.usage.output_tokens: 520, finish_reason: tool_calls
  │   ├── [execute_tool] execute_bash (1.2s)                   — gen_ai.tool.name: execute_bash
  │   │   └── [tools/call] execute_bash (1.1s)                 — SPAN_KIND_CLIENT
  │   ├── [gen_ai.chat] claude-sonnet-4 (4.2s)                — gen_ai.usage.input_tokens: 2100, gen_ai.usage.output_tokens: 380, finish_reason: stop
  │   └── [execute_tool] fs_write (12ms)                       — gen_ai.tool.name: fs_write
  │       └── [tools/call] fs_write (8ms)                      — SPAN_KIND_CLIENT
  └── [http send] response (5ms)

Why this matters

1. Debugging — When Kiro makes unexpected changes or takes a wrong path, traces let users see exactly what happened: which model was called, what tools were invoked, and where time was spent.
2. Composability — Users running Kiro as part of larger agentic systems (CI pipelines, automated workflows) need traces that connect to their existing observability backends (Jaeger, Grafana, OpenSearch, etc.).
3. Dogfooding — AWS ships OpenTelemetry (ADOT, CloudWatch, X-Ray). Kiro should emit the same telemetry it helps users instrument.
4. GenAI semconv adoption — The OTel GenAI semantic conventions are stabilizing. Native support in a widely-used AI coding tool drives adoption and validates the spec.

Prior Art

• Claude Code Monitoring / OTLP Support
• OpenSearch Agent Health — open-source observability and evaluation for AI agents
• OpenSearch observability-stack — OTel-native observability platform with first-class GenAI semantic convention support
• Strands Agents SDK — native OTel trace export for agent interactions
• OpenLLMetry — auto-instrumentation for LLM frameworks
• Arize Phoenix — LLM observability with OTel-compatible traces

Non-goals

• Custom UI or dashboard — users bring their own backend
• Logging/metrics export — traces first, expand later
• Always-on telemetry — opt-in only via env vars

[github-actions]

Thanks for opening this issue and for such a thorough, well-structured proposal! The idea of integrating native OpenTelemetry trace export for agent interactions — covering LLM calls, tool invocations, and session-level telemetry — would be a fantastic addition to Kiro's observability story. A maintainer will take a look at this soon. We really appreciate you taking the time to lay out the semantic conventions, configuration approach, and example traces — this kind of detail makes it so much easier to evaluate and move forward! 🙌

[BryanChasko]

for reference, OTEL in gemini cli 😏 https://geminicli.com/docs/cli/telemetry/ ♊

[BryanChasko]

Following up on this. I'm running 71 custom agents across kiro-cli and have had to build a hooks-based observability layer to get basic session visibility:

• agentSpawn hooks that log agent name, model, and type to JSONL + send OTEL spans to a self-hosted Jaeger instance
• preToolUse hooks on use_subagent to trace delegation chains between agents
• Static welcomeMessage fields with model identifiers because there's no native model display in the CLI prompt

This works for what it covers (spawn/stop events, delegation logging), but it cannot reach the signals that matter most: token usage per turn, LLM call latency, and error rates. Those live inside kiro-cli's runtime and are not exposed to hooks or any user-facing surface.

For reference, Gemini CLI ships OTEL support with GEMINI_CLI_OTEL_EXPORT_ENDPOINT and traces LLM calls, tool invocations, and token counts out of the box. Claude Code does the same via CLAUDE_CODE_ENABLE_TELEMETRY. Both follow the GenAI semantic conventions from OpenTelemetry.

The hooks workaround proves there's demand for this data. Native OTEL export would replace ~200 lines of shell scripts and hook wiring across 71 agent configs with a single env var.

[krisdyna]

Agreed with @BryanChasko.

From the Observability side, it would be great to accept OTLP endpoint and respect JSON and protobuf during implementation of this.
Support via configurable flags:

• application/x-protobuf — binary Protobuf (mandatory baseline)
• application/json — JSON Protobuf mapping (optional, server support not guaranteed)
• gRPC

See an example discussion here:
google-gemini/gemini-cli#23093