Trace Capsules: Agent-to-Agent Issue Reporting

Earlier this month I started wondering why agent usage data wasn’t yet shared between clients and vendors to improve the user and agent experience.

I came back to this idea recently while working on @opentraces’ upcoming replayable env features, and started playing with a narrower version of agent usage data portability: Trace Capsules.

The premise

Working on and with open source should be a competitive advantage with AI.

Today, open source context should mean even more speed for open projects, particularly as we figure out the mechanics of collaborating at warp speed compared to closed-source competitors.

One place this matters: agent-to-agent debugging. This is likely the next frontier of open source collaboration.

In this case, it is about speeding up the async work between a dev agent, like Pi, Claude, or Codex, and a maintainer agent, like the bot behind issues and PRs. This is a case of asymmetric context and objectives. The client knows most about their use case. The vendor knows most about the library and the surrounding issue history.

Today, when an agent hits a bug in an upstream framework or library, it can already open an issue with prose, logs, reproduction steps, or a PR.

But the maintainer’s agent still has to reconstruct what happened.

That communication is lossy, and it is breaking under the new exponential demand in volume and speed.

Source: GitHub availability update

The idea

A Trace Capsule makes the issue replayable by packaging the useful slice of the failing session:

• what the agent tried to do: action_trajectory
• what it knew and saw: ctx_tree
• where it failed: trace_step
• and the repo state it failed against: git snapshot

With an open repo as the anchor, this is all open data. And that open data becomes the replayable test.

Note: @opentraces already provides the tooling for your local agent to scrub and review traces before sharing them, including anonymising, PII filters, and security scanning, so you can trust the capsule contains the signals without the sensitive data.

A maintainer’s agent can pull the capsule attached to an issue, re-pose the same intent against the snapshot after the fix, and use it to close off the issue. It can also collect helpful usage data and use it to improve the agent experience.

The added bonus is having evaluation metrics beyond “did the task finish,” because agent developer experience is often about process reliability rather than brute-force success.

Finally, the client agent can subscribe to the issue and automatically unblock the work when it is resolved.

Closing notes

I have been running experiments among my internal dependencies, and have found a lot of value in passing these context capsules around. In a way, because I am the dev behind both sides, I was manually doing this process anyway when dealing with my own upstream.

It is not a very VC-hype pitch, but it is a form of high-bandwidth agent-to-agent collaboration that can really make a difference.

Originally published as an article on X.