ashconway

Appreciate it. Let me know if you hit gaps in the schema, or if you build multi agent systems and see anything missing.

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!

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.

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.

Been building AI teams and wanted to write up what I've learned about design principles.