Add OpenTelemetry exposition

[rakyll]

• Emit baseline metrics, logs, and traces in OTLP.
• Ensure trace context propagation works for outbound calls to tools, agents, etc.
• Ensure trace context propagation works from client to server.

[Siddhant-K-code]

Hey!

Ran into the same requirements building agent-trace. Imho, a couple of things worth deciding early:

• Trace context propagation across async tool calls is the tricky part. W3C traceparent works well, but tool spans that outlive the parent LLM request need to attach to the session root, not the request span.

• For the resumable stream case, tying trace context to the conversationID rather than the stream connection handles reconnects cleanly.

• Also worth aligning to the OTel GenAI semantic conventions (gen_ai.*) from the start, like Datadog, Grafana, and Honeycomb all understand them natively and it saves a mapping pass later.

I've also emailed provided email in readme with more details (but emails are getting bounced with err - We're writing to let you know that the group you tried to contact (ax-dev) may not exist, or you may not have permission to post messages to the group)

[rakyll]

We fixed the permissions issue on ax-dev@google.com, now you can post!

The protocols in AX are most likely to become async after our early refactor of the controller. Long running jobs and span lifetime is definitely something hard to get right -- we initially built linked spans in OpenTelemetry for that but they aren't sufficient in our case because any span could be long running.

We have an instrumentation workstream at Google who is going to help with some of this work, so I'm expecting for us to figure out and/or establish new patterns.

We are also heavily looking into establishing a trajectory format a first class citizen. I think there are big overlaps between trajectories and traces, and trajectory collection could be the troubleshooting signal if we get it right.

[Siddhant-K-code]

Thanks for fixing the permissions, resending the email now <3

The trajectory/trace overlap is rhe same, what I've been thinking about too, In agent-trace, a session captures the full sequence as a structured event log - tool calls, LLM requests, decisions, intermediate state. The troubleshooting signal you're describing is what agent-strace replay & agent-strace why operate on.

Happy to share the event schema if it's useful context for the instrumentation workstream.