GitHub user wenjin272 added a comment to the discussion: Planning Flink Agents 1.0 - Brainstorming
Sharing a proposed set of priorities for **Flink Agents 1.0.0** from @xintongsong, @pltbkd, @joeyutong and @wenjin272, following our initial brainstorming discussions. **Must-have for 1.0:** - **More control over model and tool execution.** Let users insert custom logic around model/tool calls, capture intermediate results, and intervene in the built-in ReAct loop. Hooks, events, and explicit tool-call handling are options to evaluate against these requirements. - **Agent loop budget controls.** Support time, round/step, and token budgets, with options to stop immediately or allow a final round for the model to wrap up when a budget is reached. - **Timer support for delayed tasks.** Allow agents to schedule future events using Flink timers, enabling delayed checks and timeout handling without keeping an action running while waiting. - **Distinguishing responses from multiple requests.** Help downstream actions distinguish responses from multiple requests and handle them appropriately by propagating user-defined context from each request to its response. - **Decoupling checkpointing from agent execution.** Agent runs may involve multiple rounds of model inference, tool calls, and subagent execution with unpredictable latency. Allow checkpoints to complete without waiting for these runs to finish, and define how in-progress execution is saved and recovered. - **API, configuration, and built-in integration compatibility.** Define stability labels and compatibility rules for APIs, configuration, YAML, and built-in integrations, including deprecation and migration. Add annotations/decorators and automated compatibility checks in CI. - **State compatibility.** Framework upgrades should preserve operator state when application logic and state usage remain unchanged, allowing necessary API adaptations. Define the supported version window and validate it with cross-release restoration tests. Compatibility after changes to application logic would require separate evaluation. Cross-version reuse of the **ActionState journal** would not be guaranteed; calls within unfinished actions may execute again after an upgrade. - **Framework support for multimodal data.** Complete the abstractions needed for multimodal inputs, outputs, and tool results. Clarify which capabilities fit existing model interfaces and which need another abstraction; individual model integrations can follow separately. - **Rename Flink Agents.** We have repeatedly seen people interpret the name as an agent for operating Flink, rather than an agent framework built on Flink. Consider a clearer name for 1.0 that better communicates the project’s purpose. **Nice to have:** - **Stage-level quality gates — high priority.** Support checks on output quality, evidence, or executability, followed by bounded retries or a return to the relevant stage while retaining successful work. - **Unified serial and parallel execution paths — high priority.** Consolidate duplicated runtime logic and align lifecycle and event-listener behavior. Evaluate concurrency and backpressure separately, favoring clear limits on in-flight inputs and asynchronous tasks where additional control is needed. - **Stronger structured-output validation.** Extend schema and field validation, including nullability constraints and handling of validation failures. Keep this separate from stage-level quality gates. - **Application versus framework failures.** Clarify which tool/subagent failures can become responses for the caller to handle, and which must propagate to the runtime and trigger recovery. - **Configurable persistence of failed calls.** Avoid repeatedly replaying a recorded transient failure that causes the job to fail again. The proposed default is to leave failed durable calls unrecorded, with an explicit per-call option when recording the failure is required. The precise failure boundary still needs design. - **Human-in-the-loop abstractions.** Simplify approval, rejection, and resumption workflows. Timer support is the more urgent framework building block; application-specific approval flows can be assembled with custom actions and external systems. - **Prompt hot updates.** Explore refreshing prompts from MCP, remote files, or prompt-management services without replacing the entire agent plan. - **Python and YAML Model Routing support.** Fill the remaining API gaps relative to Java. - **Support for Flink batch mode.** Enable Flink Agents to run in Flink batch mode. Investigate asynchronous execution and key-context lifecycle constraints, then define the supported scope. - **ActionStateStore improvements.** Improve testing, identity handling, cleanup, write-failure handling, and storage efficiency. A broader redesign needs a clearer use case and scope. - **Cross-language external subagents.** Address the remaining Java/Python interoperability gaps and clarify their relationship to internal subagent support. - **Operational visualization.** Explore a graph of observed execution relationships, combined with metrics such as event counts or rates. This should summarize runtime behavior and complement individual execution traces. Metric coverage and the UI integration approach need further design. - **Additional multimodal model integrations.** Expand model coverage based on concrete use cases, building on the framework-level multimodal abstractions. - **CDC integration.** Explore invoking agents from CDC pipelines, with scope and timing informed by concrete use cases and the Flink CDC release plan. **Longer-term directions and upstream work that should not block 1.0:** - **Subagents on RPC operators.** Explore delegating subagent execution to separate worker resources, subject to concrete use cases and upstream Flink support. - **Full AgentPlan hot updates.** Support updating agent plans, including plan, JAR, and dependency persistence and recovery. Continue the upstream groundwork while evaluating prompt-only updates separately. - **SQL integration.** Advance the Flink proposal, distinguishing calls to existing agents from declaring and reusing YAML agents through SQL/Catalog. - **New input during ongoing reasoning — high priority for longer-term exploration.** Explore how a new event for the same key can supplement or interrupt ongoing reasoning while preserving well-defined state and consistency semantics. **Development and release practices:** - **Documentation alongside features.** Require relevant documentation updates alongside changes to user-visible behavior, APIs, or configuration, and review them together before merging. - **Documentation checks.** Record this expectation in contributor and reviewer guidance. Explore automated checks and periodic audits to help catch omissions. - **Routine release preparation.** Keep release testing in routine CI, maintain a releasable main branch, and continue automating release-note preparation. - **Smaller, more frequent releases.** Keep release-blocking requirements focused and reduce accumulated release work. A cadence of roughly two weeks to one month is a direction to work toward, rather than a committed schedule. Larger documentation reorganizations can be handled as separate contributions. GitHub link: https://github.com/apache/flink-agents/discussions/1327#discussioncomment-19240496 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
