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 guess Envelope is trying to tackle this in a vendor-agnostic way?

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.