Hacker News: ashconway

The composable AI thesis

ashconway — Mon, 29 Jun 2026 22:12:24 +0000

Article URL: https://openenvelope.org/writing/composable-ai-thesis/

Comments URL: https://news.ycombinator.com/item?id=48726012

Points: 3

# Comments: 0

Why open standards matter for AI infrastructure

ashconway — Wed, 03 Jun 2026 17:00:54 +0000

Article URL: https://openenvelope.org/writing/open-standards-ai-infrastructure/

Comments URL: https://news.ycombinator.com/item?id=48386587

Points: 2

# Comments: 0

New comment by ashconway in "Show HN: Open Envelope – an open schema for defining AI agent teams"

ashconway — Tue, 02 Jun 2026 22:41:18 +0000

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

New comment by ashconway in "Show HN: Open Envelope – an open schema for defining AI agent teams"

ashconway — Tue, 02 Jun 2026 02:23:20 +0000

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!

New comment by ashconway in "Show HN: Open Envelope – an open schema for defining AI agent teams"

ashconway — Mon, 01 Jun 2026 11:35:56 +0000

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.

New comment by ashconway in "Show HN: Open Envelope – an open schema for defining AI agent teams"

ashconway — Sun, 31 May 2026 01:49:12 +0000

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.

New comment by ashconway in "Show HN: Open Envelope – an open schema for defining AI agent teams"

ashconway — Sun, 31 May 2026 00:27:03 +0000

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.

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

ashconway — Thu, 28 May 2026 20:30:20 +0000

Built an open JSON Schema for defining AI agent teams.

Multi-agent systems are becoming a real deployment pattern — not single assistants, but teams with roles, handoffs, and human checkpoints. But there's no shared way to define one that travels across frameworks. Every implementation is scattered, locked to whichever tool you picked first. Built the schema to fix that.

The schema lives at schema.openenvelope.org and is registered in SchemaStore, so if you drop a .envelope.json file in VS Code you get autocomplete and validation without installing anything. It's also on npm as @openenvelope/schema if you want to validate programmatically.

The spec covers: agent definitions (role, prompt, model, access policy), supervisor/sub-agent hierarchy, human-in-the-loop gates, pipelines, schedules, and secrets/variables that get injected at deploy time. Access policies let you declare exactly which hosts each agent can call — the runtime enforces this at the network level, not in the prompt.

The goal is a portable definition format — define a team once, any compatible runtime can execute it. Similar to how Dockerfiles describe a container without being tied to a specific host. There's a managed runtime at openenvelope.org but the schema is Apache 2.0 and anyone can implement it.

Happy to answer questions on any part of the spec — especially interested in feedback from people who've built multi-agent systems and have opinions on what's missing.

Comments URL: https://news.ycombinator.com/item?id=48315016

Points: 52

# Comments: 13