[Feature]: Configurable conversation history strategy for AgentExecutor #4038

What problem does it solve?

Currently, AgentExecutor forwards the entire chat history to downstream agents without any mechanism to filter, truncate, or summarize the conversation context.

• After each run, the full conversation is snapshotted: _full_conversation = list(self._cache) + response.messages
• The AgentExecutorResponse.full_conversation is passed downstream
• The receiving agent replaces its cache with the full prior conversation in from_response()
• Every downstream agent receives the complete conversation from the start

This leads to:

• Token limit failures — long conversations exceed model context windows, causing failures or silent truncation by the LLM provider
• Increasing cost — every hop re-sends the full history, compounding token usage as the conversation grows
• Irrelevant context — not all agents need the full history; a specialist agent may only need recent relevant turns
• No user control — there's no built-in way to configure history windowing, summarization, or per-agent filtering

What would the expected behavior be?

• A configurable history strategy on AgentExecutor that controls what portion of the conversation is forwarded to downstream agents
• It would be great to support simple filtering options like keeping only the first N messages (to preserve the original user intent / system context) or the last N messages (to keep only the most recent and relevant turns), or a combination of both
• Per-agent message filtering via a message_filter or history_transform callback for more advanced use cases (e.g., summarization)
• Builder-level options like .with_history_strategy(...) on workflow builders
• Declarative workflow support — this would be especially valuable in declarative (YAML-defined) workflows, where users can't write custom code to manage history. A declarative history_strategy property would make this feature accessible without code

Are there any alternatives you've considered?

Currently I am creating a custom executor that manually truncates the cache before calling the agent to work around this, but it would be nice if the framework supported this directly out of the box.

Additional context

AutoGen used to address this problem through message filtering mechanisms. It would be great if we could think of a better, more integrated approach for the Agent Framework — perhaps one that works seamlessly with both programmatic and declarative workflows.