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 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 <instance>-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 <agent> 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
• Scion concepts
• Scion philosophy — "hypervisor for agents"
• Scion Runtime Broker

/cc @AlexsJones