[FEATURE] Automatic Context Optimization strategy

[lizradway]

Problem Statement

Today, opting into context management best practices requires understanding and configuring multiple components independently:

agent = Agent(
    conversation_manager=SlidingWindowConversationManager(
        window_size=40,
        should_truncate_results=True,
        per_turn=True,
    ),
    plugins=[
        ToolResultExternalizer(
            storage=InMemoryExternalizationStorage(),
            max_result_chars=10_000,
            preview_chars=4_000,
        ),
    ],
)

Users need to know which conversation manager to use, what parameters are sensible, that the externalization plugin exists, what storage backend to pick, and how all these pieces interact. This violates "the obvious path is the happy path" — there's no simple way to say "just manage my context well."

Proposed Solution

Design a one-liner that enables an opinionated, best-practice context management strategy:

# Option A: Agent parameter
agent = Agent(context_management="auto")

# Option B: Preset/factory
agent = Agent(conversation_manager=AutoContextManager())

# Option C: Plugin that bundles everything
agent = Agent(plugins=[SmartContext()])

The "auto" strategy would internally compose:

• SlidingWindowConversationManager with sensible defaults (or a future improved manager)
• ToolResultExternalizer with in-memory storage
• Potentially future additions (summarization, token estimation, eviction) without requiring user changes

The key design questions:

• Should this be a new Agent parameter, a conversation manager variant, or a plugin?
• How does it interact with explicit conversation_manager= settings? (conflict? override? compose?)
• What are the "sensible defaults" and should they adapt to the model's context window size?
• How do users customize one aspect (e.g., file storage for externalization) without losing the rest of the bundle?

Use Case

1. New users — Someone building their first agent who doesn't want to think about context management. One line gives them production-grade defaults that "just work."

2. Prototyping — Rapid iteration where context blowups are a distraction. Auto-management handles it so the developer can focus on tool/prompt design.

3. Long-running agents in production — Agents that run for hours with many tool calls. Today these require careful tuning of window sizes, truncation, and externalization. A single opt-in that bundles best practices reduces configuration burden and ensures new improvements (e.g., better eviction strategies) are adopted automatically.

4. SDK evolution — As the SDK ships new context management features (summarization, token-based windowing, eviction), users on the "auto" path get improvements without changing their code. Users who configured components manually must update themselves.

Alternative Solutions

• Better documentation — Instead of sugar, provide a "recommended setup" guide. Pro: no new API surface. Con: users still need to copy-paste boilerplate, and it goes stale as best practices evolve.

• Agent-level defaults that are smarter — Instead of a new opt-in, make the default Agent() behavior include externalization and proactive management. Pro: zero config. Con: breaking change for existing users who rely on current default behavior (no externalization, reactive-only truncation). Violates "pay for play."

• Preset factories — Agent.with_preset("long_running") or Agent.for_coding_agent(). Pro: discoverable, can have multiple presets. Con: naming is hard, presets proliferate, unclear which to choose.

• Plugin that composes other plugins — A meta-plugin like SmartContext() that internally registers the externalization plugin and configures the conversation manager via init_agent. Pro: fits the plugin model, composable with other plugins. Con: plugin modifying the conversation manager feels like overreach — it crosses the boundary between plugins (optional behavior) and core agent config.

• Configuration profiles — A YAML/dict-based config that bundles multiple settings: Agent(profile="optimized_context"). Pro: extensible. Con: indirection, harder to type-check, non-Pythonic.