GitHub user weiqingy added a comment to the discussion: [Discussion] Supervisor + Sub-Agent Orchestration: Concrete Multi-Agent Use Cases for Event-Driven Agents
Thanks @xintongsong, @pltbkd, @wenjin272, @armorer-labs, and @jingchang0623-crypto. This discussion clarified both the use case and the scope considerably. On the Tier labels: the number represented how much new framework work was required, not urgency. Tier 0 required no new primitives, Tier 1 contained framework work needed to unblock the use case, and Tier 2 contained behavior that should first be validated through a recipe. That naming is confusing, so I would relabel these as implementation phases. On what "sub-agent" means: it is a logical agent boundary, backed by an Action or workflow of Actions, rather than necessarily a standalone Flink job. Placement should remain separate from that concept and follow the 1.a / 1.b / 2 / 3 taxonomy. For the first implementation, I agree with focusing on 1.a: same job, same operator, and with providing a built-in rather than asking every user to assemble the pattern manually. RpcOperator can later support independently scalable pools under 1.b. For the original Tier 0 and Tier 2 items, we can validate them against the 1.a implementation rather than settle them abstractly. I am happy to try the built-in, contribute a representative example, and use that experience to identify which judge/critic and termination behaviors belong in configuration versus recipes. The requirements I would carry into the sub-agent design are: - Context isolation by default. A sub-agent should receive declared input, not implicitly inherit the supervisor's accumulated memory. Parent-memory or resource inheritance should be explicit. - A declared invocation contract. Input, output, completion, and failure semantics need to be clear enough for validation, retry, refinement, and judge patterns. - Durable invocation identity. Each delegation should carry stable run and parent identities plus the sub-agent definition/version. Completed results can be replayed, while an in-flight external or side-effecting call needs remote idempotency or a reconciler rather than automatic re-execution. - Timeouts and typed outcomes. The supervisor must be able to distinguish success, failure, and timeout and route each outcome deliberately. - Bounded execution. Rounds, wall-clock time, tokens/cost, and nesting depth should be bounded. - Java/Python parity. Parallel invocation and recovery should have one semantic contract across both languages. @pltbkd, thanks for the detailed diagram and the design in #909. Discussion #909 is the right place to continue the framework API (we can continue the discussion there). This thread can remain the requirements and deployment-placement record. GitHub link: https://github.com/apache/flink-agents/discussions/660#discussioncomment-17729924 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
