feat: telemetry handling and enhance tape stream integration

[PsiACE]

We need to clean this up and discuss it.

In past implementations, we prioritized building tape and then leveraged its OTEL-like characteristics to provide observability. In this new approach, I’ve decided to start with OTEL to construct tape, treating tape as a subset of context that is meaningful to the agent.

In a real-world system, this is a perfectly sensible choice. If you need to integrate any agent, the best approach is not to reimplement the link for each one, but rather to provide views from the observability link.

agent/model/tool semantic action
-> telemetry.record_tape_entry / record_tape_event / record_tape_handoff
-> Logfire/OTel span
-> TapeSpanProcessor
-> TapeSpanExporter
-> tape store

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bub	92b44ab	Commit Preview URL Branch Preview URL	Jun 22 2026, 04:09 AM

[PsiACE]

I’d like to invite @frostming , @yihong0618 , @Gezi-lzq , @scbizu and @yyhhyyyyyy to share your thoughts on this design.

[PsiACE]

Of course, another obvious alternative is to keep the existing solution and continue using the previous export tool to integrate with the otel system, which has worked well so far without any significant issues.

However, the drawback is that if we want to continue scaling and implement tracking in the system, we’ll still need to integrate otel or develop a further wrapper.

[yyhhyyyyyy]

I’d separate two things here.

The tracing direction makes sense to me. Adding first-class spans around the agent/model/tool boundaries seems useful, and narrowing tape into a scoped query/session view also feels like a good cleanup.

Where I’m less convinced is making tape persistence depend on the OTel/Logfire span lifecycle. As far as I can tell from the current implementation, the actual TapeEntry payload is not part of the exported span data. It is passed through the in-process OTel context and then consumed by TapeSpanProcessor.on_end(). So exported telemetry alone cannot reconstruct the tape.

That makes OTel feel more like a local append trigger here, while tape correctness becomes coupled to telemetry behavior.

If the goal is an OTel-first tape, I think the design needs to spell out a few things: how the tape data stays self-contained, what happens with sampling/batching/failures, and what requirement cannot be met by writing tape directly while emitting spans alongside it.

The tracing spans already give us an OTel integration layer for observability, so I’m not sure that requires inverting the write path itself.

[scbizu]

Thanks for inviting . I'd happy to see the OTel integration for bub's tape-native processor and exporter .

However , hiding the entry/anchor under the span also means adding more complexity to the new-ins and maintenance. I like your idea that treat the tape as trace-able storage as it is , in my opinion , just keep the export tool to sync entry as span is just enough . Adding more logic in the exporter is more valuable than breaking bub cores , I suppose that there will be something like agent trace spec (which will be prompted by the frontier LLM provider) soon and with this we can let the trace skill as model built-in ability (depends on when will LLM providers recognize that trace really increases the token efficiency).

BTW, I am currently cooking another tape Go solution and has some thoughts like you , and the handshaking/communication between tape-native agents is also the one of goals. I am currently testing to use Google A2A to share entries between each , but the result was not luck enough :( , maybe I can take some ideas from this PR to depend on the export tool .