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

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

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/

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.

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.

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.

They kinda buried the code deep in their docs:

https://github.com/GoogleCloudPlatform/scion

This seems to be in the direction of Gas Town but missing some of the core features. Having formulas has been game changing.

> 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"

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

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.

Reading this headline, I rather thought of a different SCION:

> https://en.wikipedia.org/wiki/SCION_(Internet_architecture)

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.

Disapointing google of all places uses git worktrees instead of jj workspaces.

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]

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?