Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Open Envelope – an open schema for defining AI agent teams

openenvelope.org

Post reply on HN
Print view View original

11–19 of 19 posts

Re: Show HN: Open Envelope – an open schema for defining AI agent teams

#12

Post by politician »

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?

Re: Show HN: Open Envelope – an open schema for defining AI agent teams

#13

Post by ashconway »

politician wrote: post #12

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?

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.

Re: Show HN: Open Envelope – an open schema for defining AI agent teams

#14

Post by ashconway »

ossianericson wrote: post #10

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.

[dead]

Re: Show HN: Open Envelope – an open schema for defining AI agent teams

#16

Post by ashconway »

nostrebored wrote: post #8
ashconway wrote: post #6

Earlier quoted context omitted.

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 a…

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!

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!

Re: Show HN: Open Envelope – an open schema for defining AI agent teams

#17

Post by hipvlady »

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.

Re: Show HN: Open Envelope – an open schema for defining AI agent teams

#18

Post by ashconway »

hipvlady wrote: post #17

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 shar…

[dead]
Post reply on HN