.NET: [Feature]: Add agent-triggered in-run compaction #9379

Problem

Agent Framework already supports in-run compaction before model calls, but compaction is initiated only by developer-configured strategy conditions. An agent cannot request compaction at a semantic boundary such as moving from planning to execution or finishing work that required a large skill.

The missing capability is not another compaction implementation. It is a safe way for an agent to trigger an existing strategy while the application continues to control what that strategy removes and how it reduces context.

Use Case and Evidence

A long-running agent may load skills, gather large tool results, complete planning, and then know that earlier context is no longer needed. Automatic token or message thresholds cannot identify that phase transition.

The agent should be able to call a dedicated trigger tool after the relevant workload-tool batch completes. Before the next model call, Agent Framework runs the developer-selected compaction strategy against the in-flight context.

The trigger is control-plane context and should not consume strategy retention counters such as keep_last_tool_call_groups. It should be called in a separate tool batch so the preceding workload batch remains independently compactable.

Desired Outcome

Provide equivalent Python and .NET support for an agent-triggered compaction wrapper that:

• Wraps one existing compaction strategy.
• Exposes one explicitly registered trigger tool.
• Runs the wrapped strategy after that trigger completes and before the next model call.
• Temporarily excludes the trigger group while the inner strategy runs so retention counters apply only to workload context.
• Restores the trigger group by default, with an option to exclude it when another checkpoint or summary remains.
• Preserves atomic function-call/result and reasoning groups.
• Keeps persisted-history behavior out of scope.

Alternatives Considered

CompactionProvider integration

This is an in-flight function-loop capability, not context-provider or persisted-history management.

Session-state flag

Compaction strategies currently receive messages rather than the session, and session state has the wrong lifetime: it may persist across runs and introduces concurrency concerns.

Direct message selection by the agent

This would duplicate existing compaction policy and grouping logic. The agent should choose when to compact; the configured strategy should continue to choose what and how.

Counting the trigger as a normal tool group

This makes settings such as keep_last_tool_call_groups=1 preserve the trigger instead of one workload tool group. The wrapper should temporarily hide the trigger from the inner strategy.

Proposed Direction

Introduce an agent-triggered strategy wrapper. Conceptually:

triggered = AgentTriggeredCompactionStrategy(existing_strategy)
agent = Agent(
    ...,
    tools=[triggered.tool],
    compaction_strategy=triggered,
)

The default tool is compact_context. Specialized strategies may supply a trigger-tool factory so there is still exactly one exposed tool. The first specialized strategy should unload skill context through unload_skill, accepting one skill name, a sequence of names, or no names to unload all.

Trigger tools should instruct the model to call them alone after workload tools complete. If a trigger nevertheless appears in a mixed parallel batch, the batch must remain atomic and unrelated calls/results must not be removed.

Implementation work is tracked by Python and .NET subissues.

Scope and Non-Goals

• No persisted-history mutation.
• No dependency on CompactionProvider.
• No agent-facing message IDs or arbitrary transcript editing.
• No agent selection of the configured strategy.
• No splitting provider-atomic mixed tool batches.
• No service-side compaction protocol in this feature.

Language

Both

Contribution Intent

I can help with implementation or testing

Acknowledgements

• I searched existing issues and did not find a duplicate.
• I will wait for explicit maintainer agreement before starting implementation of a non-trivial change.