Google open-sources experimental agent orchestration testbed Scion
11–20 of 78 posts
Re: Google open-sources experimental agent orchestration testbed Scion
#12Re: Google open-sources experimental agent orchestration testbed Scion
#13Re: Google open-sources experimental agent orchestration testbed Scion
#14Re: Google open-sources experimental agent orchestration testbed Scion
#15I 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.
Re: Google open-sources experimental agent orchestration testbed Scion
#16Re: Google open-sources experimental agent orchestration testbed Scion
#17Their 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 framewor…
It's all just system prompts under the hood and nothing more.
Re: Google open-sources experimental agent orchestration testbed Scion
#18> https://en.wikipedia.org/wiki/SCION_(Internet_architecture)
Re: Google open-sources experimental agent orchestration testbed Scion
#19My 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.
Re: Google open-sources experimental agent orchestration testbed Scion
#20Their 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 framewor…
It's all just system prompts under the hood and nothing more.
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).