Remove flow task; add threadmessage construct #39
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The @flow decorator was using a "parent task" to automatically track all tasks added in the flow, but this confused the agents, who viewed that task as part of their mandate (and created complexity around how to decide if it was successful, failed, skipped, etc).
Instead, we replace the parent task with the existing task-tracking mechanism of the flow, and spawn a Controller to run all registered tasks to completion before returning from the flow decorator.
This also includes an important enhancement: the ThreadMessage object. Agents often post messages, then repeat the entire message as a Task result. By passing a special ThreadMessage object, they can indicate that the task result should be loaded from a previous response, saving time and tokens.