If you want to run your own runtime on cheap VPS, you should. That's part of why the schema is open. The hosted runtime is for people who don't want to operate that layer themselves.
On accessPolicy — sub-agents in Envelope are the tools: each defines its own access scope, the supervisor just knows what's available. Where the concern is valid is function-level tool calls — no first-class tool definition layer yet, so HTTP access scope ends up at the agent level rather than the tool.
On gates — the per-record model handles dynamic output you can't pre-declare at schema time, and timeout/onReject are runtime routing decisions. The action type specifically is doing real work — irreversible step, explicit approval required before it fires.
On trigger logic: agreed. XOR isn't expressible with the current set and recursive conditions is almost certainly the v2 shape.
Read some of your other stuff. I think we're on the same track, which is interesting! Everyone in our (admittedly SF centric) circles is trying to chase this down from the model path rather than building the consistent execution layer that we believe all of these solutions will need.
Thanks, good to know we're on the same path. The bet is that sub agents will work together in teams, and different models will be better suited to different sub agents/tasks. At that point, coordination, observability, and governance are best kept vendor agnostic. Same to you!
Right — well-suited for what they do: scripts Claude generates to orchestrate subagents for a specific task at scale (audits, migrations, research). Each run completes; that's the design.
The schema here defines the team itself — roles, supervisor/sub-agent hierarchy, access policies, human gates, schedules — as a portable, reusable declaration. Run it once, on a schedule, or keep it deployed. Closer to a Dockerfile than a script.
Vendor-agnostic is part of it. Nothing in the spec ties to Claude or any specific runtime — Apache 2.0, anyone can implement a compatible runtime.
By artificially limiting the number of invites, you get a finite number of individuals to work with and get feedback from during your beta.
I'm not sure the referrals program is always the solution you want. You should try to make sure the people who are coming to your site are qualified, otherwise Joe will ask Alice, Bob, and Charlie to join. Those 3 won't stay for any meaningful amount of time (blowing 3 of your slots), and Joe now has upgrades/perks/???. It's more desirable for you to have those 3 users giving you input.
However, there could be a time when you don't want to limit invites, such as when you need user generated content. Then the more beta users you have, the more content you have generated when you go "live".
reply