A2A History Should Replay Speech, Not Tool Output

An agent-to-agent thread has two audiences: the next agent turn needs a clean conversation, while the human operator needs evidence of what each agent actually did. Treating both audiences as one transcript creates a subtle failure mode: raw tool output starts masquerading as dialogue.

APX separates those concerns. A peer receives the messages that participants said. Tool execution remains attached to the reply as trace metadata, available for inspection without being replayed as conversation.

The thesis is simple: preserve tool traces for accountability, but do not spend conversational context on them.

How a useful thread becomes noise

Consider an APX A2A exchange:

reviewer -> opencode: Check the rendering issue.
opencode -> tool: npm run lint
opencode -> tool: a complete HTML document
opencode -> reviewer: Fixed and verified.
reviewer -> opencode: Continue with the mobile view.

If APX rebuilds history by selecting every row shared by those two participants, the next prompt may include the lint output and full HTML document as if they were earlier messages. The peer must then recover six words of intent from thousands of characters of exhaust.

This is worse than cosmetic clutter. Tool output can dominate the context window, obscure decisions, and make an agent infer that machine-generated data was something a participant intentionally said. A long-running collaboration gradually becomes less coherent even though every individual tool call succeeded.

APX therefore filters A2A history to conversational rows. Earlier requests and final replies survive. Raw tool-result rows do not enter the reconstructed dialogue.

Keep evidence, change its lane

Filtering tool output from history must not make agent work invisible. A final reply such as "fixed and verified" is only a claim unless the operator can inspect the actions behind it.

APX keeps the tool trace on the agent reply's metadata. The thread viewer can expose that trace as an action group: which tools ran, their arguments, and their results. A reply with no tool calls carries no action group. That difference helps a human distinguish completed work from an unsupported assertion.

One event now serves two views without corrupting either:

• conversational text becomes future agent context;
• trace metadata becomes operator evidence.

The trace remains connected to the reply that produced it, but it is not promoted into the next turn's prose.

APC and APX own different parts

Agent Project Context (APC) is the portable context layer. It stores durable project instructions, agent definitions, skills, and safe shared facts in AGENTS.md and .apc/. Those artifacts explain how agents should work across tools and machines.

APX is the daily-use runtime and tooling layer. It executes A2A turns, stores local message history, runs tools, and shapes the thread shown to an operator. Tool traces and runtime transcripts belong there because they describe machine-local execution, not portable project truth.

This boundary matters. Copying raw A2A traces into APC would turn a stable project contract into an ever-growing activity log. Dropping traces entirely would make runtime claims hard to verify. APX can retain them locally while APC stays clone-safe.

A practical rule for agent systems

When designing multi-agent history, ask what each record is for.

A user request, delegation, decision, or final answer belongs in replayable dialogue. A shell dump, file body, HTTP response, or intermediate tool envelope belongs in an execution trace. Both may need persistence, search, and a UI, but they should not automatically share a prompt budget.

This separation gives future turns better signal and gives humans better evidence. Clean context and auditability are not competing goals. They only conflict when one storage shape is forced to do both jobs.