Envelope is now a design tool
June 26, 2026 · 4 min read
A few weeks ago we started describing Envelope differently.
Not because the product changed — the workspace, the schema, the library are all still here. But because we kept watching the same thing happen in calls with agencies and consulting teams: they didn't need a place to run AI agents. They needed a place to design them before handing the brief to engineering.
That gap — between "I have an idea for an AI team" and "here is a structured document my IT team can build from" — was the problem nobody had solved. And it was the problem Envelope was already solving, without us saying so clearly.
What changed
Envelope is now positioned as a design tool. Not a runtime. Not a platform to host and operate your agents.
You describe what a team should do, Envelope structures it as a spec — agents, roles, tools, approval gates, schedules — and you export that document for whoever is doing the implementation. Your IT team, an implementation partner, or a developer you've hired.
The analogy we keep reaching for is Figma. Figma doesn't run your product — it designs it. Envelope doesn't run your agents — it designs them.
What didn't change
The workspace is the same. The library is the same. The .envelope.json schema is the same.
If you've been using Envelope to plan agent teams, describe workflows, and share specs with your team — that's exactly the product. Nothing broke. Nothing needs migrating. We just named what it is more accurately.
Why it matters
The old framing put us in a crowded category: AI orchestration platforms, workflow automation tools, agent runtimes. That space is competitive and converging fast.
The design layer is different. Right now, the gap between "non-technical stakeholder with a vision for an AI system" and "engineer who can implement it" is enormous. There's no standard format, no shared vocabulary, no tool for the conversation in the middle. That's the problem Envelope is built to close.
A structured Envelope spec gives the stakeholder a thing they can read, revise, and sign off on. It gives the engineer a thing they can build from. And it creates a record of what was designed, who approved it, and when — before a line of code is written.
What's next
We're building out the export side: richer handoff formats, implementation guides for common platforms, and better tooling for the IT team receiving the spec.
If you're using Envelope for client work — agencies, consulting, internal AI projects — this is the framing you'll want to use when you explain it. Design the system, hand off the file.
That's Envelope.
Frequently Asked Questions
What does it mean that Envelope is a design tool?
Envelope is where you design an AI agent system before anyone builds it. You describe the agents, their roles, tools, handoffs, and approval gates — Envelope structures it into a complete spec document. The implementation happens separately, by your IT team or a developer, using that document as the brief.
Does this change the workspace or the schema?
No. The workspace, the library, and the .envelope.json schema are unchanged. The shift is in how Envelope is positioned — as the design layer, not the runtime.
Who is Envelope for now?
Operations leads, consultants, agency teams, and anyone responsible for defining how an AI workflow should work — before engineering builds it. If you've ever tried to explain an AI agent system in a meeting and realised the brief was too vague, Envelope is the tool that fixes that.
How is Envelope different from building directly in a framework like LangChain or CrewAI?
Frameworks are for building and running agents. Envelope is for designing them first — deciding what each agent does, what it can access, when a human needs to approve something, and how agents hand work to each other. The Envelope output is a structured spec that any compatible framework can implement.