Plugins - High level SDK features#530
Conversation
Documentation Deployment CompleteYour documentation preview has been successfully deployed! Preview URL: https://d3ehv1nix5p99z.cloudfront.net/pr-530/ |
|
|
||
| Hook Providers ultimately solve our problem since they are composable, provide the necessary functionality to integrate rich features throughout an agents execution, and have been battle tested by many of our existing **high-level abstractions**. | ||
|
|
||
| One problem with `HookProviders` is that their name does not best communicate what they are positioned to do. Their name overlaps with the **low-level primitives** hooks, so it can be not-so intuitive when applying a high-level feature, like Anthropic Skills, through a `hooks` parameter (see code below). I propose that we create a new `Plugin` concept, and a `plugins` agent init parameter, as plugins are a common term in the industry to represent adding new functionality to a system. |
There was a problem hiding this comment.
nit: skills is also cross-component. it'd be hooks, system prompt, tools, etc.
| These features all have similar responsibilities, and the differences between them are nuanced, so here are definitions to explain what they do: | ||
|
|
||
| - **Hooks**: A low-level primitive of the Strands SDK. A hook is a mechanism to execute code at a specific lifecycle event in the SDK, and gives relevant context at that specific lifecycle event in order to change the standard agents behavior. | ||
| - **HookProvider**: A provider of hooks, with some convenience methods to make it easy to apply hooks to an agent. |
There was a problem hiding this comment.
I see HookProvider as just an implementation detail. With the @hook decorator, that should just be sth behind the scenes
|
|
||
| Just about every `Plugin` in Strands will depend on hooks, but a `Plugin` represents the application of a behavior to an agent, not a targeted change at a lifecycle event. `HookProviders` serve a similar role, so below is a code example comparing the two: | ||
|
|
||
| ```python |
There was a problem hiding this comment.
I think this is the wrong example here. I'd continue with skills. It's cross-component. This use case is better with hooks, in fact much better with decorator
@hook
def myhook(event: BeforeInvocationEvent | AfterInvocationEvent):
print(f"{event.agent.name} is current at {event.__class__}")| agent = Agent(plugins=[LoggingPlugin()]) | ||
| ``` | ||
|
|
||
| This comparison of `HookProvider` to a `Plugin` shows that the devex is essentially the same (same lines of code), meaning that as a customer it would be confusing why to choose one over the other; and there aren't many good reasons to (please suggest if you do have some). As such, I'm proposing that we deprecate `HookProvider` in favor of `Plugin` moving forward. There is a world where `Plugins` can depend on `HookProviders`, and extend the behavior, but I think this leads to more indirection rather than proper abstractions. |
There was a problem hiding this comment.
I think the start of the doc is right, but you diverge here a bit. We don't need to replace hooks. It's a core, good concept that allows a lot of use cases.
The problem is these features that is just not just a hooks provider that we can vend, or just a tool. If it's something like skills where it needs to add a tool, update system prompt, etc. Those should be plugins.
I like the definition, but we don't need to compare it with hooks, and we don't need to remove hooks. Plugins will need hooks. Probably one of the first things you do as a plugin is register some hooks
| # Appendix | ||
|
|
||
| ## Persisting the state of Plugins | ||
| The Session Manager has the responsibility of persisting and restoring the state of an agent, along with any attached plugins. The recommended way to accomplish this for now would be to have plugins maintain their state in the `agent.state`. Then during initialization, session manager would restore `agent.state`, and each plugin could restore themselves in turn from `agent.state`. |
There was a problem hiding this comment.
can't we just have those support snapshottable interface? if they want to? we can just load them back
3 participants
Proposal for a way to introduce high-level features that have behavioral impact to an agents execution.