Expose structured observability when Agent context compaction rewrites history

Start at the existing TieredCompaction capability and the session snapshot path that persists rewritten history. Trace how a compaction result can be identified as an actual rewrite, then check existing server-side logging and tests around agent runs. Done means a delegated compaction operation emits the proposed fields only when history changes, without altering compaction behavior or public APIs.

Self Checks

• I have read the Contributing Guide and Language Policy.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

When an Agent run approaches its configured context budget, TieredCompaction may rewrite the message history before the next model request. The rewritten history can then be persisted in the session snapshot.

From an operator's perspective, this creates a debugging challenge: the history may become shorter or be summarized without a corresponding runtime signal. It is difficult to answer whether compaction happened, what the context size was before and after, or whether a later behavioral change was related to context rewriting.

Today, this behavior can only be inferred indirectly by comparing history shapes or by reading the compaction implementation. A structured runtime signal would make production diagnosis and testing much easier.

2. Additional context or comments

A possible low-impact direction would be to wrap the existing TieredCompaction capability with an observability adapter. The adapter would delegate to the original compaction implementation unchanged and emit a server-side log only when the history is actually rewritten.

Useful fields could include:

• run_id
• target_tokens
• before_message_count
• after_message_count
• before_estimated_tokens
• after_estimated_tokens
• tier, which may initially be unknown at the top-level compaction boundary

This would not change compaction triggering, token estimation, history retention behavior, or public APIs. It would only improve diagnosability. A UI-facing event can be considered separately if maintainers think it is useful.

3. Can you help us with this feature?

• I am interested in contributing to this feature.