Scion (GCP) — Summary

Scion is an experimental open-source Go-based multi-agent orchestration testbed from Google Cloud Platform, designed to run multiple AI coding agent harnesses (Claude Code, Gemini CLI, Codex, OpenCode) in parallel, each in their own container with their own git worktree. Each agent gets isolated credentials, config, and a dedicated feature branch — preventing merge conflicts across concurrent agents. The scion CLI manages the full agent lifecycle: start, attach (tmux), send messages, stop, resume, delete. Agents are configured via Templates (system prompt + skills bundles), enabling role specialization ("Security Auditor", "QA Tester"). A Hub architecture enables multi-machine orchestration where agents run on distributed Runtime Brokers (Docker, Podman, Apple Container, Kubernetes). OTEL telemetry provides normalized observability across harnesses. The philosophy is "less is more" — agents dynamically learn a CLI tool and use natural language to coordinate among themselves.

Differs from seeds: Scion is the most structurally similar to a research infrastructure harness (not a workflow methodology). Closest to claude-flow in multi-agent scope, but diverges in architecture: Scion uses per-agent containers + git worktrees (true OS isolation), while claude-flow uses a Node.js hive-mind with SQLite. Scion's "harness-agnostic" design (any CLI that runs in a container) is unique — it does not specialize in one AI tool but provides the container substrate for any.

Scion (GCP) — Overview

Origin

Scion is developed by Google Cloud Platform (GCP) as an experimental project. It is explicitly NOT an officially supported Google product and is not eligible for the Google Open Source Software Vulnerability Rewards Program. The name: "sci·on /ˈsīən/ — a young shoot or twig, cut for grafting or rooting."

Philosophy (verbatim from README)

"Rather than prescribing rigid orchestration patterns, Scion takes a 'less is more' approach: agents dynamically learn a CLI tool, letting the models themselves decide how to coordinate among agents. This makes it a rapid prototype testbed for experimenting with multi-agent patterns through natural language prompting."

Key Design Principles

• Harness Agnostic — Works with Gemini CLI, Claude Code, OpenCode, and Codex
• True Isolation — Each agent in its own container with separated credentials, config, and dedicated git worktree
• Parallel Execution — Multiple agents as fully independent processes, locally or remotely
• Attach/Detach — Agents run in tmux sessions; attach for human-in-the-loop, enqueue messages while detached
• Specialization via Templates — Define agent roles with custom system prompts and skill sets

Project Status

• Local mode: relatively stable
• Hub-based workflows: ~80% verified
• Kubernetes runtime: early, rough edges
• Experimental; expect breaking changes

Repo Facts

• GitHub: https://github.com/GoogleCloudPlatform/scion
• Stars: 1,548 (2026-05-26)
• Language: Go
• License: Apache-2.0
• Last commit: 2026-05-24

Scion (GCP) — Architecture

Distribution

• Install from source: go install github.com/GoogleCloudPlatform/scion/cmd/scion@latest
• No pre-built binaries (must build container images too)
• Requires Docker (Linux/Windows) or Apple Container (macOS) or Kubernetes

Architecture Overview

Local Mode

scion CLI
  ├── Agent 1: Container (Claude Code) + git worktree branch-1
  ├── Agent 2: Container (Gemini CLI) + git worktree branch-2
  └── Agent N: Container (Codex) + git worktree branch-N

Each agent:
  - Own /home/gemini (dedicated home directory)
  - Own config + credentials
  - Attached to tmux session
  - .scion/ project config

Hub Mode (Multi-Machine)

Scion Hub (State Server: API + Database)
  ├── Runtime Broker A (laptop/VM with Docker)
  │   └── Agent Pods
  └── Runtime Broker B (Kubernetes cluster)
      └── Agent Pods

Workspace Strategy (Git Worktrees)

• New worktree created at ../.scion_worktrees/<project>/<agent>
• New feature branch created for each agent
• Prevents merge conflicts across concurrent agents

Container Runtimes Supported

• Docker (Linux/Windows/macOS)
• Podman
• Apple Container (macOS native)
• Kubernetes (experimental, via Hub)

Directory Structure

scion/
├── cmd/                    # CLI commands (Cobra)
│   ├── start.go
│   ├── list.go
│   ├── attach.go
│   ├── message.go
│   ├── stop.go
│   ├── resume.go
│   ├── delete.go
│   ├── template*.go
│   ├── hub*.go
│   └── server*.go
├── pkg/
│   ├── agent/              # Agent lifecycle
│   ├── config/             # .scion/ init + embeds/
│   ├── harness/            # Gemini, Claude, Generic harnesses
│   ├── runtime/            # Docker, Apple, K8s abstraction
│   ├── runtimebroker/
│   ├── hub/
│   ├── hubclient/
│   └── store/              # SQLite (local), expandable
├── web/                    # React+Vite frontend (Hub)
├── .scion/                 # Templates + project config
│   └── templates/          # Agent role blueprints
└── skills/                 # Skill SKILL.md files
    ├── scion/
    └── team-creation/

Observability

• Normalized OTEL telemetry across all harnesses
• Logging and metrics for agent swarms

Scion (GCP) — Components

CLI Binary (scion)

Key subcommands:

• scion init --machine — Machine-level initialization
• scion init — Project initialization (creates .scion/ directory)
• scion start <template> "<prompt>" — Start new agent
• scion start <template> "<prompt>" --attach — Start and immediately attach
• scion list / scion ps — List active agents
• scion attach <name> — Attach to agent's tmux session
• scion message <name> "..." / scion msg — Send message to running agent
• scion logs <name> — View agent logs
• scion stop <name> — Stop agent
• scion resume <name> — Resume stopped agent
• scion delete <name> — Remove agent, container, and worktree
• scion schedule — Schedule commands
• scion hub * — Hub management commands
• scion broker * — Runtime broker commands
• scion templates / scion template import — Template management
• scion whoami / scion version / scion doctor

Templates (Agent Role Blueprints)

Located in .scion/templates/:

• docs-writer — Documentation writing agent
• instance-manager — Instance management agent
• release-notes — Release notes agent
• web-dev — Web development agent

Each template = system prompt + collection of skills

Skills (in skills/)

• scion/ — Core Scion skill for agent CLI tool learning
• team-creation/ — Team creation workflow skill

Harnesses (in pkg/harness/)

• gemini — Gemini CLI harness
• claude — Claude Code harness
• generic — Base harness for other LLM interfaces

Agent State Files (from README)

• .scion/settings.json — Project settings (runtime choice, Hub config)
• .scion/agents/ — Per-agent configuration (in .gitignore)
• /home/gemini/.gemini-status.json — Agent status (STARTING/THINKING/EXECUTING/WAITING_FOR_INPUT/COMPLETED/ERROR)

Hub (State Server)

• Central API + database for agent state, projects, templates, users
• Web frontend (React+Vite)
• Storage: GCS or Local

Scion (GCP) — Uniqueness & Positioning

differs_from_seeds

Scion is architecturally most similar to claude-flow (multi-agent, parallel execution, coordinator role), but diverges sharply: claude-flow is an npm package running in one Node.js process with a hive-mind protocol and SQLite; Scion gives each agent its own container and git worktree, uses tmux sessions for human-in-the-loop interaction, and provides OTEL telemetry for cross-harness observability. Unlike any seed, Scion is explicitly harness-agnostic (Claude Code, Gemini CLI, Codex, OpenCode all supported equally). The "emergent coordination via CLI tool" philosophy (agents learn scion message and decide how to coordinate) is distinct from claude-flow's prescribed hive-mind protocols.

Distinctive Positioning

1. Harness-agnostic by design: Scion treats Claude Code, Gemini CLI, Codex, and OpenCode as interchangeable harnesses. Templates specify which harness + system prompt. No other multi-agent framework is this provider-neutral.

2. Emergent coordination: "Less is more" — agents learn a CLI tool and decide how to coordinate themselves via natural language messaging. No hardcoded orchestration protocol. This is an experiment in whether emergent organization outperforms prescribed coordination.

3. Tmux-based human-in-the-loop: WAITING_FOR_INPUT status triggers human attachment via tmux session. Not a webhook or API — interactive terminal access. Unusual and practical for complex debugging scenarios.

4. OTEL telemetry normalized across harnesses: Agents from different vendors produce comparable telemetry. Enables cross-agent observability dashboards and replay of coordination patterns.

5. Hub + Runtime Broker architecture: Separates state (Hub) from compute (Broker). Enables agents on laptop + remote VM + K8s cluster in the same project. No other framework in this batch supports this topology.

Observable Failure Modes

• No prebuilt binaries — must build container images (significant barrier)
• Experimental status — local mode stable, Hub/K8s rough
• Requires tmux on host for full functionality
• "Less is more" emergent coordination can be unpredictable in production
• Not an officially supported Google product
• Git worktree at ../.scion_worktrees/ — coordinate placement with parent repo layout
• 1,548 stars but early/experimental — limited production case studies