GitHub user weiqingy edited a comment on 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]. 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 [8][9]. 3. One possible area to brainstorm is durable external signal handling. I’d frame this less as generic human-in-the-loop and more as event-driven durable correlation: 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 [8][9]. 4. Flow/cost control seems partly covered by the proposed Agent Harness (`max events / max actions / max tokens / timeout`) and parallel tool call execution #855 [7]. 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 [6], 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 [8]. 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] Configuration docs: https://github.com/apache/flink-agents/blob/main/docs/content/docs/operations/configuration.md [7] #855 parallel tool execution discussion: https://github.com/apache/flink-agents/discussions/855 [8] Restate AI Agents: https://docs.restate.dev/use-cases/ai-agents [9] 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]
