GitHub user wenjin272 added a comment to the discussion: [Discussion] Context compaction for Flink Agents
Thanks for the proposal and the follow-up discussion. I suggest starting with **A1, A2, and C1 (#5)**: masking older tool results, truncating individual oversized results, and budget-triggered summarization. This aligns with common context-management capabilities in other agent frameworks. C2 (provider-native compaction) and group D could follow later. I would move **A3 out of this compaction topic**. A round cap controls how long an agent loop may continue; it does not reduce the context sent to the model. Our [[proposed 1.0 priorities](https://github.com/apache/flink-agents/discussions/1327#discussioncomment-19240496)](https://github.com/apache/flink-agents/discussions/1327#discussioncomment-19240496) already include time, round/step, and token budgets, with immediate-stop or final-wrap-up behavior. A3 and its proposed `finish` mode should be designed together with those budget controls. [[#1065](https://github.com/apache/flink-agents/issues/1065)](https://github.com/apache/flink-agents/issues/1065) is also related. For the initial compaction scope, I would focus on context growth **within one logical chat request**, including its entire model/tool-call loop. Users should be able to configure an input-context budget and a trigger threshold, such as 80%, so summarization runs when needed. Repeated summarization can distort earlier task requirements, so we should also define how task instructions, constraints, recent messages, and tool-call/result pairing are preserved. Two supporting pieces seem necessary: - A pre-call token-counting or estimation abstraction, with model/provider-specific implementations where available and an explicitly approximate fallback. It should account for the complete model input, including tool definitions. - Clear behavior when A1, A2, and C1 are enabled together, including their execution order and what history the summarizer reads. A general-purpose configurable strategy pipeline does not need to be a prerequisite. On the six questions: 1. **Configuration name and scope:** I would prefer a dedicated namespace, such as `context-management.tool-results.keep-last-rounds`, rather than `chat.tool-results.keep-last-rounds`. The policy should be scoped to a logical chat request and its loop, rather than configured globally for the job or on the model resource. We should also clearly define “round,” especially when one round contains multiple tool calls. 2. **Placeholder customization:** A standard placeholder should be sufficient for v1. Customization can follow a concrete use case. 3. **Round cap and `finish` mode:** As noted above, both should be covered by the planned agent-loop budget controls. 4. **Group B:** This appears to concern application-managed history or working state across requests. Supporting `MemoryObject.remove`, together with a documented pattern for maintaining bounded state through `set`, seems sufficient initially. Neither `append` nor a typed helper needs to be a prerequisite. I would track this separately as Memory API/documentation work. 5. **Summarizer model:** Default to the chat model used by the request, while allowing an explicitly configured summarizer resource. 6. **Implementation sequence:** I support a hardened PR for A1 and A2, with C1 following under the same context-management design. A3 should move to the budget-control work, B can proceed separately, and C2/D can remain follow-ups. GitHub link: https://github.com/apache/flink-agents/discussions/1202#discussioncomment-19264128 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
