Summary
Add unified, standards-based observability to every wrapper in this monorepo — a2a-claude, a2a-copilot, a2a-codex, a2a-antigravity, and a2a-opencode — using OpenTelemetry (OTEL).
Today, each underlying backend (Claude Agent SDK, GitHub Copilot SDK, OpenAI Codex SDK, Google Antigravity SDK, OpenCode) has its own patchwork of logging, tracing, and usage-reporting conventions — some native, some missing entirely. a2a-wrapper sits in front of all of them behind a single A2A protocol surface, which makes it the natural place to give teams one consistent way to observe every agent backend they run, regardless of which one is doing the work underneath.
Why this matters
- One protocol, one observability story. Orchestrators and platform teams already get a uniform A2A interface across five different AI coding agents. Today they don't get a uniform way to observe them — traces, token/cost usage, tool-call activity, and failures all look different depending on which backend is running behind the wrapper.
- Production readiness. Running Claude Code, Copilot, Codex, Antigravity, or OpenCode as always-on A2A services means teams need real answers to "what did the agent do, how long did it take, what did it cost, and where did it fail?" — without having to build bespoke tooling per backend.
- Industry-standard, vendor-neutral. OpenTelemetry is the emerging standard for AI agent and GenAI observability (traces, metrics, and logs), with broad backend support (Grafana, Datadog, Honeycomb, SigNoz, and any OTLP-compatible collector). Building on OTEL means
a2a-wrapper users aren't locked into any single observability vendor.
- Zero cost when unused. Observability should be entirely opt-in and impose no overhead on users who don't need it — a host application should be able to enable it, or leave it off, without touching wrapper behavior.
Scope
This issue tracks adding OTEL-based observability as a first-class, cross-cutting capability shared by all five wrappers via @a2a-wrapper/core, covering:
- Distributed tracing across the full task lifecycle for each agent backend
- Standardized metrics (usage, latency, and outcome signals) that are comparable across backends
- A consistent, opt-in approach to sensitive-data handling in exported telemetry
This was previously called out as a roadmap item in the root README ("OpenTelemetry observability — optional distributed tracing/metrics for task lifecycle and HTTP requests... Not yet implemented"). This issue formally tracks that work.
Non-goals for this issue
This issue is intentionally scoped to what we're building, not how. Implementation design (module boundaries, per-backend integration approach, config schema, etc.) will be worked out separately and doesn't need to be resolved here.
Summary
Add unified, standards-based observability to every wrapper in this monorepo —
a2a-claude,a2a-copilot,a2a-codex,a2a-antigravity, anda2a-opencode— using OpenTelemetry (OTEL).Today, each underlying backend (Claude Agent SDK, GitHub Copilot SDK, OpenAI Codex SDK, Google Antigravity SDK, OpenCode) has its own patchwork of logging, tracing, and usage-reporting conventions — some native, some missing entirely.
a2a-wrappersits in front of all of them behind a single A2A protocol surface, which makes it the natural place to give teams one consistent way to observe every agent backend they run, regardless of which one is doing the work underneath.Why this matters
a2a-wrapperusers aren't locked into any single observability vendor.Scope
This issue tracks adding OTEL-based observability as a first-class, cross-cutting capability shared by all five wrappers via
@a2a-wrapper/core, covering:This was previously called out as a roadmap item in the root README ("OpenTelemetry observability — optional distributed tracing/metrics for task lifecycle and HTTP requests... Not yet implemented"). This issue formally tracks that work.
Non-goals for this issue
This issue is intentionally scoped to what we're building, not how. Implementation design (module boundaries, per-backend integration approach, config schema, etc.) will be worked out separately and doesn't need to be resolved here.