Re: [I] Refactor WorkHub around a simpler coordination and configuration model [maka]

["ARE404 (via GitHub)" <gi...@apache.org>]

ARE404 commented on issue #5745:
URL: https://github.com/apache/maka/issues/5745#issuecomment-5933360159

   Thanks, @M4n5ter and @sunrioa, for raising these questions. Here is where I currently land on the boundaries:
   
   1. **Creating and reusing Sessions.** The coordinating Agent should be able to create a Session for an independent request without requiring the user to explicitly say “create a new task.” That was also my intent in the original design. It should reuse a Session when the request clearly continues existing work, and ask when the intent is ambiguous. Session organization, grouping, and removal from candidates are worth exploring, but I’d like to complete the refactor of the basic coordination functionality first.
   
   2. **Session identity and context window.** I agree that these concepts should be separate. The coordination interface only needs to express “continue this Session”; preparing and managing the execution context remains the target Session’s responsibility. I don’t think this refactor needs to introduce context management in WorkHub.
   
   3. **Execution permissions.** Executions initiated through WorkHub should use WorkHub’s permission settings, including when reusing an existing Session. I’d apply those settings to the delegated execution without permanently changing the target Session’s existing configuration.
   
   4. **Stopping and delegating again.** I’m comfortable with simple semantics: stopping the old execution and initiating the new delegation are separate operations, and partial success is possible. If stopping succeeds but delegation fails, the coordinating Agent should accurately report the current state and decide whether to retry, select another target, or ask the user. After a process restart, persisted conversation and operation results should also let it determine which steps have completed. We need to verify that the common Session/Host recovery mechanisms support this behavior, but I don’t think we need to retain a WorkHub-specific replacement transaction solely to make these two operations atomic.
   
   Also, @Astro-Han, I’d like to discuss communication after the refactor to a coordinating Agent. My current inclination is to reuse ordinary cross-Session messaging for delegation, Steering, and returning results or missing information, with message delivery and recovery handled by the common Session/Host layer.
   
   Do you think we need a separate message-sending or mailbox mechanism here? I’d like to first clarify how messages are received while the target is executing, and how returned results allow the coordinating Agent to continue. Are there concrete scenarios that ordinary messaging cannot cover and that require an additional mechanism?
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org