logoalt Hacker News

solarkraftyesterday at 11:41 PM2 repliesview on HN

> you are opting in to a pretty huge stack that is just Agent Substrate, that is their runners, their harness, their substrate

The website makes me think the contrary: It is described as “low opinion” and explicitly mentions that the running tasks don’t even have to be AI agents. Can you explain in what ways you’re more locked in than the website suggests?

Scion at the same time talks much more about concrete agents, giving me the opposite initial impression.


Replies

pamayesterday at 11:50 PM

Not GP, but you start with Kubernetes…

> You need a Kubernetes cluster, ko (brew install ko), a container registry your cluster can pull from, and a reachable Agent Substrate Control API (in-cluster default: api.ate-system.svc.cluster.local:443).

> make deploy AX_IMAGE_REPO=<your-registry>

> This deploys Redis, then builds and deploys the control plane images with ko. Everything lands in the ax-system namespace.

jauntywundrkindtoday at 1:48 AM

Indeed, there's much less, and that's lower opinion. But you also can't run normal workloads. You have to build for Agent Substrate / Ax.

What's nice about Scion is that it runs existing systems. It runs Claude, it runs Code, it runs Pi, it runs OpenCode. By contrast, "low opinion" means build something new, from scratch, atop this brand new platform.

Note that both of these are designed to work at some scale. Agent Substrate specifically is somewhat coupled to Kubernetes, is my impression, but honestly that's fine with me. Scion can run on Docker, Podman, Apple Container, Kubernetes, or Cloud Run. It's good that we be able to run these relatively quickly, but (especially with LLM assistance) the idea of running some substantial dependencies / services to run these things does not seem like a bad thing. If anything, I'd prefer having some well known services underfoot to these all being recreated afresh.