thanks for the kind comments (lead Scion architect here), Scion is still very much meant for teams of people to interact with teams of agents. it is not just about scheduling agents on infrastructure. it’s been getting some new UX improvements:
https://youtu.be/1WYsoSXt9QQ
[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.
[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.
I'm glad to see other projects like this. I did switch over to using Gascity, but it does still seem to have quite a few troubles. Does scion have a beads like concept using formulas for work?
[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.
[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
