Scion
An open-source orchestration platform where teams of AI agents delegate, share findings, and work in parallel alongside people.
- Source repo
- GoogleCloudPlatform/scion
- Stars
- ★ 2k
- Last updated
- today
- License
- Apache-2.0
- Primary language
- Go
- FA score
- 43/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude Code
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- An engineering team wants several coding agents to split one repository task—one debugging, one writing tests—with isolated worktrees and a consolidated result.
- Not a fit if
- Teams that need stable, production-grade APIs and cannot absorb pre-1.0 config churn.
- Users who will not run any container runtime such as Docker or Podman.
- People expecting a zero-setup experience with no local Hub server running.
- Source review
- 43/100 · Major gaps
What does this agent do, and when should you use it?
Scion, published by GoogleCloudPlatform under Apache-2.0, is an orchestration platform for teams of AI agents and the humans working with them. It runs agent harnesses such as Claude Code, Antigravity, Codex, and OpenCode as independent containerized processes, each with its own configuration and credentials, using shared workspaces, Git worktrees, or separate clones as the coordination model requires. The stack includes a scion CLI, a Workstation Hub with a local web UI, a Runtime Broker that provisions containerized agents, and hosted Hub modes that scale to Kubernetes and Cloud Run. Every agent runs through a Hub control plane that manages state, identity, and dispatch. The project describes itself as a pre-1.0 testbed for emerging agent collaboration patterns, so APIs and configuration are expected to keep changing.
The flow starts with scion init --machine to prepare a machine and scion init inside a repository to create the .scion project directory. scion server start launches the local Workstation Hub, opening an onboarding wizard at http://127.0.0.1:8080/onboarding that detects Docker, Podman, or Apple Container, configures identity and container images, and creates a first workspace. scion start <name> "<task>" then launches a harness process in a container; scion attach joins its tmux session, scion message sends text to a running agent, scion logs shows output, and scion stop, scion resume, and scion delete manage lifecycle. Agents delegate work through the CLI, message each other, and notify collaborators when tasks finish or need attention. Humans follow along through native web chat or Telegram, Discord, Slack, Google Chat, and Microsoft Teams. Templates and versioned skills, resolved through the Skill Bank and connected registries, package reusable prompts and tools, while an A2A bridge connects Scion to other agent systems.
- An engineering team wants several coding agents to split one repository task—one debugging, one writing tests—with isolated worktrees and a consolidated result.
- A researcher reruns an experiment and replays agent messages and shared-file access to study how the collaboration actually unfolded.
- A developer wants to try Claude Code, Codex, or OpenCode locally and compare model behavior without building orchestration from scratch.
- An operations group needs to run multi-agent workloads on Kubernetes or Cloud Run with a Hub managing identity and state centrally.
- A project lead wants to follow agent progress through Slack or Telegram rather than watching a terminal all day.
- A demo or teaching scenario defines multi-agent coordination entirely in markdown and visualizes the agents solving puzzles.
How do you install or deploy this agent?
The recommended path is the community Homebrew tap, which installs the scion CLI preconfigured to use ghcr.io/homebrew-scion as its default image registry, plus the scion-plugin-telegram broker plugin:
brew tap homebrew-scion/scion
brew install homebrew-scion/scion/scionTo upgrade later:
brew update && brew upgrade homebrew-scion/scion/scionAlternatively, build from a clone with make all, which builds the web frontend and embeds it in the binary. Use the Go version specified in go.mod and the Node.js prerequisites from the installation guide. A container runtime is auto-detected in the order Podman, then Docker (on macOS: Podman, Docker, then Apple Container), and can be overridden in .scion/settings.yaml.
How do you use this agent?
Start the local Hub server first:
scion server startThe browser opens the onboarding wizard at http://127.0.0.1:8080/onboarding, which walks through runtime detection, identity configuration, container image setup, and creating your first workspace. Then initialize a repository and start an agent:
cd my-project
scion init
scion start my-agent "Your task here"Common management commands:
scion list
scion attach <name>
scion message <name> "..."
scion logs <name>
scion stop <name>
scion resume <name>
scion delete <name>If you initialize the machine by hand instead of using the wizard, still run scion server start, because agents always run through a hub. Adding .scion/agents to .gitignore is recommended to avoid nested git worktree issues.
What are this agent's strengths and limitations?
- Mix harnesses and models freely—Claude Code, Antigravity, Codex, and OpenCode are named as supported—and extend setup through harness configuration bundles outside the core.
- One CLI spans a wide execution range: local Docker, Podman, or Apple Container up to Kubernetes and Cloud Run, with Workstation, single-node hosted, and HA hosted Hub modes.
- Built-in visibility for collaboration research: logs, session metrics, system health, and a choice of shared directories, worktrees, or clones per project.
- Open interfaces for integration: CLI, APIs, lifecycle hooks, MCP configuration, and an A2A bridge, with room for GitHub Issues, Linear, or Beads alongside.
- Skill Bank supports publishing and versioning skills resolvable from GitHub and external registries, so team expertise can be packaged and reused.
- Self-described as pre-1.0 and evolving rapidly; APIs and configuration may change between releases, which complicates production adoption.
- A Hub control plane is mandatory—even a hand-initialized machine still needs
scion server start, adding a long-running local service over a plain CLI. - Requires a container runtime (Docker, Podman, Apple Container, and so on); HA hosted operation additionally needs Postgres and shared storage.
- Not an officially supported Google product and not eligible for the Google OSS Vulnerability Rewards Program, so security support is limited.
- No pricing is stated; model usage costs depend entirely on the harnesses and model providers you choose.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Scion This agent | 43 · Major gaps | CLI | ★ 2k | today | Go | Codex · Claude Code |
| Polter Terminal Agent Supervisor | 80 · Good | Desktop appFree + model costs | ★ 20 | 1d ago | Zig | Claude Code |
| MCO | 73 · Some gaps | CLIFree + model costs | ★ 541 | 14d ago | Python | Codex · Claude Code |
| NTM (Named Tmux Manager) | 73 · Some gaps | CLIFree + model costs | ★ 460 | today | Go | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
README asserts container isolation, per-agent credentials, and hosted-mode roles/scoped secrets, but these are claims without implementation or default-policy detail; no user-confirmation flow is described; data-flow transparency for credentials, telemetry, and messaging is thin; sensitive-data handling is one sentence; go.mod pins many dependencies including dev/pseudo versions (grpc dev, chromedp pseudo) with no audit or mitigation note; external effects (containers, cloud resources, chat platforms) lack rollback or consent mechanics; source attribution is supported by Apache-2.0 and copyright headers, hence 2.
README and test scripts are broadly consistent, but chart-integrity.sh contradicts itself: comments say EXPECTED_TOTAL should be 39 yet it is set to 49 and the script states it therefore exits 2, showing an unconverged test baseline; dependency availability rests on go.mod and a Homebrew tap without verification; failure messages are strong in the test harness (explicit exit 0/1/2 contract, META-FAILURE text), hence 2.
README clearly enumerates local, Workstation, single-node hosted, HA hosted, and multiple runtimes, so scenario coverage is good; capability boundaries are mostly a concept table without precise constraints; trigger precision (when agents start or delegate) is unspecified; environment fit (Docker/Podman/Apple Container/K8s/Cloud Run) is documented, hence 2.
README is well structured with concrete install steps (Homebrew and source) and states pre-1.0 status and API churn as known limitations; naming stability is weak by its own admission, there is no version number or changelog file, and examples/FAQ are sparse; the full Apache-2.0 license earns 3; maintenance responsibility is only a 'not an officially supported Google product' disclaimer with unverified publisher identity, hence 1.
Output usability has a CLI command table and quick start but no end-to-end example output; the marginal-value proposition (multi-agent orchestration) is plausible but unquantified; cost-benefit is not discussed (containers, cloud resources, model calls), hence 1.
README claims (internal Google experiments, Scion Films) point to external links with no in-repo evidence; test-script comments are detailed and cite specific commits and measurements but are self-reported and cannot be cross-checked; fact/inference separation is partially handled (scripts distinguish META-FAILURE from assertion failure), but the overall evidence chain is weak, hence 1.
- Publisher identity is unverified and the README states it is not an officially supported Google product; do not infer safety or reliability from the brand.
- chart-integrity.sh sets EXPECTED_TOTAL inconsistently with its own comments and states it will exit 2, indicating an unconverged test baseline; do not treat it as a passing suite.
- go.mod includes dev/pseudo-version dependencies (e.g., grpc dev, chromedp pseudo) with no dependency audit or mitigation note.
- README claims about internal Google experiments and case studies lack in-repo verifiable evidence.
- The project self-describes as pre-1.0 with evolving APIs and configuration, creating naming-stability and upgrade-path risk.
FAQ
Why do I still need scion server start after installing the CLI?
scion command runs agents through a Hub. The local Workstation server is that Hub and owns state, identity, and dispatch, so it must be running even if you initialized the machine manually.Which model API does Scion call itself?
Can it run on Kubernetes or Cloud Run?
Is this ready for production?
How do humans monitor what agents are doing?
scion logs for output and attaching to interactive harness sessions where supported.