GitHub user joeyutong edited a comment on the discussion: [Feature] Sub-agent Resource for Flink Agents - Framework part
Thanks for the proposal. I understand the motivation for providing a unified invocation API for internal and external agents. However, I think the current `Subagent` abstraction mixes the agent being registered with the capability used to invoke it. >From the user's perspective, an external agent is a black-box invocation >target, so `call()` naturally matches its execution boundary. An internal >`Agent`, however, is already presented to users through actions, resources, >and event-driven execution. Exposing the same `Agent` as a callable sub-agent >makes users reason about two public execution models for the same abstraction: >it is event-driven when used as a regular `Agent`, but >request/response-oriented when used as a sub-agent. This is not only an internal implementation difference. To understand the behavior of `call()`, users also need to know how the request becomes an input event, which output events form the result, and what marks the call as complete, such as quiescence. In other words, the callable view is exposed to users, while the semantic adaptation that creates this view remains implicit. Therefore, the proposal unifies the invocation shape, but does not fully unify the user-facing semantics. From this perspective, the shared abstraction seems closer to a `SubagentInvoker`: - for an external agent, it delegates to the invocation protocol provided by the external integration; - for an internal agent, it invokes the `Agent` through a **`CallProtocol`** that defines request, result, and completion mappings. Under this model, the authoring experience remains different where it should be. For an external agent, its integration can provide a custom `SubagentInvoker` that encapsulates the agent endpoint and its invocation protocol. For an internal agent, users continue to define and register the `Agent` itself as `ResourceType.AGENT`; the framework provides a built-in `SubagentInvoker`, invisible to users, that drives the `Agent` according to the internal **call protocol**. Users therefore do not construct or register this invoker as another kind of `Agent`: `SubagentInvoker` is the invocation mechanism, while `Agent` remains the user-facing authoring abstraction. This would preserve a unified API for callers without exposing `call()` as a second intrinsic execution model of every `Agent`. GitHub link: https://github.com/apache/flink-agents/discussions/909#discussioncomment-17661229 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
