Interesting to see Google go with a testbed approach instead of a production framework. In practice the hard part of agent orchestration is not the routing but deciding when to stop. Most agents loop forever without good termination conditions.
Six months from now half of these abstractions will have been renamed or removed once real users push back on the cognitive overhead. Google has a pattern of releasing infrastructure that's perfectly shaped for Googles problems and awkward for everyone else's
It's super neat! Just like Kubernetes is also super neat at what it can do. It's super neat primarily because consuming it is so easy, provided you already have all the same abstraction layers in place in your infra.
You...do have all the same abstraction layers, right? No? Oh. Well, don't worry, Google/Amazon/Microsoft can sell you those if you don't want to pay your IT staff to prop it up for you.
---
Look, snark aside, yours is the correct take. Google's solutions are amazing, but they're also built for an organization as large and complex as Google. Time will tell if this is an industry-standard abstraction (a la S3 APIs) or just a Google product for Google-like orgs/functions (a la K8s).
[primary author and architect of scion here] Part of this will be pushing that cognitive overhead increasingly onto agents. By how much and when is what Scion is here to explore.
I think most of the legacy companies that can benefit from Kubernetes don't use it, while most of the companies that are using it are startups doing it for the résumé.
This is the exact opposite of my experience. Maybe it was true 10 years ago when K8s was new and trendy so many engineers wanted to try it out. Now it's just boring tech at large orgs.
I'm proud to say I retired more k8s clusters than I created. And I've created 5 production ones, still in production.
One that I retired was used for serving ftp(among other transfer stuff), ftp of all things, it needs to have ports open and routed back from the client. And for extra points they had the pods capped at 1 cpu. And I had to explain the thing to the perpetrator and their boss, madness.
k8s is simple because it offload some key tasks to 3rd party like network and storage; it is not easy to: a) setup and maintain a k8s cluster with all necessary components from at least a dozen different sources b) design your application to be k8s native
This. K8s is easy to consume, and a real PITA to actually setup and support from an IT perspective.
If someone wants production K8s, I'm steering them (and their budget) to a managed control plane from one of the major cloud providers. Trying to prop it up locally when it really hates having to work directly with bare metal does not spark joy.
The same way linux isn't. It's easy to start, all the base modifications/configurations are fairly simple, and if you find yourself deep into custom ways of using it, it's open source and fairly well documented with a large community.
I'm looking forward to trying this. I've had a positive but high-variance experience with Gastown[1], which is in the same genre. I hope that Scion does better.
My main complaints with Gastown are that (1) it's expensive, partly because (2) it refuses to use anything but Claude models, in spite of my configuration attempts, (3) I can't figure out how to back up or add a remote to its beads/dolt bug database, which makes me afraid to touch the installation, and (4) upgrading it often causes yak shaving and lost context. These might all be my own skill issues, but I do RTFM.
But wow, Gastown gets results. There's something magic about the dialogue and coordination between the mayor and the polecats that leads to an even better experience than Claude Code alone.
The "Build container images" is confusing and written for someone who is familiar with GitHub Actions and ghcr.io. `fork this repo` should be linkified. The page never actually tells you where the repo is; you have to infer it from a `go install` command. It's https://github.com/GoogleCloudPlatform/scion/.
Under "Building Custom Images," option 1 seems to require having cloned the repository, but as mentioned earlier, there's no indication of where the repo is hosted. This option fails for me with `=> ERROR [internal] load metadata for ghcr.io/sowbug/core-base:latest`, and I don't know what that means. My guess would be it's a dependency error because the build-images.sh script was not tested with a completely clean registry like mine. (Update: I got farther by adding `--target core-base` to the script arguments. This means that the script documentation "Build scion-base + all harness images" is misleading, because it requires you to know that scion-base depends on core-base, but the "Quick Start" script doesn't build that for you.) (Update 2: this still fails with "failed to fetch anonymous token," which I'm guessing is needed for me to upload to my registry. To reiterate, until today I had no idea that I had a registry.) (Update 3: I had to authenticate -- different from gh auth login -- using `echo "ghp_[rest of PAT]" | docker login ghcr.io -u [your-github-username] --password-stdin`. I got the PAT at https://github.com/settings/tokens and creating a classic personal access token with permissions read:org and write:packages.)
Option 2 starts with "If your project is hosted on GitHub," but I don't have a project (I want to test-drive Scion to start one), so I don't know whether that option applies to me. I tried it anyway, and it failed with a similar error as option 1 -- "core-base:latest: not found."
I'm not going to try Option 3, because it appears to give even less background than the prior options.
The instructions are inconsistent about referring to `ghcr.io/myorg` or `ghcr.io/<your-username>`. If anything, it is consistently backward in that it includes ghcr.io/myorg in text designed to be copied/pasted, and ghcr.io/<your-username> in text designed to be read.
scion init --machine doesn't check to see whether you've already set the image_registry option (as you would if you went through Quick Start Option 1), so you have to retype it.
Isolation over constraints sounds like the right philosophy. Containers give you a boundary but not vis into what ran inside them. Curious how much execution context Scion surfaces, w/o that you're still in a position similar to the LiteLLM attack where something can run and cause damage before you know it happened.
[primary author and architect of scion here]
There are several layers of state and telemetry - first is provided by the hook system available in most harnesses, then for those that provide OpenTelemetry -that is normalized and forwarded raw (preserving both) to a cloud collector. Finally - some activities are "self reported" by agents using a built-in toolset that can be reflected in the control plane
Really interesting to see Google's approach to this.
Recently I shared my approach, Optio, which is also an Agent Orchestration platform: https://news.ycombinator.com/item?id=47520220
I was much more focused on integrating with ticketing systems (Notion, Github Issues, Jira, Linear), and then having coding agents specifically work towards merging a PR.
Scion's support for long running agents and inter-container communication looks really interesting though. I think I'll have to go plan some features around that. Some of their concepts, make less sense to me, I chose to build on top of k8s whereas they seem to be trying to make something that recreates the control plane. Somewhat skeptical that the recreation and grove/hub are needed, but maybe they'll make more sense once I see them in action the first time.
[primary author and architect of scion here] The missing features are mostly by design - this is closer to what the gastown plans as "gascity" - bring your own orchestration characters and definition.
> This project is early and experimental. Core concepts are settled, but expect rough edges. Local mode: relatively stable - Hub-based workflows: ~80% verified - Kubernetes runtime: early with known rough edges
i guess gastown is a better choice for now? idk i don't feel good about "relatively stable"
I swore to not be burned by google ever again after TensorFlow. This looks cool, and I will give this to my Codex to chew on and explain if it fits (or could fit what I am building right now -- the msx.dev) and then move on. I don't trust Google with maintaining the tools I rely on.
I want to experiment more with agents but my employer only pays for Claude Code, and TOS disallows using the subscription API for other purposes. Anyone else in the same boat? Token based pricing also gets expensive fast.
Their agent tooling is shaping up to be the well known issue of product cancellation. They have how many different takes on this now? (gemini-cli, antigravity, AI studio, this, Gemini app)
I've not been impressed with any of them. I do use their ADK in my custom agent stack for the core runtime. That one I think is good and has legs for longevity.
The main enterprise problem here is getting the various agent frameworks to play nice. How should one have shared runtimes, session clones, sandboxes, memory, etc between the tooling and/or employees?
Not if you go custom, you have unlimited latitude, examples...
I modified file_read/write/edit to put the contents in the system prompt. This saves context space, i.e. when it rereads a file after failed edit, even though it has the most recent contents. It also does not need to infer modified content from read+edits. It still sees the edits as messages, but the current actual contents are always there.
My AGENTS.md loader. The agent does not decide, it's deterministic based on what other files/dirs it has interacted with. It can still ask to read them, but it rarely does this now.
I've also backed the agents environment or sandbox with Dagger, which brings a number of capabilities like being able to drop into a shell in the same environment, make changes, and have those propagate back to the session. Time travel, clone/fork, and a VS Code virtual FS are some others. I can go into a shell at any point in the session history. If my agent deletes a file it shouldn't, I can undo it with the click of a button.
I can also interact with the same session, at the same time, from VS Code, the TUI, or the API. Different modalities are ideal for different tasks (e.g. VS Code multi-diff for code review / edits; TUI for session management / cleanup).
You...do have all the same abstraction layers, right? No? Oh. Well, don't worry, Google/Amazon/Microsoft can sell you those if you don't want to pay your IT staff to prop it up for you.
---
Look, snark aside, yours is the correct take. Google's solutions are amazing, but they're also built for an organization as large and complex as Google. Time will tell if this is an industry-standard abstraction (a la S3 APIs) or just a Google product for Google-like orgs/functions (a la K8s).
One that I retired was used for serving ftp(among other transfer stuff), ftp of all things, it needs to have ports open and routed back from the client. And for extra points they had the pods capped at 1 cpu. And I had to explain the thing to the perpetrator and their boss, madness.
If someone wants production K8s, I'm steering them (and their budget) to a managed control plane from one of the major cloud providers. Trying to prop it up locally when it really hates having to work directly with bare metal does not spark joy.
My main complaints with Gastown are that (1) it's expensive, partly because (2) it refuses to use anything but Claude models, in spite of my configuration attempts, (3) I can't figure out how to back up or add a remote to its beads/dolt bug database, which makes me afraid to touch the installation, and (4) upgrading it often causes yak shaving and lost context. These might all be my own skill issues, but I do RTFM.
But wow, Gastown gets results. There's something magic about the dialogue and coordination between the mayor and the polecats that leads to an even better experience than Claude Code alone.
1. https://github.com/gastownhall/gastown/
The "Build container images" is confusing and written for someone who is familiar with GitHub Actions and ghcr.io. `fork this repo` should be linkified. The page never actually tells you where the repo is; you have to infer it from a `go install` command. It's https://github.com/GoogleCloudPlatform/scion/.
Under "Building Custom Images," option 1 seems to require having cloned the repository, but as mentioned earlier, there's no indication of where the repo is hosted. This option fails for me with `=> ERROR [internal] load metadata for ghcr.io/sowbug/core-base:latest`, and I don't know what that means. My guess would be it's a dependency error because the build-images.sh script was not tested with a completely clean registry like mine. (Update: I got farther by adding `--target core-base` to the script arguments. This means that the script documentation "Build scion-base + all harness images" is misleading, because it requires you to know that scion-base depends on core-base, but the "Quick Start" script doesn't build that for you.) (Update 2: this still fails with "failed to fetch anonymous token," which I'm guessing is needed for me to upload to my registry. To reiterate, until today I had no idea that I had a registry.) (Update 3: I had to authenticate -- different from gh auth login -- using `echo "ghp_[rest of PAT]" | docker login ghcr.io -u [your-github-username] --password-stdin`. I got the PAT at https://github.com/settings/tokens and creating a classic personal access token with permissions read:org and write:packages.)
Option 2 starts with "If your project is hosted on GitHub," but I don't have a project (I want to test-drive Scion to start one), so I don't know whether that option applies to me. I tried it anyway, and it failed with a similar error as option 1 -- "core-base:latest: not found."
I'm not going to try Option 3, because it appears to give even less background than the prior options.
The instructions are inconsistent about referring to `ghcr.io/myorg` or `ghcr.io/<your-username>`. If anything, it is consistently backward in that it includes ghcr.io/myorg in text designed to be copied/pasted, and ghcr.io/<your-username> in text designed to be read.
scion init --machine doesn't check to see whether you've already set the image_registry option (as you would if you went through Quick Start Option 1), so you have to retype it.
I was much more focused on integrating with ticketing systems (Notion, Github Issues, Jira, Linear), and then having coding agents specifically work towards merging a PR. Scion's support for long running agents and inter-container communication looks really interesting though. I think I'll have to go plan some features around that. Some of their concepts, make less sense to me, I chose to build on top of k8s whereas they seem to be trying to make something that recreates the control plane. Somewhat skeptical that the recreation and grove/hub are needed, but maybe they'll make more sense once I see them in action the first time.
https://github.com/GoogleCloudPlatform/scion
If you look at this orchestration example
https://github.com/ptone/scion-athenaeum
its just markdown - Scion is the game engine
(a port of gastown to run on scion is in progress)
i guess gastown is a better choice for now? idk i don't feel good about "relatively stable"
and also wrote about it https://s2.dev/blog/distributed-ai-agents
> https://en.wikipedia.org/wiki/SCION_(Internet_architecture)
I've not been impressed with any of them. I do use their ADK in my custom agent stack for the core runtime. That one I think is good and has legs for longevity.
The main enterprise problem here is getting the various agent frameworks to play nice. How should one have shared runtimes, session clones, sandboxes, memory, etc between the tooling and/or employees?
I modified file_read/write/edit to put the contents in the system prompt. This saves context space, i.e. when it rereads a file after failed edit, even though it has the most recent contents. It also does not need to infer modified content from read+edits. It still sees the edits as messages, but the current actual contents are always there.
My AGENTS.md loader. The agent does not decide, it's deterministic based on what other files/dirs it has interacted with. It can still ask to read them, but it rarely does this now.
I've also backed the agents environment or sandbox with Dagger, which brings a number of capabilities like being able to drop into a shell in the same environment, make changes, and have those propagate back to the session. Time travel, clone/fork, and a VS Code virtual FS are some others. I can go into a shell at any point in the session history. If my agent deletes a file it shouldn't, I can undo it with the click of a button.
I can also interact with the same session, at the same time, from VS Code, the TUI, or the API. Different modalities are ideal for different tasks (e.g. VS Code multi-diff for code review / edits; TUI for session management / cleanup).