Why open standards matter for AI infrastructure
April 2026 · 5 min read
The internet runs on standards nobody owns. AI infrastructure doesn't — yet. What format lock-in actually costs, and why the ecosystem effects of an open standard can't emerge from a closed one.
The internet runs on standards nobody owns. HTTP, SMTP, SQL, RSS — protocols that any implementor can read, build against, and extend without asking permission. When you send an email, you don't think about which server is on the other end. When you query a database, your application doesn't break because the vendor released a new version. These things work because the contract between components is public, stable, and enforced by convention rather than by a single company's product roadmap.
AI infrastructure in 2026 looks nothing like this.
Every orchestration platform — every system for defining AI agents and running them at scale — speaks its own language. One platform expects a YAML file with a steps array. Another uses a Python SDK with decorators. A third has a visual editor that exports to a proprietary JSON format. None of them interoperate. A team you build on platform A cannot run on platform B without a full rewrite.
This is where we were with databases before SQL. With email before SMTP. With the web before HTTP.
Quick answer
AI orchestration today lacks interoperability: every platform uses a different format for defining agents, and a team built on one platform can't run on another without a full rewrite. Open standards solve this by separating design from runtime — a team spec written to an open schema can be implemented on any compliant runtime. The goal is for AI agent design to reach the same interoperability that SQL brought to databases and HTTP brought to the web.
What lock-in costs
Platform lock-in in AI orchestration isn't just an inconvenience — it has compounding costs.
Speed to market. When your choice of infrastructure is also a choice of how you define your AI team, switching platforms means starting over. Teams that would have taken a week to migrate take months, if they get migrated at all.
Negotiating leverage. A builder who has invested a year into one platform's format has effectively given up their ability to shop around. The platform knows this. Pricing, SLA terms, and feature prioritisation all become harder to negotiate when exit costs are this high.
Ecosystem fragility. If a platform shuts down, pivots, or changes pricing, the teams built on it are stranded. This has already happened multiple times in the two years since LLM-powered orchestration became viable. The teams weren't portable. The work was lost.
Ecosystem formation. Standards create ecosystems. When a format is open, third parties build validators, linters, editors, and adapters around it — without asking for permission and without a business development agreement. Closed formats don't accumulate these effects. The platform has to build everything, and they always build less than the community would.
What standards actually enable
When a team definition is a file — a JSON document with a public schema — something fundamental changes.
Builders can move. If a new runtime is faster or cheaper, migrating is a matter of pointing to the same file. The definition doesn't change. The agents, their roles, their access policies, their inputs and outputs — all of it is the definition, and the definition is portable.
Validators emerge. Once a schema exists, it becomes possible to check a team definition before deploying it. Your editor can flag missing required fields. A CI pipeline can reject a broken definition before it reaches production. These tools don't require a central authority to build them — anyone can implement a validator against a public schema.
Registries become possible. A common definition format means multiple parties can host and distribute teams. A team published to one registry can be discovered, verified, and installed from another. The builder's identity and the registry's identity are separate concerns — just as a package author is separate from npm.
Trust becomes observable. When an agent's outbound access rules are declared in the definition — what hosts it can call, under what conditions — an operator can read them before installing. A closed platform with opaque internals can't offer this. The standard makes security review possible.
The precedent is clear
The history of software is a history of standards winning. Not always quickly, not always cleanly, but reliably. Java didn't kill C++. XML didn't kill everything it touched. But HTTP did win, and the web that exists today is the web that could only have been built once a common protocol was established.
AI orchestration is at the HTTP moment. The platforms building today are making format choices that will either lock in their users for years or open the ecosystem to effects none of them can fully anticipate. The ones who choose openness will be the ones whose names appear in the history of how AI agents became infrastructure.
The Envelope schema is an attempt to be that standard — a public, versioned JSON Schema for defining AI agents that any platform can implement, any builder can publish against, and any deployer can install without caring which runtime is on the other end.
It's early. The ecosystem around it is nascent. But the shape of the thing that needs to exist is clear, and the time to establish the open path is before the closed alternatives have accumulated too much inertia.
Standards don't win by being perfect. They win by being early, open, and good enough to build on.
Design your AI agents in Envelope
Envelope turns a plain-language description of your workflow into a complete AI agent system — agents with named roles, model assignments, tool access, handoffs, and human review gates. Free to start, no code required.
Frequently asked questions
Why does AI infrastructure need open standards?
Every AI orchestration platform currently speaks its own format — YAML, a proprietary SDK, a closed JSON export. Teams built on one platform can't run on another without a full rewrite, the same problem the internet solved with HTTP, SMTP, and SQL.
What does platform lock-in actually cost AI teams?
Slower migrations if you ever need to switch, weaker negotiating leverage on pricing and terms, and the risk of being stranded if a platform shuts down, pivots, or changes pricing.
What becomes possible once an AI team definition has a public schema?
Validators can check a definition before deployment, registries can host and distribute teams across parties, and operators can read an agent's declared access rules before installing it — none of which a closed format allows.
Is the Envelope schema a proprietary format?
No. It's a public, versioned JSON Schema for defining AI agents that any platform can implement, any builder can publish against, and any deployer can install without depending on a specific runtime.
Has an open standard ever won out over proprietary platforms before?
Yes — HTTP is the clearest precedent. Multiple proprietary protocols competed early on, but the open, common standard is what let the web be built at all, by anyone, without asking permission.
Why does open standardisation matter now rather than later for AI orchestration?
Because the platforms building today are making format choices that will either lock users in for years or open the ecosystem to effects none of them can fully anticipate — and it's easier to establish an open path before closed alternatives accumulate inertia.
→ The Envelope schema — the open, Apache 2.0 JSON Schema for multi-agent team definitions
→ Schema versioning policy — how backwards compatibility is maintained as the standard evolves