Add conversation compaction as an Agents API runtime capability

[chubes4]

Problem

Long-running agent conversations eventually outgrow model context windows. Without a shared compaction layer, each agent runtime, transport wrapper, or product integration has to invent its own behavior for trimming, summarizing, or replaying conversation history.

That leads to inconsistent and risky behavior:

• older context may be silently dropped instead of summarized
• tool-call / tool-result pairs can be split incorrectly
• clients may not know that a transcript boundary was compacted
• persisted transcripts may diverge from the context actually sent to the model
• transport adapters can stream agent output while missing runtime lifecycle events such as compaction start/end

Agents API is meant to be the runtime substrate, so conversation compaction should be modeled as a first-class runtime capability rather than an implementation detail hidden inside individual agents.

Proposal

Add a public conversation compaction contract to Agents API.

Suggested shape:

• agent capability/config flag, e.g. supports_conversation_compaction
• compaction policy/config, e.g. thresholds, recent-context budget, summary model/provider selection
• runtime service/hook that transforms a transcript before model dispatch
• structured lifecycle events, e.g. compaction_started, compaction_completed, compaction_failed
• transcript metadata recording compacted boundaries and generated summaries

The API should define behavior, not prescribe one summarizer implementation.

Expected Behavior

A shared implementation should:

• preserve the most recent conversation turns verbatim
• summarize older turns into an explicit synthetic summary message or equivalent transcript artifact
• avoid cutting through tool-call / tool-result boundaries
• fail safely if summarization fails, preferably without silently discarding transcript data
• expose compaction state to streaming clients so UI and agent-to-agent transports can relay what happened
• keep persisted transcript state understandable after compaction

Why This Belongs In Agents API

Conversation compaction is not product-specific. It is a runtime concern that any durable, tool-using agent will hit once conversations become long enough.

If Agents API does not provide the contract, every consumer will need local policy decisions around:

• when to compact
• what to summarize
• how to represent summaries in the transcript
• how to preserve tool-call integrity
• how to surface compaction to clients
• how to persist compacted transcript boundaries

That is exactly the kind of repeated substrate logic Agents API should centralize.

Non-Goals

• This does not require Agents API to own low-level model execution.
• This does not require one specific summarization prompt or provider.
• This should not expose private implementation details from any consuming product.
• This should not be a generic memory-management feature; it is specifically about live conversation transcript compaction before or during agent execution.

Acceptance Criteria

• Agents can declare whether they support conversation compaction.
• The runtime has a documented compaction policy/extension point.
• Transcript compaction preserves safe message boundaries, especially around tool calls and results.
• Streaming clients can observe compaction lifecycle events.
• Persisted transcripts retain enough metadata to explain where summaries replaced earlier messages.
• Tests cover at least: below-threshold no-op, successful compaction, summarizer failure, and safe boundary selection around tool calls.