Problem
currently, a higher order work item can schedule children, but not configure them. For instance, a lvl-4-workflow can only schedule a lvl-3-task but not provide any additional context when that 3 runs. If the 3 fails, the 4 wouldn't know
Proposed solution
Add a "executionWrappers" array to first-class task state that higher level agents can utilize. Adding named wrappers to this would let the 4 wrap a lvl3 in something like a retry (.step(task('blah', { retry: 3 })), that would attempt but retry if possible. This would schedule the "blah" task and add "retry" to the wrapper list. When the 3 gets picked up to run, we would stack the wrappers around the 3 work item's run method, equivalent to scheduling retry(taskAgent('')) effectively
Alternatives considered
No response
Area
CLI (bf)
Additional context
No response
Problem
currently, a higher order work item can schedule children, but not configure them. For instance, a lvl-4-workflow can only schedule a lvl-3-task but not provide any additional context when that 3 runs. If the 3 fails, the 4 wouldn't know
Proposed solution
Add a "executionWrappers" array to first-class task state that higher level agents can utilize. Adding named wrappers to this would let the 4 wrap a lvl3 in something like a retry (.step(task('blah', { retry: 3 })), that would attempt but retry if possible. This would schedule the "blah" task and add "retry" to the wrapper list. When the 3 gets picked up to run, we would stack the wrappers around the 3 work item's run method, equivalent to scheduling
retry(taskAgent(''))effectivelyAlternatives considered
No response
Area
CLI (
bf)Additional context
No response