feat: implemented pruning conversation manager

[roeetal]

Description

Implement Pruning conversation manager to prune messages in the agent conversation history. Heuristic pruning strategy implemented for tool responses that are too long.

Related Issues

#556

Documentation PR

strands-agents/docs#229

Type of Change

New feature

Testing

How have you tested the change? Verify that the changes do not break functionality or introduce warnings in consuming repositories: agents-docs, agents-tools, agents-cli

• I ran hatch run prepare

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[Unshure]

I see the value in pruning tool result messages that exceed some threshold, but there seems to be a lot more going on in this feature, and Im not even sure that the conversation manager is the right place for this logic to live.

A feature like this makes a bit more sense as a hook in my mind: https://strandsagents.com/latest/documentation/docs/user-guide/concepts/agents/hooks/#hook-event-lifecycle

We have some lifecycle events, like AfterModelCallEvent and AfterToolCallEvent, where a hook can intercept the result of the model or tool and prune it to be shorter.

With the current design of conversation managers, they are basically just error handlers and are not well suited to be proactive context managers. We do plan to improve upon this in the future, and update them to use hooks, but until then I think this feature makes more sense as a hook.

[roeetal]

I see the value in pruning tool result messages that exceed some threshold, but there seems to be a lot more going on in this feature, and Im not even sure that the conversation manager is the right place for this logic to live.

A feature like this makes a bit more sense as a hook in my mind: https://strandsagents.com/latest/documentation/docs/user-guide/concepts/agents/hooks/#hook-event-lifecycle

We have some lifecycle events, like AfterModelCallEvent and AfterToolCallEvent, where a hook can intercept the result of the model or tool and prune it to be shorter.

With the current design of conversation managers, they are basically just error handlers and are not well suited to be proactive context managers. We do plan to improve upon this in the future, and update them to use hooks, but until then I think this feature makes more sense as a hook.

r.e. hooks, they are inappropriate as conversation managers manage the entire context, including older messages. Hooks are focused on specific actions before and after message creation/addition to context.

agents are stateful. conversation managers, by default, are not, as they operate solely on the agent based on its state. conversation managers might need state management should their business logic require state tracking, which currently is not the case.

[codecov]

Codecov Report

❌ Patch coverage is 85.90604% with 21 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...nversation_manager/mapping_conversation_manager.py	87.94%	7 Missing and 10 partials ⚠️
src/strands/experimental/__init__.py	33.33%	4 Missing ⚠️

📢 Thoughts on this report? Let us know!