wenjin272 opened a new issue, #1086: URL: https://github.com/apache/flink-agents/issues/1086
### Search before asking - [x] I searched the existing issues and did not find a duplicate. ### Description This is a child issue of #1055. Today, invoking a chat model from a custom Agent Action is expressed through the built-in event flow: one Action sends a `ChatRequestEvent`, the built-in chat model Action processes it, and another user Action receives the resulting `ChatResponseEvent`. This event-oriented model is useful for advanced workflows, but making it the required path for ordinary chat model invocations introduces usability concerns: - A single logical model invocation is split across multiple user Actions. - Data that would otherwise be local to the invocation often needs to be stored in Agent memory and recovered by the response Action. - Concurrent requests require users to correlate responses with request IDs and maintain additional mappings. - Users need to understand the framework's built-in request/response protocol before they can perform a common operation. - Success, failure, and continuation semantics are distributed across the request Action, built-in Action, and response Action. We should review this user journey and clarify the public API boundary for invoking chat models from custom Actions. #### Direction and constraints The existing `ChatRequestEvent` / `ChatResponseEvent` API and the built-in event-processing flow should be retained as a supported event-oriented API. It remains valuable for workflows that need explicit event routing, parallel fan-out/fan-in, custom correlation, branching, or direct control over event-driven orchestration. This issue intentionally does not prescribe a concrete alternative API. The exact API shape should be discussed separately and evaluated across Java, Python, and YAML-facing workflows. Any future refinement should preserve the behavior currently provided by the built-in flow, including model selection, retries and fallback, tool-call rounds, durable execution, structured output, metrics, tracing, and well-defined failure handling. Compatibility and migration mechanisms are outside the scope of this issue. #### Acceptance criteria - The common chat model invocation journey and its usability problems are documented for Java and Python custom Actions. - The existing Event API is retained and clearly positioned as a supported event-oriented API. - Requirements and semantic constraints for any API refinement are agreed before a concrete API design is selected. - Java, Python, and relevant YAML-facing behavior are considered consistently. ### Are you willing to submit a PR? - [x] I'm willing to submit a PR! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
