Replies: 1 comment
-
|
@yangrudan @LuigiGonnella @doroteaMonaco it would be very helpful, if you give your opinion on this. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Discussion: Progress updates from long-running tools
Hi everyone,
While going through the MoFA codebase and trying to understand how tool execution works, I noticed that tools currently behave like atomic operations — they run and then return a single result at the end.
From what I saw, the
ToolExecutortrait looks like this:So the agent calls the tool, waits for it to finish, and then uses the returned value.
For most tools this seems totally fine, but I was wondering about long-running tools like web scraping, shell commands, or heavy file processing. In those cases the agent just waits until the tool finishes, and there’s no way for the tool to emit intermediate messages like:
I tried tracing the execution path a bit and it seems like tools don’t currently receive any kind of context or event emitter — they only get the JSON arguments. Because of that, there isn’t really a way for them to send progress updates back to the runtime.
My initial thought was that something like a small execution context might make this possible, for example:
where the context could optionally expose something like a progress sender or event emitter.
That said, it also looks like this would touch quite a few parts of the system (the tool trait, plugin runtimes, agent loop, event system, etc.), so it might not be something the architecture is meant to support.
So I mainly wanted to ask:
Is the current “single result” tool model an intentional design choice?
Or is emitting progress updates from tools something that could make sense for MoFA in the future?
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions