RFC: Scion Runtime Backend for Long-Lived Interactive Agent Sessions

## RFC: Scion Runtime Backend for Long-Lived Interactive Agent Sessions ### Background Sympozium's ephemeral-Job model is excellent for event-driven, short-lived agent runs (channel messages, scheduled heartbeats, API requests). However, it creates friction for **long-lived, interactive coding sessions** — the kind where a human needs to attach mid-run, inspect progress, and send follow-up instructions. This is exactly the gap [GoogleCloudPlatform/scion](https://github.com/GoogleCloudPlatform/scion) is designed for. Scion is a multi-agent orchestration testbed from GCP that manages long-lived agent processes in containers with: - `tmux`-based interactive sessions (attach/detach, message enqueue) - Git worktree isolation per agent (clean branch per agent, no merge conflicts) - Support for Claude Code, Gemini CLI, Codex, OpenCode as harnesses - A Runtime Broker model — compute nodes register to provide execution capacity - OTEL telemetry (same stack as Sympozium) ### Proposed Integration Pattern Sympozium becomes the **channel layer, memory layer, and policy layer**. Scion becomes the **execution layer** for long-lived coding runs. ``` User (Slack/Telegram) └── Sympozium Channel Pod └── NATS JetStream └── [new] ScionRuntime reconciler └── Scion Runtime Broker └── Agent container (Claude Code / Gemini CLI) ├── git worktree workspace ├── tmux session (interactive) └── IPC → NATS → Sympozium memory controller ``` ### Concrete Scope This doesn't require deep coupling. A minimal viable integration could be: 1. **New `runtimeClass: scion` field on `SympoziumInstance`** — when set, the orchestrator delegates to a Scion Runtime Broker instead of creating a K8s Job directly. 2. **Scion IPC bridge → Sympozium NATS** — Scion already emits structured OTEL; mapping its agent state events (`thinking`, `waiting_for_input`, `completed`) onto Sympozium's NATS bus gives the web UI and channels real-time visibility. 3. **Memory handoff** — on run completion, extract Scion agent output and patch the `-memory` ConfigMap via the existing memory controller. Scion agents would be ephemeral from Sympozium's perspective even if long-lived at the Scion layer. 4. **TUI/web visibility** — surface Scion agent state (idle/thinking/waiting) in the Sympozium TUI alongside normal AgentRun pods. ### What This Unlocks - A Slack message saying "refactor the auth module" could spin up a Claude Code agent with a full git worktree, run for 20 minutes, allow the user to `sympozium attach ` for human-in-the-loop, and write back results via PR — all triggered and tracked through Sympozium's existing channel + memory + policy stack. - PersonaPacks could include `developer-team` personas that use Scion-backed execution for coding tasks vs. ephemeral Jobs for triage/review tasks. - No changes needed to Scion itself — this would be a new Sympozium reconciler that speaks the Scion Hub API. ### Open Questions - [ ] Scion Hub API is still maturing — is it stable enough to build against, or should we wait for a formal release? - [ ] How do we handle Scion's git worktree model alongside Sympozium's GitOps-managed config? Do we want the Scion worktree to be a separate repo, or forked from the same one the PersonaPack is operating on? - [ ] Should `sympozium attach` transparently proxy to `scion attach` for Scion-backed runs? - [ ] Blast-radius isolation: Scion's model is infrastructure-layer isolation (container + network policy); does this satisfy Sympozium's `SympoziumPolicy` admission requirements, or do we need a translation layer? ### References - [GoogleCloudPlatform/scion](https://github.com/GoogleCloudPlatform/scion) - [Scion concepts](https://googlecloudplatform.github.io/scion/concepts/) - [Scion philosophy — "hypervisor for agents"](https://googlecloudplatform.github.io/scion