Rendered at 02:59:33 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
nostrebored 3 days ago [-]
I think this is kinda wrong.
Declarative approaches require validation to live at a synthesis layer, while an imperative approach that compiles down to declarative configs at runtime gives you the best of both worlds -- this is why anyone who does not need terraform cross compatibility will write things against CDK or Pulumi that has the same declarative schema wins with the niceness of testability and author-time typing.
Edit:
That said, it is shockingly close to the schema that we wound up with with a few ideas that I think are interesting.
reportsTo allows bottoms up orchestrator delegation
workspaces are interesting -- right now we have one bag of data with per-subagent data subscriptions, but this means that we frequently add input requirements to subagents that really should be more implicit
accessPolicy seems like a footgun to me -- i feel fairly convicted that tools should define their access scope and the only thing a subagent should know is the bag of tools available to it.
human approval seems redundant given we already have input requirements, and one can just be `email_approved` with a tool that emits the human approval request and `email_approved | email_not_approved` -- same feeling about `GateTypes` in general. If we are working on flat input-output requirements, then why do we need a specific GateType handler?
Trigger `any_approved | all_approved` is going to bite you if you move into plan solving. It is not rich enough to express XOR style relationships and I am willing to bet that v2 of your implementation splits TriggerRequirements where TriggerRequirements can be recursively applied to the type.
It seems like the tool definition is missing a lot of niceties that have been important for us -- for instance, at most once invocation. But we are working primarily over voice where there is a strong need to control execution for quality of service.
glenngillen 3 days ago [-]
What do you mean by "Terraform cross compatibility"? Pulumi was (initially) built upon the same underlying providers so had the same capabilities.
I'd posit the main difference between the two was Terraform's declarative approach provided more consistency and predictability in how infrastructure was defined and provisioned. The constraints it imposed were the benefit vs a sprawling estate with a hundred different bespoke ways to provision a given service in your preferred language.
ashconway 3 days ago [-]
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.
nostrebored 3 days ago [-]
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.
Wishing you luck with the project!
ashconway 1 days ago [-]
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!
hipvlady 11 hours ago [-]
It's really useful to have a clear list of who's on the team and what they do, because there isn't one at the moment. A static team definition doesn't show the runtime hazard. This is when two agents read the same artifact. One updates it, while the other keeps acting on the version it loaded. The roles can be clearly defined, but the output is still unclear because agent B wasn't told that agent A had moved the shared state. I would like to know if you think that coordination layer is part of the problem, or if it is only a problem with the runtime.
ashconway 4 hours ago [-]
[dead]
ossianericson 3 days ago [-]
Strong for the downstream part.
Upstream rules should travel with your repository, never be locked to just one agent. I want to experiment, test different models.
I could never work in one model, it requires specific parts that work only in that specific snowflake implementation.
I guess Envelope is trying to tackle this in a vendor-agnostic way?
ashconway 3 days ago [-]
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.
ander1733 1 days ago [-]
this is sick nicely done, definitely where things are trending
ashconway 4 hours ago [-]
Appreciate it. Let me know if you hit gaps in the schema, or if you build multi agent systems and see anything missing.
politician 2 days ago [-]
It's clear that you understand that releasing a schema with this much documentation makes the AI-assisted reverse engineering loop trivial. I'm interested in understanding why I should trust/use/pay for your hosted runtime versus rolling my own to run on cheap VPS?
ashconway 2 days ago [-]
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.
Declarative approaches require validation to live at a synthesis layer, while an imperative approach that compiles down to declarative configs at runtime gives you the best of both worlds -- this is why anyone who does not need terraform cross compatibility will write things against CDK or Pulumi that has the same declarative schema wins with the niceness of testability and author-time typing.
Edit:
That said, it is shockingly close to the schema that we wound up with with a few ideas that I think are interesting.
reportsTo allows bottoms up orchestrator delegation
workspaces are interesting -- right now we have one bag of data with per-subagent data subscriptions, but this means that we frequently add input requirements to subagents that really should be more implicit
accessPolicy seems like a footgun to me -- i feel fairly convicted that tools should define their access scope and the only thing a subagent should know is the bag of tools available to it.
human approval seems redundant given we already have input requirements, and one can just be `email_approved` with a tool that emits the human approval request and `email_approved | email_not_approved` -- same feeling about `GateTypes` in general. If we are working on flat input-output requirements, then why do we need a specific GateType handler?
Trigger `any_approved | all_approved` is going to bite you if you move into plan solving. It is not rich enough to express XOR style relationships and I am willing to bet that v2 of your implementation splits TriggerRequirements where TriggerRequirements can be recursively applied to the type.
It seems like the tool definition is missing a lot of niceties that have been important for us -- for instance, at most once invocation. But we are working primarily over voice where there is a strong need to control execution for quality of service.
I'd posit the main difference between the two was Terraform's declarative approach provided more consistency and predictability in how infrastructure was defined and provisioned. The constraints it imposed were the benefit vs a sprawling estate with a hundred different bespoke ways to provision a given service in your preferred language.
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.
Wishing you luck with the project!
Upstream rules should travel with your repository, never be locked to just one agent. I want to experiment, test different models.
I could never work in one model, it requires specific parts that work only in that specific snowflake implementation.
I guess Envelope is trying to tackle this in a vendor-agnostic way?
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.