Problem or Use Case
Hermes currently has plugin hooks for observing tool execution and for injecting extra per-turn context before the next model call, but there does not seem to be a formal hook for transforming a tool result before it is appended back into conversation context.
This feels like a useful missing extension point.
Even with the existing result persistence / turn budgeting protections, tool results can still consume meaningful context and may not always be in the most model-friendly form. A plugin-level transform hook would be helpful for use cases such as:
reducing the effective context footprint of verbose tool outputs
redacting sensitive fields from tool results
normalizing inconsistent return formats across tools
converting raw outputs into a more model-friendly structure or summary
adding compatibility/adaptation layers without wrapping each individual tool
I would be happy to implement this as a PR, but wanted to first confirm whether this is considered in scope for Hermes and whether a focused PR here would have a realistic chance of being merged.
Proposed Solution
Add a dedicated plugin hook for tool-result transformation, rather than changing the semantics of the existing post_tool_call hook.
Roughly, the behavior would be:
a new hook such as transform_tool_result(...)
it runs after tool execution and before the result is appended back into conversation context
returning None keeps the original result
returning a replacement value uses that transformed result instead
hook failures fail open and preserve the original result
post_tool_call remains observational
I think a dedicated hook would keep the API clearer and more predictable than making post_tool_call both observational and mutating.
If this direction looks reasonable, I’d be glad to put together a small, focused PR with tests and docs.
Alternatives Considered
-
Reuse post_tool_call as a mutating hook
I considered this, but I think it would make the API less clear. post_tool_call currently reads like an observer hook, so changing it into a result-rewriting hook could be surprising for existing plugin authors.
-
Use wrapper tools instead
This can work in some cases, but it pushes the problem down to each individual tool and loses the benefit of having one consistent plugin-level extension point.
-
Handle this in pre_llm_call instead
This can inject extra context, but it is not the same as transforming the tool result itself before that result re-enters the conversation. It feels like a less direct and less ergonomic solution.
-
Do nothing / rely only on existing persistence and budgeting
Those protections are helpful, but they do not address redaction, normalization, or semantic transformation of tool outputs before they go back into context.
Feature Type
Other
Scope
Large (new module or significant refactor)
Contribution
Problem or Use Case
Hermes currently has plugin hooks for observing tool execution and for injecting extra per-turn context before the next model call, but there does not seem to be a formal hook for transforming a tool result before it is appended back into conversation context.
This feels like a useful missing extension point.
Even with the existing result persistence / turn budgeting protections, tool results can still consume meaningful context and may not always be in the most model-friendly form. A plugin-level transform hook would be helpful for use cases such as:
reducing the effective context footprint of verbose tool outputs
redacting sensitive fields from tool results
normalizing inconsistent return formats across tools
converting raw outputs into a more model-friendly structure or summary
adding compatibility/adaptation layers without wrapping each individual tool
I would be happy to implement this as a PR, but wanted to first confirm whether this is considered in scope for Hermes and whether a focused PR here would have a realistic chance of being merged.
Proposed Solution
Add a dedicated plugin hook for tool-result transformation, rather than changing the semantics of the existing post_tool_call hook.
Roughly, the behavior would be:
a new hook such as transform_tool_result(...)
it runs after tool execution and before the result is appended back into conversation context
returning None keeps the original result
returning a replacement value uses that transformed result instead
hook failures fail open and preserve the original result
post_tool_call remains observational
I think a dedicated hook would keep the API clearer and more predictable than making post_tool_call both observational and mutating.
If this direction looks reasonable, I’d be glad to put together a small, focused PR with tests and docs.
Alternatives Considered
Reuse post_tool_call as a mutating hook
I considered this, but I think it would make the API less clear. post_tool_call currently reads like an observer hook, so changing it into a result-rewriting hook could be surprising for existing plugin authors.
Use wrapper tools instead
This can work in some cases, but it pushes the problem down to each individual tool and loses the benefit of having one consistent plugin-level extension point.
Handle this in pre_llm_call instead
This can inject extra context, but it is not the same as transforming the tool result itself before that result re-enters the conversation. It feels like a less direct and less ergonomic solution.
Do nothing / rely only on existing persistence and budgeting
Those protections are helpful, but they do not address redaction, normalization, or semantic transformation of tool outputs before they go back into context.
Feature Type
Other
Scope
Large (new module or significant refactor)
Contribution