@Jeremiah @Nate I needed to extend the interaction tool and I had to find a way. The nicest way I've found so far was to drop the

interactive=

argument and replace with

handlers=[InteractionHandler()]

instead, serving both as a wrapper for

PrintHandler

, and a as a factory for the

InteractionTool

(formerly

cli_input

). What do you think of this approach? 👉 This is quite urgent for me - had me blocked mid integration. The whole purpose of this is to be able to extend the interaction layer at will, and not limit it to a shell interface, but open the doors to other possibilities such as any X Y chat messaging interface. Another goal is that of implementing commands (which I did), but I am still exploring nice ways onto how commands, and other entities, can interact with the runtime. Please give feedback. I can submit a PR for both, with complete test coverage

hi @Constantin Teo - imo if you have a PR that's the best way to get feedback!

I don't, I need to write it and considering if its worth the effort before going with the approach. Very experimental

i like the sound of your proposed approach, but @Jeremiah has spent more time here so I dont want to offer half baked thoughts

yup I think we need him for direction - to me this is quite a feature that shapes the vision of it

do you have a public fork?

I'll add you as collab to the private one

sorry, I probably wont have time to grok your repo in short order if things are urgent. happy to help how I can w a PR or otherwise

if @Jeremiah likes the idea I'll open a PR

We've weighed a bunch of different approaches here and never found a good one-size fits all to the point that I almost view the current CLI implementation as an example more than a definitive guide to how to do it. In practice I've found it easier to give an agent a task to generate a response, then handle that "normally" in my application, retrieving a user response, and reengaging the agent, than seeking to do it entirely inside the tool-use loop. But I agree I'd like the agent to be able to do more. I think the question is: • what does the framework need to provide thats different from what it currently does (e.g. currently the agent invokes a tool and now anything can happen as long as the tool ultimately returns a string value) This reminds me I need to push a release with the event streaming stuff, it seems to work well