My brain keeps wanting to pronounce it Tomb Raider style, like /ˈskiː ɒn/.
Google open-sources experimental agent orchestration testbed Scion
51–60 of 78 posts
Re: Google open-sources experimental agent orchestration testbed Scion
#52[flagged]
Like Kubernetes?
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.
Re: Google open-sources experimental agent orchestration testbed Scion
#53Earlier quoted context omitted.
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.
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).
Re: Google open-sources experimental agent orchestration testbed Scion
#54Disapointing google of all places uses git worktrees instead of jj workspaces.
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.
Re: Google open-sources experimental agent orchestration testbed Scion
#55[flagged]
[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.
Re: Google open-sources experimental agent orchestration testbed Scion
#56They kinda buried the code deep in their docs: https://github.com/GoogleCloudPlatform/scion
Exactly, I actually starred this in late March and hadn't made my way back to it yet. Glad somebody posted, looks very interesting.
Re: Google open-sources experimental agent orchestration testbed Scion
#57> 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"
imagine thinking gas town is a better choice over _literally anything else_
Re: Google open-sources experimental agent orchestration testbed Scion
#58I'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 ma…
As someone who hasn't yet jumped into working with multiple agents simultaneously, where does a tool like gastown help you the most?
Re: Google open-sources experimental agent orchestration testbed Scion
#59I'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 ma…
Have you looked at mngr by Imbue? Some of the same energy, you might find it useful.
Re: Google open-sources experimental agent orchestration testbed Scion
#60I'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 ma…
Scion looks interesting, as a “hypervisor for agents”. It has Kubernetes influences, and a substrate for agent execution is a useful primitive.
Gastown goes further than Scion in that it chains agents together into an ecosystem. My sense is that Gastown or similar could be built as a layer on top of Scion.
Dan Shapiro helped shape my thinking on the two most important capabilities for agent orchestration as concurrency and loops. Scion provides concurrency only at present, and Gastown is also more concurrency-oriented than loops.
Fabro is a new OSS project I am working on which attempts to do both loops and concurrency well: https://github.com/fabro-sh/fabro (Maybe someday it should be built on top of Scion.)