GitHub user weiqingy added a comment to the discussion: Planning Flink Agents 0.4
Thanks for starting the 0.4 planning thread. The current Must list looks like a good foundation to me. The split between highlight features, production requirements, experience improvements, and “if possible” items also makes sense. A few thoughts / brainstorm ideas: 1. For sub-agent primitives, I’ll resolve the pending feedback in #660 and follow up there with a concrete proposal [1]. At a high level, I’m leaning toward treating `SubAgent` as a logical unit first, rather than tying it to one placement model too early. Same-job/same-operator could be a practical starting point, while leaving room for future same-job/different-operator or cross-job execution. 2. The observability part already covers the main things I was thinking about: memory observation through EventLog, per-run trace #710, and metrics improvements [2][3][4]. I don’t have extra items to add there beyond agreeing that these are important for production debugging and evaluation. This also matches what other agent runtimes emphasize: execution timelines, trace visualization, and evaluation/debugging loops are treated as core production capabilities [7][8]. 3. For durable external signal handling, I would avoid framing this as generic human-in-the-loop. In an event-driven system, the more natural primitive is durable correlation with later events: wait/resume/timeout based on a callback or another stream event. Flink Agents already has durable execution, action-state recovery, reconcilers, and request_id-style correlation in built-in events [5]. The missing part may be a generic pattern/API for “this keyed run is pending until a later correlated event arrives or times out.” Restate and LangGraph both show a similar need around durable waiting/resuming long-running agent or workflow executions, though Flink Agents may want to express it in a more event-stream-native way [7][8]. Example: a support agent sends a fraud-check request to an external risk service. The response comes back later on Kafka. The agent should not block a thread; it should persist pending state, resume on the callback event, or emit a timeout path. 4. Flow/cost control also seems partly covered by the proposed Agent Harness (`max events / max actions / max tokens / timeout`) and parallel tool call execution #855 [6]. One possible extension to consider is resource-scoped guardrails: per-model, per-tool, per-key, or per-tenant concurrency/rate limits. A global async pool prevents unlimited threads [5], but it does not express “this tenant gets max N concurrent model calls” or “this external CRM tool gets max QPS.” This could maybe fit under Agent Harness or the parallel tool execution work rather than being a separate top-level feature. Restate calls out cost/concurrency control for agent invocations as an explicit runtime concern, which seems like a useful reference point here [7]. References: [1] #660 Sub-agent discussion: https://github.com/apache/flink-agents/discussions/660 [2] Monitoring docs: https://github.com/apache/flink-agents/blob/main/docs/content/docs/operations/monitoring.md [3] #710 tracing/evaluation discussion: https://github.com/apache/flink-agents/discussions/710 [4] #876 memory observation discussion: https://github.com/apache/flink-agents/discussions/876 [5] Deployment / exactly-once action consistency docs: https://github.com/apache/flink-agents/blob/main/docs/content/docs/operations/deployment.md [6] #855 parallel tool execution discussion: https://github.com/apache/flink-agents/discussions/855 [7] Restate AI Agents: https://docs.restate.dev/use-cases/ai-agents [8] LangGraph overview: https://docs.langchain.com/oss/python/langgraph/overview GitHub link: https://github.com/apache/flink-agents/discussions/862#discussioncomment-17573905 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
