GitHub user weiqingy edited a comment on the discussion: [Feature] Sub-agent Resource for Flink Agents - Framework part
Hi @pltbkd, Thanks for putting together this comprehensive proposal! The introduction of `ResourceType.AGENT` and the `Subagent` abstraction is a helpful step forward. It addresses the capability-agnostic orchestration vision discussed in #660 by treating internal agents, external setups, and tools as peer capabilities, while eliminating the need for users to split logical operations into inverted send/receive actions (`Action-A` / `Action-A'`). A few thoughts and questions regarding design details, open items, and alignment with earlier roadmap discussions: * **`SubagentCompatible` Marker vs. Runtime Enforcement:** Just to confirm my understanding: when registering an internal agent directly via `addResource(name, ResourceType.AGENT, new TargetAgent())`, does compilation fail if `TargetAgent` wasn't originally declared with `@SubagentCompatible`? If so, this might create friction when users want to reuse existing or third-party agents whose source code they don't own or cannot easily modify. Since `SubagentRunnerContext` already enforces read-only parent memory access and scope-bounded events at runtime, do you think strict runtime enforcement (throwing a clear exception if forbidden operations like parent memory mutation are attempted) could be sufficient to catch anomalies without requiring compile-time marker declarations? * **External Idempotency Framework:** Building on the discussion above regarding side-effect recovery during crash windows, you mentioned the potential for a shared framework for external sub-agents (`SubagentSetup`). How do you envision this framework enforcing `sessionId`-based idempotency automatically so that individual integration authors don't have to write custom deduplication/reconciliation logic manually? * **Nested Backpressure & Deadlocks:** The proposal highlights potential deadlock issues in nested sub-agent calls under backpressure. Are you leaning toward addressing this via non-blocking yield mechanics in the execution operator, or by enforcing explicit call-stack depth / concurrency limits on worker pools? * **Timeout & Cancellation Semantics (Refining "To Be Refined"):** Regarding the timeout/cancellation gap noted in the proposal, here are a few scenario requirements that might be worth considering: 1. *Resource & Token Control:* Supporting a timeout context on `call()` to unblock the parent pipeline if a sub-agent stalls or hallucinates. 2. *Parallel Short-Circuiting:* When running `durableExecuteAllAsync(c1, c2)`, if one branch returns a conclusive answer early or fails, having a mechanism to pass a cancellation signal to the remaining in-flight callables so we don't waste LLM tokens or external compute. 3. *Propagation:* Emitting a scope cancellation event within `SubagentRunnerContext` for internal agents, or triggering an HTTP abort/gRPC cancel for external `SubagentSetup` instances. * **Framework Primitives vs. Application Templates:** Looking at this proposal alongside @xintongsong's suggestions in #660, which discussed higher-level user templates (e.g., introducing the sub-agent concept on top of the built-in `ReActAgent`, or a built-in `SupervisorAgent` handling routing, critic steps, and termination budgets): with these new primitives, do you think an out-of-the-box template layer remains valuable so users don't have to write custom orchestration logic? Is the main goal here to establish the primitive layer for templates to build upon, or does your POC also explore a built-in `SupervisorAgent` template? Looking forward to hearing your thoughts! GitHub link: https://github.com/apache/flink-agents/discussions/909#discussioncomment-17784292 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
