fix: populate context_view in pre-execute hooks

[psschwei]

Misc PR

Type of PR

• Bug Fix
• New Feature
• Documentation
• Other

Description

• Link to Issue: Part of REACT agent issue with plugins #920

Populates context_view in the COMPONENT_PRE_EXECUTE payload, which was previously always None.

Testing

• Tests added to the respective file if code was changed
• New code has 100% coverage if code as added
• Ensure existing tests and github automation passes (a maintainer will kick off the github automation when the rest of the PR is populated)

Attribution

• AI coding assistants used

[github-actions]

The PR description has been updated. Please fill out the template for your PR to be reviewed.

[psschwei]

xref #763

[jakelorocco]

I think the payload fix is correct. A few concerns about the tooling hook:

1. Do we care if users set MelleaTool.is_internal=True on their own?
2. We should put this in the public documentation somewhere. Otherwise, we will continuously hit this.
3. A potential solution would also be to document all of our internal tools somewhere (in a constant). Then users can even modify that list / explicitly disallow certain internal tools.

I think 2. above is a blocker for me. I'm willing to punt issues 1 and 3 until we design a comprehensive solution (and maybe is_internal is already that).

My fear is that there will always be new MelleaPrograms (like react) that are either in our actual code base or user implemented and introduce internal tools. Then, there will always be new user hooks that seek to prevent certain tools from executing. is_internal helps but I'm not sure it fully alleviates this situation.

For instance, what if a MelleaProgram called "ResearchAgent" has a tool that the user doesn't add that searches the web. Should that tool be marked as internal? I would argue no.

I'd like to have some criteria for what tools get marked is_internal in the future. A better flag might be something that indicates this tool is used for internal control flow, not data processing.

Claude is the example that I am using to think through all this. It asks permissions for new tools (not necessarily possible here); but importantly it doesn't necessarily ask permission to do things like spin off agents. In Mellea, spinning off those agents would most likely be a tool call.

[nrfulton]

I think it's worth having a broader discussion about the purpose and necessity of hooks.

Hooks are a GOTO.

Hooks should only be used for things that look like Aspects. Logging is (always) the canonical example of an aspect. For agentic systems, I think that "blocking or allowing tool execution based on the application's capabilities" also looks very aspect-y.

(Aside: Things like PII redaction should be done in normal control flow for most applications; I don't really see any substantive benefit to doing that via a level of indirection. My assertion here that PII redaction isn't aspect-y is a strong opinion loosely held; please feel free to disagree here :).)

But the is_internal flag feels like exactly the sort of thing that should be possible to do in the hook system without modifying the existing code base. In this view, access to tool calls is governed by a capability system. That capability system is instantiated by the developer and enforced by the hook system. The internal_tool_call is a capability that the hook system marks certain tools with. The developer can then add that capability marker to the relevant tools when instantiating the hook system and adding the tool call hook.

In other words: we need to associate tools with an internal_tool_call bit, but that tracking should be done by the hook system not the tool class.

[psschwei]

Makes sense. I'll drop the tool change