RFC: Support of different agent patterns as part of AgentRun / SympoziumInstance

[v01t]

Recently I found quite illustrative visualization of different agent patterns:

That I found quite interesting to have/implement some of those as part of ecosystem that based on sympozium (assume each LLM block from above as AgentRun), as out of those we could see that different type of tasks may require different agent pattern itself, few examples:

• Response of model needs to be automatically audited and authorized before being returned to user. While this theoretically can be implemented as part of model system prompt itself ("ensure that ...") that is sub-optimal as same model / context prepare response and decide if it could be returned. In this scenario "respose-gate" (Prompt Chaining Pattern) sidecar container (that should be treated as blackbox in this context) or bypass given model response or block it and reply with some "given information is restricted for an public" response could help.
• There are type of tasks and some studies that says that, if we run same request with same context n times and then summarize results this could lead to better results (Parallelization Pattern), also this could be useful when task could be chunked on buckets as then we could proceed huge list in parallel.
• For some tasks there are are natural requirements to "evaluate" results of another run before continuing (not block), like: one write code - another test it and give feedback (Evaluator Optimizer Pattern)

While I found those 3 (Prompt Chaining Pattern, Parallelization Pattern, Evaluator Optimizer Pattern) quite useful in future, I'm not sure what could be best scenario to implement those, should those be part of controller (SympoziumInstance / AgentRun spec.pattern(s)) or should those be implemented outsize of sympozium stack when some pod/controller simply create AgenRun kinds and handle pattern logic outside of sympozium.

Any comments, suggestions are always welcome.

And yeah... thanks for a great product @AlexsJones it may look like an draft as of now and could be not ready here and there but imho its already solid base for any LLM Agents in Kubernetes.

[AlexsJones]

Thanks for the thoughtful RFC @v01t, and for the reference to those agent patterns. I went through this alongside the discussion in #62 and wanted to share where things stand.

Current State

The good news is that all three patterns you identified are achievable today with the existing primitives:

Prompt Chaining -- SympoziumSchedule with IncludeMemory: true passes context between sequential runs. Lifecycle hooks (PreRun/PostRun) can transform or gate between stages. Sub-agents can also be spawned imperatively via tool calls with parent-child tracking built in.

Parallelization -- The spawner lets agents create concurrent sub-agents. SympoziumPolicy.SubagentPolicy already governs MaxConcurrent and MaxChildrenPerAgent. Schedules support ConcurrencyPolicy: Allow for parallel independent runs.

Evaluator-Optimizer -- An agent with the right skill/prompt can spawn a "reviewer" sub-agent and react to its output. The event bus (agent.run.completed) provides the async notification layer for this.

Declarative vs Imperative

The core question you raised; should these patterns live in the controller spec or be handled outside Sympozium -- is good. and The discussion in #62 landed on a similar conclusion: the stateless CRD-chain model keeps runs replayable and avoids the statefulness headaches that come with long-lived orchestration processes. Adding a DAG or pipeline spec to AgentRun would introduce significant control-plane complexity (state machines, failure recovery, partial rollback) that agents already handle naturally through sub-agent spawning.

That said, if there are specific patterns that feel awkward to express today, a targeted SkillPack (e.g. a parallel-fanout skill that teaches the agent to spawn N sub-agents and aggregate results) would be more aligned with the architecture than new CRD fields.

Response-Gate / Sidecar Pattern

One thing you raised that is not fully covered today: the response-gate pattern (your first example, where output needs to be audited before reaching the user). Currently PostRun lifecycle hooks are best-effort and do not block or rewrite the response. We are actively looking at improving this -- adding a gating mode to PostRun hooks so a sidecar can reject or rewrite agent output before it reaches the channel. We will open a separate enhancement issue for that work.

Would love to hear your thoughts on whether the existing primitives cover your use cases or if there are specific gaps that feel painful. The patterns you described are exactly the kind of feedback that helps us figure out what to prioritize next.

[AlexsJones]