[HN Gopher] Google open-sources experimental agent orchestration...
___________________________________________________________________
Google open-sources experimental agent orchestration testbed Scion
https://googlecloudplatform.github.io/scion/overview/
Author : timbilt
Score : 134 points
Date : 2026-04-07 13:39 UTC (9 hours ago)
(HTM) web link (www.infoq.com)
(TXT) w3m dump (www.infoq.com)
| hackerman70000 wrote:
| 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
| popalchemist wrote:
| 100%. Great assessment.
| repelsteeltje wrote:
| Like Kubernetes?
| conception wrote:
| And angular.
| otabdeveloper4 wrote:
| Yes, and unironically.
| hhh wrote:
| kubernetes isnt difficult
| Mond_ wrote:
| really?
| scottyah wrote:
| 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.
| hujun wrote:
| 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
| stego-tech wrote:
| 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.
| jjmarr wrote:
| 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 resume.
| manojlds wrote:
| This is not 2015.
| dvfjsdhgfv wrote:
| 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.
| permalac wrote:
| 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.
| verdverm wrote:
| It's also much easier to bring online these days with
| managed offerings like GKE, EKS, and AKS.
|
| I have no love for the original bash scripts that booted
| the cluster from your dev machine.
|
| Now we also have k3s that is a easy option for self
| hosting something simple (like homelab).
| verdverm wrote:
| Slightly trailing off from your focus, but hopefully within
| the same sentiment (that k8s was good, albeit an exception)
|
| I would place Google ADK in alignment with Kubernetes more
| than this project, for the well designed abstractions, the
| controlplane, and handling the boring parts that every
| alternative will at maturity.
|
| I can see the agent framework ignorance to the container
| analogy about what's running inside. ADK lacks the ability to
| run any agent tool, but you can build most of this projects
| controlplane on top of it with minimal effort, most of the
| bookkeeping is there already. It's more about what experience
| you want to have.
| stego-tech wrote:
| 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).
| ptone wrote:
| [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.
| verdverm wrote:
| 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?
| otabdeveloper4 wrote:
| It's all just system prompts under the hood and nothing more.
| IncreasePosts wrote:
| Don't forget a while loop and a TODO.md
| verdverm wrote:
| 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).
| ptone wrote:
| [primary author and architect of scion here] Actually - there
| are two other big parts: a CLI and a control plane
| simple10 wrote:
| They kinda buried the code deep in their docs:
|
| https://github.com/GoogleCloudPlatform/scion
| tornikeo wrote:
| 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.
| forsalebypwner wrote:
| nice plug
| cedws wrote:
| 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.
| ptone wrote:
| This runs stock Claude Code in containers, should be completely
| fine for TOS
| aleph_minus_one wrote:
| Reading this headline, I rather thought of a different SCION:
|
| > https://en.wikipedia.org/wiki/SCION_(Internet_architecture)
| sowbug wrote:
| 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.
|
| 1. https://github.com/gastownhall/gastown/
| armanj wrote:
| > 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"
| kvanbeek wrote:
| This seems to be in the direction of Gas Town but missing some of
| the core features. Having formulas has been game changing.
| ptone wrote:
| [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.
|
| 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)
| infiniteregrets wrote:
| this is very cool! i recently hacked on something similar
| https://github.com/s2-streamstore/parallax
|
| and also wrote about it https://s2.dev/blog/distributed-ai-agents
| jawiggins wrote:
| 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.
| jFriedensreich wrote:
| Disapointing google of all places uses git worktrees instead of
| jj workspaces.
| verdverm wrote:
| jj will not achieve meaningful adoption until git interop is
| improved and there is a big enough win to change a core work
| tool. Lack of git-lfs is a blocker where I work and asking all
| the devs to change their git habits for a shop that doesn't use
| rebase (as I understand the main issue jj aims to make
| better)... the ROI just doesn't appear to be there.
| BlueRock-Jake wrote:
| 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.
| ptone wrote:
| [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
| studio-m-dev wrote:
| 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.
| ptone wrote:
| [primary author and architect of scion here] The reason this is
| a testbed is because this is a new and emerging area of
| replacing things like codified graphs in tools like langraph
| with pure agent instruction where agents manage agents with a
| lot more autonomy. These patterns are not well explored, and
| are not ready for production in most cases. The goal of a
| testbed is to have an easy and quick way to try out N of these
| patterns.
| mahadillah-ai wrote:
| Agent orchestration is one side of the problem. The other side
| is: where does the data go? When agents process
| EU user data (names, emails, IBANs) and route it to US
| model providers, that's a GDPR violation. I open
| sourced a routing layer that detects PII in prompts and
| forces EU-only inference when personal data is found:
| https://github.com/mahadillahm4di-cyber/mh-gdpr-ai.eu
| bitwize wrote:
| My brain keeps wanting to pronounce it Tomb Raider style, like
| /'ski: an/.
___________________________________________________________________
(page generated 2026-04-07 23:00 UTC)