[Feature] Expose compaction integration points for plugins that own model-visible context

[yackimoff]

Summary

It would be useful to expose an explicit integration point before summary compaction mutates the session surface, and possibly a corresponding post-compaction hook.

The main use case is plugins that inject or otherwise own model-visible context: memory systems, workspace instructions, retrieved context, long-lived reminders, or similar components. Such plugins often know more about the semantics of their own artifacts than the generic summarizer does, and may want to deterministically reduce, replace, remove, or re-materialize those artifacts around compaction.

Motivation

Today compaction-basic already performs one specialized model-free reduction before summarization: toolResultPruner.pruneSession() runs before the compactable range is selected and the surface is summarized.

Other plugins can have the same need.

For example, consider a memory plugin that has injected several progressively superseded memory snapshots into the conversation. Before generic summarization, it may be preferable to:

• remove obsolete snapshots from the model-visible surface;
• retain only the current canonical memory state;
• replace large historical injections with small markers;
• or otherwise transform plugin-owned context deterministically before asking an LLM to summarize the remaining conversation.

The same applies to workspace instructions and other context-injection-producing plugins.

The important point is that the plugin that produced an artifact often knows whether that artifact is:

• historical conversation content that should be summarized;
• replaceable state that should instead be folded to its latest value;
• disposable derived context;
• or something that should be re-materialized after compaction rather than summarized.

A generic summarizer cannot reliably infer those semantics from message text.

Why compaction/start / compaction/end are not sufficient

The durable compaction/* events are useful for observation and replay, but they are not currently suitable as mutation hooks for this purpose.

session/event is post-commit, and compaction has already entered its transaction by the time compaction/start is observed. Mutating the surface asynchronously from such a listener can also invalidate the stability assumptions of the in-progress compaction.

Conversely, compaction/end is too late to affect the input that was already sent to the summarizer.

What is missing is an integration point owned by the compaction pipeline itself.

Possible direction

One option would be a generic pre-compaction reduction seam, conceptually something like:

pressure / overflow detected
        ↓
plugin-owned deterministic surface reductions
        ↓
remeasure
        ↓
select compactable range
        ↓
summarize if still necessary
        ↓
commit compaction

The exact API could be a service registry, waterfall hook, reducer collection, or another Cordis-native mechanism. The important properties seem to be:

1. It runs before the final token measurement and range selection used for summarization.
2. It may durably transform model-visible state using normal Session mechanisms.
3. Compaction remeasures after the transformation.
4. Multiple independent reducers can compose deterministically.
5. It is generic rather than tied specifically to tool results.

toolResultPruner could eventually become one consumer of such a mechanism rather than a special case hard-coded into compaction-basic.

A post-compaction integration point could also be useful for plugins that intentionally remove derived context before summarization and want to re-materialize the current canonical state afterward.

Broader rationale

Compaction is not only about making arbitrary conversation text shorter. In an extensible agent harness, part of the model-visible context is often generated by plugins and represents structured state.

Memory systems in particular are likely to accumulate context whose lifecycle is different from ordinary conversation history. The same is true for retrieved context, workspace instructions, plans, runtime context, and other injected artifacts.

Giving their owning plugins a controlled place in the compaction pipeline would allow them to preserve their own semantics while leaving generic summarization responsible for actual conversational history.