GitHub user pltbkd added a comment to the discussion: [Feature] Sub-agent Resource for Flink Agents - Framework part
Hi @alnzng, thanks for sharing! Your questions are very valuable for thinking through this design. My thought is that the interface should be designed from the caller’s perspective, while the implementation side can provide framework capabilities through a thicker common layer, which is what I referred to as the “External subagent support framework” in the proposal. I think this case is a good example to discuss the capability and value of such a framework, and we can further improve this part. ------ **From the caller perspective,** the current assumption is that the caller expects to obtain a result (or at least an acknowledgment) before continuing with subsequent work. Therefore, the interface is designed around obtaining a result. We also considered another approach during the design process: `callAsync/await`. * `callAsync` eagerly sends the request. * `await` is introduced into the context to wait for the result. This is very similar to the submit/query model, except that `await` internally polls the query until the result is available. The problem with this approach is: * It cannot naturally reuse the durable callable mechanism, including possible future batch execution support. * Internal subagents and Python subagents also cannot truly eager fire requests. They would only actually start execution and yield when `await` is reached, which does not achieve the expected behavior. In both approaches, the assumption is that the result is eventually needed inside the caller action. I think this interface model matches the caller’s mental model better, and subagent should avoid exposing execution management and polling responsibilities to the caller. Due to the execution model limitations of internal subagents, we also cannot expose a similar polling interface there. Otherwise, the common subagent interface would become different between internal and external implementations. I also raised a related question in a previous sync meeting: whether subagent needs a pub/sub style interface. This model would break the assumption that callers expect a result or acknowledgment, but I am not sure whether there are many such scenarios. At least from my perspective, an acknowledgment is likely still necessary. What do you think about the interface design? ------ **From the implementation perspective,** I agree that the current subagent abstraction is almost no different from implementing the same thing as a Tool. The main additional semantics of subagent are independent context and lifecycle. Since external agents are naturally isolated from the main agent, the design process focused more on internal agent scenarios and did not provide many external-agent-specific capabilities. My view is: * The interface should focus on caller usage. * The implementation side can provide framework capabilities through a thicker common layer, i.e. the External subagent support framework. This could be a future work item, and we can further discuss and refine it based on this feedback and the preferred interface design. Regarding the continuity issue, I think using deterministic session ID (+ call ID) together with the durable execute mechanism can satisfy this requirement. * The session ID can represent the remote thread/session identity. * The call ID can represent an individual invocation and become part of the durable execute identity. * During recovery, an in-flight request can use reconciliation to query the remote state and determine whether the request needs to be resent. Even without relying on ActionState, the callable provided by Subagent can check the state before sending the request and decide whether to proceed. This logic belongs to the subagent implementation rather than the caller side. Therefore, I think the re-post issue you mentioned can be avoided with the existing mechanisms. However, I agree that these capabilities are not currently provided directly as framework features and still depend on the subagent implementation. Tools and MCP can implement the same approach, but they require the caller to provide deterministic IDs and handle the lifecycle management themselves. ------ I think the current discussion mainly focuses on two aspects: 1. The interface design: whether we should introduce submit/query, or an asyncCall/await model. 2. How the External subagent support framework should be implemented and what capabilities it should provide. My current preference is still not to expose the lifecycle protocol of external agents directly in the caller API, but rather let the framework layer absorb these differences. What do you think? GitHub link: https://github.com/apache/flink-agents/discussions/909#discussioncomment-17850782 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
